比特幣下一次軟分叉最可能不是新功能,而是一份「清理」:BIP-54(Consensus Cleanup,共識清理)。依 crypto.news 11 月 5 日轉述 Decrypt 11 月 4 日的報導,Bitcoin Core 開發者 Matt Corallo 估計它有約 80% 的機率成為下一次軟分叉;BIP-54 規格已在 2026 年 5 月 22 日標為完整(Complete),但沒有啟用日期。今天拆解它修補的四個舊漏洞:時間扭曲、超慢區塊、64 位元組交易與重複 coinbase,看每一條規則的數字與取捨。
讀到的程度:BIP-54 規格本文與 crypto.news 的文章,我讀的是抓取工具整理的摘要,非逐字原文;Decrypt 原訪談、Bitcoin Core 參考實作與測試向量我沒有打開。規格中「約 40 倍」「38 天」等數字是規格作者的估計,我沒有自己驗證;標明「自算」的才是我算的。
📖 學
一、時間扭曲:區塊時間戳可以被多數算力往回拖
比特幣每 2016 個區塊依這段期間花的時間調整難度,目標是 10 分鐘一個區塊,也就是一期約 14 天(自算:2016 × 600 秒 = 1,209,600 秒)。漏洞在於調整只看「期首區塊與期末區塊的時間戳差」,而時間戳本身只受鬆散限制。擁有多數算力的礦工可以讓時間戳慢慢往前爬得比實際慢,系統就以為出塊太慢,難度調降;依規格的說法,在極端情況下難度約 38 天內可降到最低。
BIP-54 的修補很小:在期首區塊(高度 N 滿足 N 除以 2016 餘 0)要求時間戳不得比前一個區塊早超過 7200 秒(兩小時寬限);在期末區塊(餘 2015)要求時間戳不得早於該期第一個區塊。規格說明選兩小時寬限是求保守,代價是攻擊情境下預期出塊間隔多約 2.2 秒(相較於十分鐘寬限)。這條規則同時處理了規格中提到的 Murch-Zawy 問題。因為只是收緊既有規則,舊節點照樣能驗證新規則下產生的區塊。
二、超慢區塊:限制每筆交易的舊式簽章運算數
某些精心構造的區塊,用大量舊式腳本(legacy 與 P2SH)的簽章運算與雜湊,可以讓驗證在強力電腦上花數分鐘、較弱的機器上花數小時,這會讓節點被拖住。BIP-54 的做法不是禁用任何腳本功能,而是限制單筆交易(coinbase 除外)最多 2500 次簽章運算(sigops)。計法依 BIP-16:CHECKSIG 與 CHECKSIGVERIFY 各算 1 次;CHECKMULTISIG 前面若是 OP_1 到 OP_16 就算 1 到 16 次,其他情況算 20 次;計入範圍涵蓋 scriptSig、scriptPubKey 與 P2SH 的 redeemScript。
規格宣稱這可把最壞情況的驗證時間降低約 40 倍,並說 2500 是「不會讓非病態的標準交易失效」的最緊上限。自算一個直觀感受:若每個 CHECKMULTISIG 都按 20 次算,單筆交易最多放 125 個(2500 除以 20);這遠超正常用途,所以一般錢包不受影響。
三、64 位元組交易:讓輕量客戶端被假的包含證明騙
比特幣區塊的 Merkle 樹內部節點,是把兩個 32 位元組雜湊接起來再雜湊,也就是剛好 64 位元組的資料(自算:2 × 32 = 64)。若一筆交易去除見證資料後的序列化大小也剛好是 64 位元組,它的內容有可能被解讀成一個內部節點,攻擊者便可能對 SPV 輕量客戶端偽造「某筆交易已在區塊中」的證明。BIP-54 的修補是直接宣告這種大小的交易無效。
規格指出,這種交易只能放任何人可花或銷毀資金的輸出,自 2019 年起就是非標準交易,2016 年後也沒再被使用,所以實際影響很小;作者考慮過其他繞過方法,最後選擇從根源修補。
四、重複 coinbase:用 nLockTime 讓每個 coinbase 都獨一無二
歷史上比特幣出現過重複 coinbase 交易的問題,後來靠 BIP-30 在驗證時額外檢查來避免,這個檢查要持續維護,也會妨礙像 Utreexo 這類不存完整 UTXO 集合的設計。BIP-54 要求 coinbase 的 nLockTime 必須等於區塊高度減 1,且 nSequence 不得為 0xffffffff,讓每個 coinbase 因為包含高度而不可能重複,啟用後就不必再做 BIP-30 檢查。crypto.news 提到,依這個設計,未來最早可能出現重複的高度是 1,983,702。
規格也坦承取捨:nLockTime 欄位原本有些 ASIC 控制器拿來當額外的 extranonce(挖礦用的可變欄位),之後就不能這樣用,礦池要確認自己的 coinbase 構造符合新規則;依 crypto.news,Bitcoin Core 29.0 與 30.0 的區塊模板已有與部分限制相容的保護。
五、為什麼爭議不在技術,而在「值不值得為純維護動共識」
批評主要來自 LayerTwo Labs 的 Paul Sztorc,他在 X 上說啟用前景「有點令人沮喪」,理由是這是純維護、沒有新功能。依 crypto.news,他在亞特蘭大 TABconf 訪問的開發者普遍預期 BIP-54 會是下一次軟分叉,最早預測的啟用時間是 2027 年 9 月,多數人預期 2028 年或更晚。Corallo 的看法則是這是「我們知道、而且確實該清掉的一長串清單」,並認為這個流程也許能幫助未來處理啟用分歧。另一個背景是 BIP-110(暫時限制非支付資料)的訊號極少,有監測服務記錄自 5 月 1 日起 9,000 多個區塊中只有 38 個發出訊號,這是同一篇與周邊報導提到的對照,我沒有核實該監測數字。
🧠 記
- 一句話: BIP-54 把四個已知舊漏洞一次收緊,屬於相容舊節點的軟分叉,規格完整但無啟用日期。
- 時間扭曲: 每期期首區塊時間戳不得比前一塊早超過 7200 秒;期末區塊不得早於該期首塊;原攻擊約 38 天可把難度壓到最低(規格估計)。
- sigops: 每筆交易(coinbase 除外)最多 2500 次;CHECKMULTISIG 預設算 20 次;最壞驗證時間約降 40 倍(規格估計)。
- 64 位元組: 去見證大小剛好 64 位元組的交易無效,堵住 SPV 偽造包含證明。
- coinbase: nLockTime 等於高度減 1、nSequence 不得為 0xffffffff,可省掉 BIP-30 檢查。
- 時程與爭議: 最早預測 2027 年 9 月,多數預期 2028 年後;批評點是沒有新功能。
- 邊界: 我讀的是規格摘要與媒體摘要,沒讀參考實作與 Decrypt 原文。
✍️ 實踐
全部唯讀,約 25 分鐘。
- 自己算一次:若時間戳每期少「前進」兩小時以內(7200 秒),相對於一期 1,209,600 秒是多少比例?再想想為什麼規則只管期首與期末兩個區塊(約 5 分鐘)。
- 讀 BIP-54 規格的 sigops 計法,拿一個 2-of-3 的 P2SH 多簽(腳本內是 OP_2 開頭)與一個沒有前置數字的 CHECKMULTISIG,各算它被計幾次(約 10 分鐘)。
- 把四條規則各寫成「攻擊者能做什麼、規則怎麼擋、誰的軟體要改」三格表,礦池與錢包欄位寫「未載明」就照實寫(約 10 分鐘)。
可證偽預測(台北時間):
- 預測一: 2026 年 12 月 31 日前,BIP-54 在 Bitcoin Core 合併進正式發行版本並含任何啟用參數 5%。
- 預測二: 2026 年 12 月 31 日前,有任何 BIP-54 的啟用機制提案(例如 BIP 8 或 BIP 9 風格參數)被公開寫成正式 BIP 草案 20%。
- 預測三: 2027 年 12 月 31 日前,BIP-54 在比特幣主網實際啟用 25%。
🔗 延伸學習
- BIP-54: Consensus Cleanup(bitcoin/bips):讀到摘要,四條規則的數字與理由來源。
- Bitcoin’s next upgrade: BIP-54 could fix four longstanding flaws(crypto.news):讀到摘要,Corallo 80% 與 Sztorc 批評、時程預測來源。
- BIP-110 enters mandatory signaling(Cointelegraph):只看到搜尋結果標題,沒有打開,作為 BIP-110 背景的入口。
💬 問 AI
我在學比特幣 BIP-54(Consensus Cleanup)。我讀的是規格與 crypto.news 報導的摘要,沒讀 Bitcoin Core 參考實作與 Decrypt 原訪談。
我目前的理解(請逐條檢查):
- 時間扭曲:期首區塊時間戳不得比前一塊早超過 7200 秒,期末區塊不得早於該期首塊;原攻擊約 38 天可把難度壓到最低。
- sigops:每筆非 coinbase 交易最多 2500 次,CHECKMULTISIG 前有 OP_1 到 OP_16 算 1 到 16 次,否則算 20 次;最壞驗證時間約降 40 倍。
- 去見證大小剛好 64 位元組的交易無效,因為可能被誤當 Merkle 內部節點。
- coinbase 的 nLockTime 等於高度減 1、nSequence 不得為 0xffffffff,可省 BIP-30 檢查。
請幫我:
(a) 用具體數字走一遍時間扭曲攻擊:每期如何把時間戳往回拖、難度如何下降,並說明 7200 秒寬限在其中的作用;
(b) 舉兩個合法的標準交易,算它們在新 sigops 規則下的計數,說明為何不受影響;
(c) 說明 64 位元組交易如何偽造 SPV 包含證明,以及為何不用別的方式(例如在 SPV 端檢查樹深度)修補;
(d) 每個結論標示「來源說的」、「你另外查到的(附網址)」、「你的推論」,不要編造連結、日期、數字。
這是學習用,不要給投資建議。