Bitcoin Core 已發布 CVE-2025-62861 的官方揭露報告，這是節點軟體交易轉播邏輯中的高嚴重性缺陷，可能導致礦工在過期的區塊模板上持續進行雜湊運算，且沒有任何明顯警訊。該公告將問題的發現歸功於安全研究員 Niklas Goegge，並指出根源在於一條在錯誤時機觸發的轉播規則：在鏈重組期間，它本應保持沉默。

受影響版本涵蓋 Bitcoin Core 28.0 至 28.2，以及 29.0 至 29.1。修復已於 2025 年 10 月發布，但依據該專案的協調揭露政策，完整技術細節直到 2026 年 11 月才對外公布。公告中未提及任何事故或受影響的營運者；風險屬於歷史性質。指向處於損壞狀態節點的礦機會持續進行雜湊運算，但依據的是最後收到的模板，因此新交易及其手續費在有人察覺之前都無法被收取。

鏈重組如何使交易失去父輩

鏈重組發生在節點放棄其當前鏈頂、改用另一條競爭且更重的分支時。被斷開區塊中的交易仍然有效，因此 Bitcoin Core 會將它們放回記憶體池，也就是未確認交易的暫存區。由於這些交易已在有效區塊中確認過，節點會以名為 bypass_limits 的旗標重新加入它們，該旗標會關閉一般的反垃圾與拓撲檢查。其目的在於忠實還原交易池，而非重新審判已通過共識的交易。

其中一項本應被關閉的檢查涉及第三版本（即 TRUC）交易。依據 BIP 431，一筆 TRUC 交易最多只能有一筆未確認的父交易與一筆未確認的子交易。這是轉播政策而非共識規則：區塊中可以合法地包含一筆擁有多個子交易的 TRUC 父交易，即使沒有節點會從網路接受這種形態進入自己的記憶體池。政策與共識之間的這條界線，也正是此漏洞影響範圍的界線：CVE-2025-62861 可能損壞節點的記憶體池並使其模板輸出停擺，但無法產出無效區塊或改變鏈的規則。

自 28.0 版本起，Bitcoin Core 透過一種稱為兄弟驅逐（sibling eviction）的機制來執行單一子交易限制。當一筆新交易會使 TRUC 父交易擁有第二筆未確認子交易時，節點會將現有的子交易視為替換候選，若新來者支付足夠的手續費，便依取代付費（replace-by-fee）規則將其驅逐。

漏洞在於：即使設定了 bypass_limits，兄弟驅逐仍會執行。一場重組若還原了一筆擁有多個子交易的 TRUC 父交易——這種形態在斷開的區塊中完全有效——可能觸發驅逐其中一筆被還原的交易，而花費其輸出的交易仍留在池中。記憶體池於是持有了一些子交易，其父交易已不存在於任何地方：不在鏈上，也不在池中。

Greg Sanders 的修復將 TRUC 檢查以 bypass_limits 加以門控，因此在重組還原期間不再執行驅逐。相關的拉取請求 PR #33504 也補上了原始程式碼所缺少的測試場景：交易來自被斷開的區塊而非來自對等節點。

從礦工角度看模板停擺

節點透過 getblocktemplate 將工作交給挖礦軟體，該呼叫會組裝候選區塊、執行節點自身的有效性檢查，並回傳前一區塊雜湊值、所選交易與下一個區塊高度。當池中存在無父交易時，組裝出的候選區塊無法通過該檢查，因此該呼叫無法回傳新工作。

從外部看，節點顯得健康：

• 程序正在執行
• 對等連線開啟
• 鏈頂持續推進
• 記憶體池接受新交易

實際損壞之處：

• 模板請求回傳錯誤
• 雜湊器持續對過期工作運算
• 當前鏈頂上無法找到任何區塊
• 此狀態持續到節點重新啟動為止

一般監控儀表板所關注的指標全都會維持綠燈。網路也不會回傳任何訊號：鏈頂持續推進——區塊仍被找到，只是不來自這個礦場——因此成本完全落在停擺的礦工身上：雜湊運算無法在當前鏈頂上產出區塊，原本可收取的手續費也隨之流失。礦工向節點需要的唯一一樣東西——最新的模板——正是它停止產出的那一樣。

重啟、修補與終止支援

重新啟動節點會以一致狀態從磁碟重新載入記憶體池，從而清除症狀。但這無助於解決成因：下一次帶有相同交易形態的重組仍可能再次使節點停擺。

根本缺陷已在三個版本中移除。30.0 版本於 2025 年 10 月 10 日隨修復發布，回移植版本 29.2 與 28.3 也相繼推出。從私下報告到最後一個版本發布歷時三週：

兩個回移植分支此後均已終止支援。Bitcoin Core 的維護政策涵蓋最近三個主要版本——目前為 30.x、31.x 與 32.x——而 29.x 已於 2026 年 10 月 27 日終止支援。當初僅以重新啟動回應故障、而未採取其他措施的營運者，如今運行的是不受支援的程式碼，而觸發該問題的交易形態描述已公開在眾人眼前。

為何公告延遲了 396 天

從第一個修復版本到詳細公告歷時 396 天，且公告恰好在 29.x 終止支援兩週後發布。兩個數字都非巧合。Bitcoin Core 的揭露政策將中高嚴重性細節保留至最後一個受影響版本不再受支援後兩週，並在其兩週前發布預告，時機配合新的主要版本發布。

保密協議涵蓋的是說明而非程式碼。該拉取請求自 2025 年 9 月 29 日起即已公開，28.3 與 29.2 的發布說明當時也列出了記憶體池修復。保密一年的是將修補與可重現的挖礦停擺連結起來的技術說明。

該政策確實提供了一條更快的途徑。被歸類為易於發現的漏洞——專案對此的定義是以極少心力即可找到——可立即發布點版本與公告，不受保密限制。此案走的是標準時程，因此維護者並不認為它容易被發現。它與另外兩則中高嚴重性公告於同日發布，分別涉及區塊處理停擺與 Tor 權限錯誤；三者均在同一個 2025 年 10 月的發布週期中修復。因此，任何新到足以包含該記憶體池修補的版本，也同樣包含另外兩項修復。

較慢的途徑本身蘊含著一項假設：營運者會在長達一年的時間窗口內完成升級，因此當觸發條件被公開描述時，已無易受影響的對象還在監聽。

該監控什麼，而非僅看線上狀態

對挖礦作業而言，有用的檢查不是節點是否存活，而是其最近一次成功取得的模板有多舊。一個正在執行、已連線且已同步的程序，仍可能已停止交付工作，而這個漏洞正是讓這種情況無聲發生的途徑之一。建置版本應納入同一項檢查，因為今天模板仍是最新的節點，明天可能就已失去支援。

備用模板來源也應接受相同的質疑。使用相同版本與相同記憶體池政策的故障轉移節點，會遇到同樣的重組與同樣的停擺；兩個執行中的程序並不代表兩個獨立的工作來源。只有運行不同、已修補建置的節點才能讓作業持續挖礦，而且只有事先在模擬重組下測試過的營運者，才會預先知道這一點。