內存池最低費率門檻全解析：比特幣交易手續費不足為何一直未確認

按下發送按鈕後，錢包跳出「交易已廣播」，區塊瀏覽器也給出了一串 txid。然而十分鐘過去、數小時過去，狀態欄依舊卡在「未確認」。回頭檢查手續費，設定的費率可能是 1.8 sat/vB，而此刻節點的內存池最低費率門檻已經攀升至 4 sat/vB 以上。這筆交易沒有損壞，只是暫時失去了被節點轉發或被礦工打包的優先級。

比特幣交易長期滯留未確認，背後的原因往往不僅僅是「網絡擁堵」四個字。內存池最低費率門檻是一個動態變化的數值，由單個節點的政策參數、本地記憶體的即時佔用量，以及全網交易需求的起伏共同塑造。理清這套機制的運作邏輯，就能準確判斷交易當前的真實狀態並採取相應的補救手段。

內存池不是全網統一的單一佇列

理解最低費率門檻前，需要釐清一個核心概念：比特幣網絡中並不存在一個中央統一的「待確認交易總排隊庫」。實際上，每個完整節點（Full Node）都在各自的記憶體中獨立維護一份待確認交易池，這便是內存池（mempool）。廣播一筆交易時，周邊節點接收、驗證並放入本地內存池，隨後向其他節點轉發，整個傳播過程不存在中心調度。

這導致了一個直接現象：同一筆交易可能已進入節點 A 的內存池，卻因配置不同而被節點 B 拒之門外。不同節點的記憶體上限、准入門檻與驅逐策略各自獨立。區塊瀏覽器呈現的內存池數據，本質上是該服務商自建節點或聚合採樣節點的視角，並非全網絕對統一的狀態。

礦工在構建區塊模板時，通常從自己運行的節點內存池中挑選收益最高的交易。因此，一筆交易能否被順利打包，取決於它是否成功進入算力節點的內存池，以及在該池中的費率排序是否靠前。

最低費率門檻的兩層結構解析

所謂的「門檻」在比特幣節點底層被清晰地拆分為靜態底線與動態准入門檻兩層，兩者的觸發機制與處理方式截然不同。

第一層：節點的靜態中繼底線（-minrelaytxfee）

Bitcoin Core 節點客戶端內建了啟動參數 -minrelaytxfee，代表節點願意接收並轉發一筆交易的最低費率底線。在歷史版本中，官方默認值長期保持在 1000 sat/kvB（即 1 sat/vB）。隨著客戶端演進（如 Bitcoin Core 30.0 起透過 PR #33106 調整），默認中繼費率底線已進一步下調至 0.1 sat/vB（100 sat/kvB）。

這項參數由節點營運者自行配置，有人維持默認，有人主動調高或調低。低於特定節點中繼底線的交易，會被該節點直接丟棄且不予轉發，並拋出 min relay fee not met 錯誤。

需要注意的是，門檻考核的是虛擬費率（sat/vB）而非絕對手續費總額。若一筆交易包含大量輸入導致虛擬大小（vSize）達到 2000 vB，即便支付了 0.00001 BTC（1000 sat）的手續費，折算費率僅有 0.5 sat/vB，依然會被要求 1 sat/vB 底線的節點直接攔截。

第二層：動態准入門檻（mempoolminfee）

即便交易費率高於靜態底線，在網絡繁忙時也不必然能留在池中。Bitcoin Core 默認設置的內存池容量上限通常為 -maxmempool=300（300 MB）。當待確認交易佔用達到該上限時，節點會啟動驅逐機制，優先淘汰費率最低的交易以釋放記憶體。

為了防止被淘汰的低費率交易反覆湧入消耗系統資源，節點會動態調高准入門檻，即 mempoolminfee。依據 Bitcoin Core 的 RPC 機制，節點即時准入門檻取 -minrelaytxfee 與當前動態計算值中的較大者。該動態門檻會隨著池內空間的釋放逐步遞減，但具有一定的滯後保護期。

節點政策（Policy）與共識規則（Consensus）的邊界

交易被節點拒絕轉發，並不等於違反了比特幣的共識規則。共識規則是全網嚴格遵守的底層標準（決定區塊與交易是否合法有效），而節點轉發政策則是單個節點在區塊確認前用以保護自身硬體資源的過濾策略，最低費率門檻便屬於此類政策。

這意味著：一筆費率極低、被公網多數節點拒絕中繼的合法交易，只要直接提交給礦池，在共識層面依然可以被合法打包進區塊。不同版本客戶端的政策參數具備靈活性，因此「即時准入門檻」是一個隨網絡供需波動的市場數據。

比特幣交易長時間未確認的常見成因

1. 費率滿足准入門檻，但不足以競價入塊

比特幣單個區塊的權重上限為 4,000,000 WU（約折合 1 vMB 空間），大約每十分鐘產出一個區塊。礦工在經濟利益驅動下，會優先挑選費率最高的交易填滿區塊。若支付的費率處於內存池底部，即便已入池，也需要等待前方高費率交易被消耗完畢後才有機會確認。

2. 遭遇節點內存池驅逐（Eviction）

交易在廣播初期費率尚可，但隨後鏈上活動激增導致內存池爆滿，節點開始清理池底交易。被驅逐後，交易在該節點的記憶體中不復存在。由於各節點負載差異，可能出現部分節點仍有記錄、部分節點查無此筆交易的情況。

3. 本地廣播未實質成功

部分錢包在網路切換、節點連線中斷或簽名後廣播失敗時，本地介面可能已記錄「已發送」，但交易數據並未真正抵達公網節點。在多個公開區塊瀏覽器均檢索不到 txid 時，通常屬於廣播未成功。

4. 達到內存池過期時限（Expiry）

Bitcoin Core 默認設置了 -mempoolexpiry=336（即 14 天 / 336 小時）的保留時間。未被確認且未被驅逐的交易在超過該時限後，會被節點從內存池中徹底移除。部分錢包若未及時同步此狀態，可能會持續鎖定對應的 UTXO。

加速與補救方案：RBF、CPFP 與交易包中繼

當交易因費率不足停滯時，可依據交易具體屬性選擇相應的鏈上加速工具。

RBF（Replace-By-Fee，費用替代法）

RBF 允許發送方利用相同的輸入 UTXO，重新簽名並廣播一筆費率更高的新交易，以覆蓋原交易。自 Bitcoin Core 28.0 起，全網默認廣泛支持 Full RBF（mempoolfullrbf=1）。新交易的費率必須高於原交易，且需支付足夠的增量中繼費用（Incremental Relay Fee）以彌補節點的頻寬消耗。

CPFP（Child Pays For Parent，子為父償）

若發送方未開啟 RBF 或收款方急需確認，可使用 CPFP。收款方或發送方花費該筆未確認交易產生的輸出（UTXO），建立一筆高費率的「子交易」。礦工為了獲取子交易的高額手續費，必須將「父交易」與「子交易」一同打包入塊。

計算範例：父交易大小為 400 vB，費率 2 sat/vB（手續費 800 sat）；子交易大小為 200 vB。若期望整個交易包的平均等效費率達到 10 sat/vB（總大小 600 vB，需總手續費 6000 sat），則子交易需支付的手續費為 6000 − 800 = 5200 sat，折合子交易自身費率為 26 sat/vB。

交易包中繼（Package Relay）的演進

在過去，若父交易費率低於節點的 minrelaytxfee 或動態准入門檻，父交易無法入池，導致子交易無法廣播。自 Bitcoin Core 28.0 引入「1 父 1 子」交易包中繼與 v3/TRUC 交易政策後，節點可以將父子交易視為整體進行費率評估，極大提升了極低費率交易透過 CPFP 脫困的可行性。

節點常見拒收錯誤訊息對照

交易卡單後的標準處置流程

1. 狀態核查：在多個區塊瀏覽器中輸入 txid。若完全查無記錄，表明交易未成功廣播，可直接在錢包內重新構建發送；若顯示未確認，確認當前池內費率分佈。
2. 優先採用原生 RBF：若原交易支援替換或節點開啟 Full RBF，直接在錢包內使用「加速交易 / 加價替換」功能，設定高於當前區塊打包中位數的費率。
3. 次選 CPFP 拉動：若無法使用 RBF 但錢包掌控未確認交易的找零輸出（或作為收款方），構建一筆高費率子交易將父交易一同拉入區塊。
4. 錢包相容性處置：若現有軟體不支援加速操作，應優先考慮將助記詞或公鑰匯入支援高級手續費控制的開源硬體錢包或桌面客戶端（如 Electrum / Sparrow），切忌隨意在不信任的在線網頁或第三方服務中輸入私鑰。
5. 被動等待過期：若不急於確認且無可用加速條件，可等待交易達到節點過期時限（默認 14 天）自內存池逐出，隨後在錢包中重置交易快取釋放 UTXO。

常見問題快速解答（FAQ）