Bitcoin Optech 電子報 #423 回顧 Podcast
節點原本要保存約 11 GB 的 UTXO 集,Utreexo 的累加器卻不到 1 kB,代價是頻寬用量增加,Davidson Souza 在 #423 回顧節目如此說明。MARA 的 Eric Price 與 PortlandHODL 也是來賓,議題包括會讓算力下滑的礦機卡住的 vardiff 控制器,以及不可花費內部金鑰的 BIP 草案。
Bitcoin Optech
從官方來源收錄的全部內容。
141 篇文章
節點原本要保存約 11 GB 的 UTXO 集,Utreexo 的累加器卻不到 1 kB,代價是頻寬用量增加,Davidson Souza 在 #423 回顧節目如此說明。MARA 的 Eric Price 與 PortlandHODL 也是來賓,議題包括會讓算力下滑的礦機卡住的 vardiff 控制器,以及不可花費內部金鑰的 BIP 草案。
Bitcoin Optech
礦池可能讓算力下滑的礦機卡在依舊速度設定的 share 難度上,Eric Price 在 Delving Bitcoin 提出這項論點,解方是計時器:一段時間沒有 share 就調降難度。Davidson Souza 希望在初始區塊下載期間,以 SwiftSync hintsfile 省去 Utreexo 的刪除證明;NTL 則為不可花費的 taproot 內部金鑰起草了 BIP。
Bitcoin Optech
Adam Gibson 向 Optech 主持人 Mark Erhardt、Mike Schmidt 介紹 Babilonia,這是他設計的 coinjoin 協定,外觀偽裝成隱蔽賭局;他也提到 Ron Rivest 1997 年關於樂透式微支付的論文,是機率支付較早的源頭。隨後 Rob Segers 談他對靜默支付輕客戶端的量測。
Bitcoin Optech
Adam Gibson 提出的 Babilonia 把 coinjoin 包裝成鏈上擲硬幣,從外部看就像一般付款,不過他的論文也承認,這套協定的成效目前沒有明確的衡量方式。Rob Segers 的測試顯示,BlindBit Oracle v2 的下載量約為「只含 taproot 的過濾器加上 tweak 資料」的 2.1 倍,換來的是沒有誤判。LDK v0.2.6 則修補了一個阻斷服務漏洞。
Bitcoin Optech
正常運作時磁碟讀寫量偏高,問題出在 chainstate 資料庫不斷重寫自身的大部分內容,Bitcoin Core 29.4 修掉了這個錯誤:停用 LevelDB 的 seek compaction,改為定期壓實 chainstate(#35465)。
Bitcoin Core
chainstate 造成的磁碟頻繁讀寫在 Bitcoin Core 30.3 畫下句點。這一版也修復 feebumper 在無法取得合併加價手續費時當機(#34870),以及幣選擇把金額算成布林值的錯誤(#34888)。PSBT 方面,解序列化 pubnonce 與部分簽章時現在會驗證 MuSig2 公鑰(#34219)。
Bitcoin Core
Bitcoin Core 31.1 補上 -privatebroadcast 的 IP 位址外洩:部分連線原本走明網,而不是已啟用的隱私網路。chainstate 反覆重寫導致磁碟活動過量的問題也一併解決,MuSig2 金鑰聚合則開始拒絕空的公鑰清單(#35316)。
Bitcoin Core
啟用 -privatebroadcast 的 Bitcoin Core 31.0,在 v2 交握失敗後的 v1 重試會跳過 Tor 代理直接連上對等節點,發送者的 IP 位址因此可能曝光。最可能的觸發情境是惡意節點故意中斷交握。在 31.1 推出前,使用者可關閉此功能、設定 -v2transport=0,或讓 IPv4/IPv6 對外連線全部走 Tor。
Bitcoin Core
Bitcoin Core 0.14.0 之後、29.0 之前的版本,驗證特製無效區塊時可能讀取已釋放的記憶體,導致節點當機。CVE-2024-52911 評為高風險,不過攻擊者必須在鏈頂付出有效的工作量證明,遠端執行程式碼的可能性也被認為不大。這個漏洞由 Cory Fields 通報,29.0 已納入修補。
Bitcoin Core
叢集記憶池在 Bitcoin Core 31.0 取代舊設計:祖先與後代限制改為每個叢集上限 64 筆交易、101 kB,CPFP carveout 也一併取消。記憶體至少 4096 MiB 的機器,-dbcache 預設提高到 1024 MiB;新增的 -privatebroadcast 選項則讓 sendrawtransaction 只透過 Tor 或 I2P 廣播。
Bitcoin Core
Bitcoin Core 28.4 修正未命名錢包的兩項錯誤:舊版錢包遷移(#34156),以及 createfromdump 失敗時會刪除 wallets 目錄(#34215)。chainparams 也移除了一個 DNS 種子(#33723)。
Bitcoin Core
對等節點傳送違反共識的交易,Bitcoin Core 29.3 不再予以懲處(#33050)。驗證流程新增逐輸入的 sighash midstate 快取,涵蓋 legacy、P2SH 與 segwit v0 腳本(#32473),偵測 witness stripping 也不必重跑 Script 檢查(#33105);礦工程式 addPackageTxs 的無號整數溢位則已排除(#33475)。
Bitcoin Core
未命名舊版錢包遷移失敗的問題,到 Bitcoin Core 30.2 已獲解決(#34156),createfromdump 處理這類錢包失敗時也不再刪除 wallets 目錄(#34215)。IPC 等待呼叫期間按 Ctrl-C 不會再卡住(#33511)。
Bitcoin Core
在罕見情況下,Bitcoin Core 30.0 或 30.1 遷移 wallet.dat 失敗時,可能刪光錢包目錄內所有檔案,資金因此面臨風險。開發者已下架這兩版的二進位檔,並請使用者在 30.2 推出前不要透過 GUI 或 RPC 遷移。觸發條件是預設、未命名的 wallet.dat 遷移或載入失敗,其他使用者不受影響。
Bitcoin Core
錢包在 Bitcoin Core 30.1 不再選用帶有祖先的未確認 TRUC 幣(#33528)。IPC 方面,選項不必再加 -m 參數(#33229),訊息記錄的額外負擔降低(#33517),執行中的 waitNext 呼叫也可以取消(#33676)。
Bitcoin Core
攻擊者在多條連線重複使用 version 訊息的 nonce,偽裝成自我連線,就能灌大 Bitcoin Core 節點的記錄檔。由於受害者第一條連線預設 60 秒後逾時,要填滿磁碟得花很久,CVE-2025-54604 因此評為低風險。Niklas Goegge 在 2022 年通報,29.1 與 30.0 的記錄限速已阻擋此攻擊。
Bitcoin Core
反覆傳送無效區塊可能耗盡 Bitcoin Core 節點的磁碟空間,因為未通過基本檢查、或在最後檢查點之前分岔的區塊都會被逐一寫入記錄。Niklas Goegge 與 Eugene Siegel 分別獨立通報 CVE-2025-54605,評為低風險,29.1 與 30.0 以記錄限速修復。
Bitcoin Core
特製的非標準交易每筆可佔用 Bitcoin Core 節點數秒,發送方卻不會被斷線,攻擊者可藉此拖慢區塊傳播。CVE-2025-46598 評為低風險,由 Antoine Poinsot 通報,v30.0 透過縮短最壞情況的驗證時間來緩解。
Bitcoin Core
超過 1GB 的區塊可能讓 32 位元 Bitcoin Core 節點的大小檢查溢位,並在寫入磁碟時當機,但前提是以 compact block 形式傳送,受害者還得把 -maxmempool 設在 3GB 以上、內有 1GB 交易。Pieter Wuille 發現的 CVE-2025-46597 評為低風險,29.1 與 30.0 限制 32 位元系統的 -maxmempool 後問題解除。
Bitcoin Core
Bitcoin Core 28.3 調低預設最低費率:-blockmintxfee 降到每 kvB 1 聰,-minrelaytxfee 與 -incrementalrelayfee 降到每 kvB 100 聰。錢包費率維持不變,若新預設值未在全網普及,低費率交易可能傳不出去。另外,白名單權限不再適用於洋蔥入站連線(#33395)。
Bitcoin Core