作者：Antoine Poinsot
來源：https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710
最近我一直在回顧 Matt Corallo 的 “共識清理” 提議。我的興趣是弄清楚：
- 該提議想解決的那些 bug 有多嚴重；
- 被提議的修復措施，對最差情形的改善有多少；
- 多了 5 年的經驗之後，我們是否能做得更好；（譯者注：Matt 的提議是在 2019 年提出的。）
- 還有沒有別的東西，是值得解決的。
長話短說：我認為那些 bug 很糟糕。最差情形下的區塊驗證時間令人擔憂。我也認為，修復時間扭曲漏洞比人們通常認為的要重要得多。最後，我認為，我們可以包含一項修復，以避免在區塊高度 198 3702 後執行 BIP30 驗證；還有一項對傳統交易形式（legacy transactions，指的是隔離見證以前的交易形式）體積上限的額外限制，可以為區塊驗證時間提供有用的安全邊際。
我希望用這篇文章激發對共識清理提議希望解決的協議 bug 的討論。我希望手機對每一項擬議的緩解措施的評論和意見，以及對更多修復措施的潛在建議。關於區塊驗證時間的部分有大幅刪減：我會公開分享一些數字，但關於製作破環性區塊的策略的細節，我只會跟 Bitcoin Core 的常年貢獻者以及少數比特幣協議開發者分享。
時間扭曲漏洞
時間扭曲漏洞理由了難度調整週期不會重疊的特點。礦工通過將一個目標調整週期的最後一個區塊的時間戳儘可能往前撥（也就是現在的 2 個小時之後），同時將所有其它區塊的時間戳儘可能往後撥，就可以利用這一特點，人為降低難度。這個 stackexchange 的答案有更詳盡的解釋。
它有多糟糕？
考慮它到底如何讓情形惡化，以及它具體帶來了什麼，是有趣的事情。不管怎麼說，礦工們總是可以按住時間戳，不讓它推進，即時不利用時間扭曲漏洞。但如果不將一個難度調整週期的第一個區塊的時間戳設定得比上一週期最後一個區塊還要早，利用難度調整機制就必然會帶來挖礦難度的增加。反之，將一個週期的第一個區塊的時間戳設得比上一週期最後一個區塊要早，攻擊者就就可以在利用低難度（本局成果）的同時進一步降低難度。
實際上，攻擊者可以在開始這種攻擊的一個多月時間裡，就對網絡造成致命傷害。從時間點 t 、週期 N 開始發動攻擊，到週期 N+1 的末尾，攻擊者就已經可以讓難度降低一半。這又讓他們可以在一週內挖出週期 N+2 的所有區塊，進一步將難度降低 2.5 倍，等等。在少於 40 天的時間裡，攻擊者就可以讓難度降至 1，而已一下子可以挖出幾百萬個區塊。除了拿走剩餘所有的區塊補貼，這還會摧毀所有依賴於時間鎖的 L2 協議的安全性，並讓 DoS 攻擊界面惡化（比如，可以跟 UTxO 集的膨脹相結合）。
這裡忽略了 MTP（過往時間中值），因為它充其量只是攻擊者的一個小麻煩。不過，這也提出了一個問題：儘管這樣的攻擊以控制大部分挖礦算力為前提，小體量的算力是否可以嘗試伺機利用它的有利策略？比如，將一個調整週期的最後一個區塊的時間戳儘可能向前撥，而將所有其它區塊的時間戳（在 MTP 規則允許的範圍內）儘可能向後撥。技術上來說，這對礦工來說沒有（顯著）的代價，而 可能 會給他們（以及其它礦工）稍微多一點點區塊獎勵（以犧牲未來的礦工為代價）。事實證明，使用這樣的策略，對於任何小的挖礦算力來說，邊際收益都是微不足道的，所以我們可以合理預計，礦工不會嘗試相機而動地利用時間扭曲漏洞。
我們應該修復它嗎？
一些人主張，礦工們不會有意搬起石頭砸自己的腳。實際上，指望他們會殺死自己要挖的鏈是不顯示的。相反，他們可能會達成一種均衡，僅僅將出塊的速度提高 X% 。關於礦工有能力讓可用的區塊空間增加而不需要改變節點間的共識規則會帶來的政治影響，我交給讀者自行評判。但我們要指出的是，如果一個礦工的卡特爾（聯盟）可以通過利用時間扭曲漏洞來降低難度，即使只是輕微降低，也可以在幾周時間內就讓網絡持續處在崩潰的邊緣。
另一個常見的主張是，這並不緊急，因為攻擊很明顯，而且要花費很長時間。我非常懷疑需要用戶在身處的共識規則之外協調並決定某一高度的某個區塊的有效性的論證。此外，要協調和更改比特幣的共識規則，一個月並不算長。而且，如前所述，什麼不確定能不能形成這樣做的廣泛共識。用戶喜歡更低的手續費，礦工喜歡更多的補貼。給定當前對挖礦算力的控制分佈以及指數降低的區塊補貼，認為可能會形成一個嘗試利用時間扭曲漏洞的卡特爾並非無稽之談。
最後，一些人主張，還有人認為這不緊急，因為攻擊需要大部分挖礦算力的參與。我認為這太過輕敵。理由時間扭曲漏洞極大地增加了 51% 攻擊可以造成的傷害。原本 51% 攻擊 “只能” 暫時地審查交易。但用了時間扭曲攻擊，可以摧毀整個網絡。
我們能夠得出一個更好的修復措施嗎？
也許不能。被提議的修復措施是直截了當的：讓難度調整週期重疊。Matt 提出的變更是最簡單也最顯著的：用上一週期最後一個區塊的時間戳來約束本週期第一個區塊的時間戳。
最差情形下的區塊驗證時間
眾所周知，惡意製作的非隔離見證交易可以是極難驗證的。更長的區塊驗證時間可以讓礦工攻擊者獲得不公平的優勢，妨礙區塊在網絡中的傳播（及其一致性），甚至對依賴於區塊可得性的軟件造成有害的後果。為此，共識清理提議加入了對傳統腳本用法的幾個額外限制。
有多糟糕？
很糟糕。最差情況下，我可以得出一個在我的最新筆記本電腦的 16 核 CPU 上佔滿 CPU、花費 3 分鐘才能驗證的區塊；在樹莓派 4 上，要花 1.5 小時。出於明顯的理由，我在這裡刪減了這樣的區塊的細節，以及多種創建類似難以驗證的區塊的方法。我會用一種半私密的附件帖子跟其他協議開發者分享，用的是 Delving 的私密工作坊特性。如果你認為自己也應知曉，但我忘了把你加進去，請聯繫我。
提議對最差情形有多大提升？我們可以得出更有效的緩解措施嗎？
共識清理提議所提議的緩解措施會讓我製作出的區塊無效。而在新的限制之下，最糟的區塊在我的筆記本電腦上只要 5 秒鐘就驗證完成了。我認為我們可以進一步引入對傳統交易體積的限制，以求穩妥。
關於被提議的緩解措施，也有人擔心 “沒收” 問題（原本有效的腳本變得花不出去了）。我認為，這些擔憂是合理的，也可以解決：僅對某個區塊高度之後創建的腳本應用新的規則。
使用 64 字節交易的默克爾樹攻擊
根據比特幣區塊中默克爾根的計算方式，（已知）剩餘有兩種攻擊。兩種都跟拼接兩個 32 字節的哈希值相關，要求該拼接後的字符串能夠成功反序列化為比特幣交易。（可能最著名的）一種是欺騙一個輕節點接受一筆並沒有被某個區塊確認的交易：讓一筆體積為 64 字節的交易得到區塊確認（因此被默克爾樹承諾），但其後面的 32 字節卻對應於一個支付給受害者、但沒有得到區塊確認的交易的 txid。另一種是欺騙一個節點，讓其將一個有效的區塊永遠禁止：找出一行樹節點，可以全部反序列化為（無效的）64 字節的交易。更多細節請看 Suhas Daftuar 撰寫的這篇文章。
共識清理提議將體積小於等於 64 字節的交易判為無效交易，可以同時修復這兩個問題。
有多麼糟糕？
針對輕節點（或任何接受默克爾證據的東西，比如側鏈）的攻擊都要求在 61 到（大約）75 比特區間內的暴力搜索，具體取決於專門用於攻擊的比特幣的數額。這是昂貴的，而且有簡單的緩解措施。比如，通過請求對 coinbase 交易的默克爾證據來檢查默克爾樹的深度，這會告訴你該區塊包含了多少交易。
也就是說，這種攻擊估計要花費 100 萬美元的成本，在 “最新的比特幣挖礦 ASIC 算力到達 14TH/s” 的時候。現在，似乎 ASIC 的算力已經上升到 400TH/s 了。此外，這種攻擊可以給交易偽造任意數量的確認。而成本只是挖出一個假的區塊來欺騙一個 SPV 客戶端，現在高了一點（80 比特）。
愚弄比特幣節點的攻擊在 Bitcoin Core 中已經得到了緩解，辦法是不緩存沒有上下文的區塊檢查（CheckBlock()）。創建有效的交易是不顯示的：第一筆必須是 coinbase 交易，需要暴力搜索 224 比特。
因為默克爾根在區塊中的計算方式，64 字節的交易是比特幣中的一個核心漏洞。雖然因它而起的（已知的）兩種攻擊都可以被緩解，但如果能避免這個走火風險，同時在 Bitcoin Core 中緩存無上下文的區塊檢查，那會是好事。
我們能得出更好的修復措施嗎？
64 字節的沒法是 “安全的”，因為在一筆交易中，64 字節不足以安置一個帶有鎖定腳本（不是任何人都可以花費、也不會永久鎖定）的輸出。它們沒有已知的用途，而且已經被全網當成非標準交易長達 5 年了。給定它們會帶來的漏洞以及它的無用，將它們判為無效交易是非常合理的。
然而，該 BIP 提議將小於 64 字節的交易也判為無效交易。雖然它們是沒有（或者不怎麼有用）的，這樣的交易是無害的。我一直認為，一種交易類型無用，不足以讓我們通過軟分叉將它們判為無效。
AJ 在他給 Bitcoin-inquisition 的 PR 中也讓（確切的）64 字節長的交易無效。
願望清單
BIP30 驗證
BIP34 暫時可以避免對每一個區塊連接運行相對昂貴的 BIP30 檢查。從區塊高度 198 3702 開始，就不能只依賴於 BIP34 了。如果要提議一種軟分叉來解決長期存在的協議 bug，那麼讓每一筆 coinbase 交易從此絕對獨一無二，就最好了。
一種簡單的解決辦法是讓 coinbase 交易的 nLockTime 設置成創建它的區塊高度。但是，有一種辦法更迂迴，可能對礦工來說更容易部署：在所有 coinbase 交易中強制要求 witness 承諾（來自 Greg Sanders）。我還沒有確定這條規則會不會有例外，但如果一個前隔離見證 coinbase 交易，其輸出恰好推送了以 32 個 0x00 字節開通的見證承諾頭，我會非常驚訝。
你最 “喜歡” 的 bug！
在這個階段，我希望收集儘可能多的清理建議，確保如果這樣的軟分叉被擺上檯面，我們已經儘可能細緻地分析了所有我們可以加入的修復措施。
當然，建議應該有合理性。例如，“禁止 ordinals” 是一個無趣的提議，而且我很懷疑有多少人會參與。此外，讓我們集中在長期的、沒有爭議的 bug 上。例如，“一個花費長於 30 分鐘來驗證的區塊意味著糟糕情形”、“被打破的默克爾樹計算會帶來走火風險”，以及 “讓 coinbase 交易 真正 獨一無二”，似乎是完全沒有爭議的。而另一方面，雖然 “讓我們降低區塊體積限制” 可能有合理的理由，但對我來說，有爭議得多。
舉個例子，這裡有兩種你無法說服我值得提議的東西：
- 要求隔離見證 v0 交易也具備標準的 SIGHASH 類型字節。
- 限制腳本公鑰的體積上限，以減少最差情形下 UTXO 集的增長。
