比特幣交易廣播流程與記憶池狀態管理完整指南

比特幣交易的的生命週期從建立到確認涵蓋了複雜的網路傳播、共識驗證與費用市場機制。理解這些過程不僅有助於開發者建構更高效的应用，更是進階使用者優化交易費用與確認時間的關鍵知識。本文將深入解析比特幣交易從創建到確認的完整流程，並提供記憶池狀態管理的實務指南。

交易的創建與序列化

比特幣交易在廣播前必須經過正確的建構與序列化過程。

交易的基礎結構

每筆比特幣交易由輸入（Input）與輸出（Output）組成：

交易結構：
═══════════════════════════════════════════════════════

版本號（4 位元組）：
- 標識交易格式版本
- 大多數交易使用版本 1 或 2

輸入數量（1-9 位元組）：
- VarInt 表示輸入數量
- 單筆交易可包含數百個輸入

輸入列表：
- 前置交易雜湊（32 位元組，反向順序）
- 前置輸出索引（4 位元組）
- 輸入腳本長度（1-9 位元組）
- 解鎖腳本（SigScript）
- 序列號（4 位元組）

輸出數量（1-9 位元組）：
- VarInt 表示輸出數量
- 比特幣最小輸出為 546 satoshi

輸出列表：
- 輸出金額（8 位元組，satoshi 為單位）
- 輸出腳本長度（1-9 位元組）
- 鎖定腳本（ScriptPubKey）

鎖定時間（4 位元組）：
- 0 表示立即生效
- > 0 表示區塊高度或 UNIX 時間戳

輸入與輸出的具體格式

交易輸入需要引用之前的 UTXO（未花費交易輸出）：

輸入格式詳解：

TXID（32 位元組）：
- 前置交易的 SHA-256 雙重雜湊
- 比特幣使用小端序（Little-endian）編碼
- 實際存儲時需反轉字節順序

VOUT（4 位元組）：
- 前置交易中輸出的索引位置
- 第一個輸出為 0，第二個為 1，以此類推

SigScript（變長）：
- 包含簽章與公鑰
- 不同地址類型有不同格式：
  * P2PKH: <sig> <pubKey>
  * P2WPKH: <sig> <pubKey> (witness data)
  * P2TR: <sig> (witness data)

序列號（4 位元組）：
- 通常為 0xFFFFFFFF
- 較小值可用於 RBF（Replace-By-Fee）

輸出格式與腳本類型

輸出決定了比特幣的鎖定條件：

P2PKH 輸出：
────────────────────────────────────────
ScriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

輸出金額：8 位元組（satoshi）
腳本長度：25 位元組
腳本內容：76 A9 14 <20 bytes> 88 AC

P2WPKH 輸出（SegWit）：
────────────────────────────────────────
ScriptPubKey: OP_0 <pubKeyHash>

輸出金額：8 位元組
腳本長度：22 位元組
腳本內容：0020 <20 bytes>

P2TR 輸出（Taproot）：
────────────────────────────────────────
ScriptPubKey: OP_1 <tweakedPubKey>

輸出金額：8 位元組
腳本長度：34 位元組
腳本內容：5120 <32 bytes>

交易的序列化與大小計算

比特幣交易在網路傳輸時需要正確序列化：

交易序列化格式：

普通交易（非 SegWit）：
- 版本號：4 位元組
- 輸入數量：1-9 位元組
- 輸入列表：~148-180 位元組/輸入
- 輸出數量：1-9 位元組
- 輸出列表：~34-44 位元組/輸出
- 鎖定時間：4 位元組
- 總大小：~100-1000+ 位元組

SegWit 交易：
- 基礎交易：與普通交易類似
- Witness 數據：
  * 輸入數量標記
  * 每個輸入的 witness 堆疊
  * Witness 資料不計入原始大小，但計入 vsize

vsize（虛擬大小）計算：
vsize = 基礎大小 × 3 + 總大小 / 4

範例：
- 典型 P2WPKH 輸入：~105.5 vbytes
- 典型 P2WPKH 輸出：~31 vbytes
- 1 輸入 2 輸出交易：~140-150 vbytes

簽章過程與交易有效性

交易在廣播前必須經過正確的簽章過程。

簽章類型與 Sighash 標誌

比特幣支援不同的簽章類型，決定了簽章覆蓋的交易範圍：

Sighash 類型：

SIGHASH_ALL（0x01）：
- 簽章涵蓋所有輸入與輸出
- 最常用的簽章類型
- 確保交易內容不可更改

SIGHASH_NONE（0x02）：
- 簽章涵蓋所有輸入，不涵蓋任何輸出
- 允許任何人選擇輸出
- 用途：捐款、霧運算

SIGHASH_SINGLE（0x03）：
- 簽章涵蓋所有輸入與對應索引的輸出
- 其他輸出的數量必須為 0
- 用途：特定輸出保護

ANYONECANPAY 修飾符（0x80）：
- 可與上述三種類型組合
- SIGHASH_ANYONECANPAY：只簽章當前輸入
- 允許其他人添加更多輸入
- 用途：CoinJoin、部分簽章交易

ECDSA 簽章流程

傳統比特幣交易使用 ECDSA 簽章：

ECDSA 簽章過程：

1. 交易資料準備
   - 創建交易框架（不含 SigScript）
   - 為每個輸入添加 SigScript 空間
   - 序列化交易

2. Sighash 計算
   - 將交易轉換為 Sighash 格式
   - 加入 sighash 類型標誌
   - 計算 SHA-256(SHA-256(sighash))

3. 私鑰簽章
   - 選擇隨機 nonce (k)
   - 計算 r = (k×G).x mod n
   - 計算 s = k⁻¹(hash + d×r) mod n
   - 輸出 (r, s) 簽章對

4. DER 編碼
   - 將 (r, s) 轉換為 DER 格式
   - 添加 sighash 類型
   - 產生最終的 SigScript

交易延展性問題

交易延展性（Transaction Malleability）是比特幣長期存在的問題：

延展性問題描述：

問題本質：
- 簽章數學特性允許第三方修改簽章的外觀
- 交易的 TXID（雜湊值）會因此改變
- 但交易本身仍然有效

延展性來源：
1. 非 DER 編碼簽章
   - DER 標準要求嚴格格式
   - 但 Bitcoin Core 曾接受非標準編碼
   
2. Witness 數據
   - SegWit 前，witness 未隔離
   - 第三方可修改 witness 產生新 TXID

3. ScriptSig 中的额外数据
   - OP_PUSHBYTES 可以在簽章後添加數據

SegWit 解決方案：
- Witness 資料與交易主體分離
- 簽章只覆蓋交易主體
- 第三方無法透過修改 witness 改變 TXID

交易的網路傳播

交易建立後需要廣播到比特幣網路。

P2P 網路協議

比特幣使用點對點協議進行節點間通信：

比特幣 P2P 協議基礎：

連接建立：
1. 節點發現：DNS 種子或已知節點列表
2. 版本交換：protocol version、services、timestamp
3. Verack：確認版本相容性
4. 建立加密連接（可選）

消息類型：
- version：版本資訊交換
- verack：版本確認
- getaddr：請求節點列表
- addr：節點位址列表
- inv：庫存通知（區塊、交易）
- getdata：請求特定數據
- tx：交易消息
- block：區塊消息
- merkleblock：梅克爾區塊（SPV 用）
- filterload/setfilter：布隆過濾器（SPV 用）

交易傳播流程：
1. 錢包/節點創建交易
2. 透過 mempool 子系統驗證
3. 發送 inv 消息（庫存通知）
4. 接收節點請求 getdata
5. 發送 tx 消息
6. 接收節點驗證並本地保存
7. 繼續傳播（gossip）

交易驗證標準

節點在接受交易前必須通過多層驗證：

交易驗證清單：

基本結構驗證：
□ 交易格式正確
□ 版本號有效
□ 輸入/輸出數量在允許範圍內
□ 鎖定時間有效
□ 序列化後大小 < MAX_BLOCK_SIZE

輸入驗證：
□ 每個輸入引用的交易存在
□ 引用的輸出存在且未花費
□ ScriptSig 可以解鎖 ScriptPubKey
□ 總輸入金額 >= 總輸出金額
□ 無重複輸入

腳本驗證：
□ 所有腳本操作有效
□ 堆疊狀態正確
□ 簽章驗證通過
□ 無腳本執行錯誤

共識規則：
□ 隔離見證格式正確（如適用）
□ Taproot 腳本驗證（如適用）
□ Coinbase 規則（如適用）

交易傳播時間

交易在網路中傳播的速度取決於多個因素：

傳播延遲因素：

網路拓撲：
- 節點數量：~50,000-65,000 個全節點
- 平均連接數：每節點約 8-12 個連接
- 全網路傳播時間：通常 < 3 秒

節點性能：
- 驗證速度
- 網路頻寬
- CPU 處理能力

交易特性：
- 交易大小
- 費用高低（高費用交易優先傳播）
- 是否包含隔離見證數據

估計時間：
- 50% 節點收到：< 1 秒
- 95% 節點收到：1-3 秒
- 99% 節點收到：3-10 秒

記憶池（Mempool）機制

記憶池是比特幣網路中尚未確認交易的臨時存放區。

記憶池的運作原理

每個比特幣全節點都維護自己的記憶池：

記憶池資料結構：

記憶池大小：
- 通常包含數千到數十萬筆交易
- 受區塊空間需求影響
- 有最大記憶體限制（預設 300MB）

交易存放格式：
- 交易元數據：
  * 交易 ID（TXID）
  * 交易大小（bytes）
  * 費用（satoshi）
  * 費率（sat/vB）
  * 進入時間
  * 依賴交易列表
- 交易本身（已驗證的交易資料）

記憶池維護：
- 定期清理超時交易（預設 336 小時）
- 費用率排序（用於區塊模板）
- 依賴關係追蹤（CPFP）

費用市場機制

比特幣費用市場決定交易的確認優先順序：

費用率計算：

費率表達式：
- sat/vB（satoshi per virtual byte）
- sat/kVB（satoshi per kilo virtual byte）
- 兩者等價：1 sat/vB = 1000 sat/kVB

計算範例：
交易大小：150 vbytes
費用：3000 satoshi
費用率：3000 / 150 = 20 sat/vB

費用率與確認時間：
- > 100 sat/vB：下一個區塊
- 50-100 sat/vB：1-3 個區塊
- 20-50 sat/vB：3-6 個區塊
- 10-20 sat/vB：1-2 天
- < 10 sat/vB：超過一週或卡住

區塊空間需求與費用波動

比特幣區塊空間是稀缺資源，費用隨需求波動：

區塊空間統計（2025-2026）：

區塊容量：
- SegWit 前：1 MB 硬上限
- SegWit 後：~1.5-4 MB/區塊（加權計算）
- 平均區塊大小：~2-3 MB

日均區塊空間：
- 每天約 144 個區塊
- 總空間：~430 MB/天
- 實際使用率波動：40-95%

費用波動因素：
1. 網路活動週期
   - 亞洲白天高峰
   - 美國交易日高峰
   - 減半前後波動

2. 機構活動
   - 大額轉帳
   - 交易所批次處理
   - ICO/代幣活動

3. 特殊事件
   - 市場大幅波動
   - 熱門 NFT 鑄造（Ordinals）
   - 礦難影響算力

費用估算演算法

比特幣錢包使用多種費用估算策略：

費用估算方法：

歷史百分位法：
- 分析過去 N 個區塊的交易費用
- 計算不同確認時間的費用百分位
- 選擇符合目標的百分位

費用率模擬：
- 根據記憶池狀態模擬未來區塊
- 考慮費用率分佈
- 計算不同費率交易的排隊位置

實際費用市場：
- mempool.space API
- Bitcoin Core RPC
- 第三方服務（BlockCypher、CoinStats）

常見問題：
- 費用估算落後於市場變化
- 記憶池清空時估計失準
- 區塊發現時間波動

交易加速與費用調整

當交易卡在記憶池時，有多種解決方案。

RBF（Replace-By-Fee）

RBF 允許用更高費用的交易替換原有交易：

RBF 機制：

啟用 RBF：
- 交易的序列號 < 0xFFFFFFFE
- 原交易未進入區塊
- 新交易費用更高

RBF 類型：

1. Full RBF（BIP 125）：
   - 可添加新輸入/輸出
   - 費用必須顯著更高
   - 礦工選擇性接受

2. Opt-In RBF：
   - 交易包含 BIP 125 信號
   - 費用率至少提高 1 sat/vB
   - 錢包軟體廣泛支援

費用增加計算：
- 絕對費用增加
- 費用率增加（推薦）
- 通常需要增加 1.1-2 倍

CPFP（Child Pays for Parent）

CPFP 透過花費記憶池中的未確認交易來加速：

CPFP 運作原理：

概念：
- 子交易費用激勵礦工確認父交易
- 總費用 = 父交易費用 + 子交易費用

實施步驟：
1. 識別記憶池中未確認的交易
2. 使用其中一個輸出創建新交易
3. 新交易設置較高費用
4. 礦工為賺取總費用會打包兩筆

費用計算：
CPFP 總費用率 = (父費用 + 子費用) / (父大小 + 子大小)

限制：
- 需要控制未確認交易的輸出
- 子交易必須在記憶池中
- 總費用必須足夠高

第三方加速服務

部分機構提供交易加速服務：

加速服務類型：

1. 礦池加速：
   - 與大型礦池合作
   - 直接將交易加入區塊模板
   - 通常免費或收費

2. 費用補貼：
   - 添加新輸入增加費用
   - 需要控制錢包
   - 類似 CPFP

3. RBF 加速：
   - 幫助廣播更高費用的替換交易
   - 錢包需支援 RBF

知名服務：
- ViaBTC 加速器
- AntPool 加速器
- Bitcoin Accelerated

記憶池監控與分析工具

監控記憶池狀態有助於優化交易策略。

RPC 命令監控

Bitcoin Core 提供豐富的記憶池查詢功能：

常用記憶池 RPC：

getmempoolinfo：
{
  "loaded": true,
  "size": 14235,
  "bytes": 15892420,
  "usage": 67543210,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00001000,
  "minrelaytxfee": 0.00001000,
  "unbroadcastcount": 0
}

getrawmempool：
- 返回記憶池中所有交易
- 可選擇費用詳細資訊
- 每分鐘更新

getmempoolentry：
- 查詢特定交易的詳細資訊
- 包括費用、時間、依賴關係
- 用於追蹤特定交易

getmempoolancestors / getmempooldescendants：
- 查詢交易的祖先/後代交易
- 分析 CPFP 可能性

第三方記憶池瀏覽器

線上工具提供視覺化記憶池數據：

主要記憶池瀏覽器：

mempool.space：
- 即時記憶池視覺化
- 費用估計工具
- 交易追蹤
- 區塊空間市場分析

Blockchain.com：
- 記憶池統計
- 費用建議
- 交易狀態查詢

Blockstream.info：
- 即時記憶池數據
- 費用預測
- API 存取

數據類型：
- 記憶池大小（交易數/位元組）
- 費用分佈圖
- 區塊空間需求趨勢
- 待確認交易列表

交易確認狀態追蹤

追蹤交易狀態是確保比特幣轉帳成功的關鍵。

確認機制

比特幣交易的確認基於區塊挖礦：

確認流程：

第一個區塊確認：
- 交易被礦工選中
- 進入區塊並廣播
- 交易狀態：1 confirmation

後續確認：
- 每個新区块在链上添加
- 確認次數遞增
- 6 個確認通常視為不可逆

確認數量與安全：
- 1 確認：基本確認
- 3 確認：適合小額交易
- 6 確認：適合大額交易
- 更多確認：極高安全性

雙花風險：
- 理論上 6 個確認後雙花不可能
- 攻擊成本隨確認數增加

交易失敗與處理

了解交易失敗原因有助於解決問題：

常見交易問題：

1. 費用過低：
   - 交易停留在記憶池
   - 解決：RBF 或 CPFP

2. 記憶池飽和：
   - 交易被驅逐
   - 解決：提高費用重新廣播

3. 雙花檢測：
   - 相同輸入的衝突交易
   - 先廣播的交易優先

4. 輸入無效：
   - 引用的輸出已花費
   - 交易失敗，需重新創建

5. 腳本錯誤：
   - ScriptPubKey 不匹配
   - 技術性問題，需專業協助

參考資料與數據來源：

• Bitcoin Developer Guide - Transactions: https://developer.bitcoin.org/devguide/transactions.html
• Bitcoin Core RPC Documentation
• mempool.space API Documentation
• 數據截止日期：2026 年 3 月

費用市場數據說明：

• 費用率數據基於 mempool.space 即時 API
• 區塊空間使用基於 Bitcoin Core 統計
• 網路節點數據基於 multiple block explorer 估算