Bitcoin Core 32 加快驗證速度並調整手續費機制

Bitcoin Core 32.0 已進入最終候選版本測試週期，此前開發者於 9 月 14 日標記了 v32.0rc1，使手續費估算、區塊驗證效能與安全性修復更接近預定的 10 月 10 日發布。

Bitcoin Core 專案的官方 GitHub 發布頁面顯示，v32.0rc1 位於提交 d0231bb，並於 9 月 14 日 12:58 UTC 以經驗證的維護者簽章簽署。該專案的發布時程仍以 10 月 10 日為最終 v32.0 標記的目標，儘管該日期仍取決於測試與進一步修復。

第 32 版聚焦於節點軟體行為、錢包介面、手續費計算、網路與效能。發布說明草稿並未列出比特幣共識規則的變更，這意味著該更新並未重新定義網路認為有效的交易或區塊。

Bitcoin Core 32 在 RC1 標記後以 10 月 10 日為目標

開發者於 8 月 20 日進入功能凍結，將工作限制在發布前所需的修復。9 月 14 日，他們從主要開發分支分離出 32.x 分支，並開始候選版本週期，同時第 33 版的開發工作另行恢復。

第一個候選版本旨在讓節點營運者、錢包開發者與其他使用者在開發者決定程式碼是否已準備好穩定發布之前進行測試。Bitcoin Core 於 9 月 15 日，即 RC1 標記後一天，開設了一個專門的32.0 候選版本測試回饋問題。

該專案要求測試者使用測試指南進行 RC 特定檢查，並透過個別的 GitHub 問題回報軟體問題。截至 9 月 16 日，尚未發布最終的 v32.0 二進位檔。

Bitcoin Core 不會自動更新。營運者自行選擇何時安裝新版本，這意味著較舊的版本在較新軟體可用後仍可能保持運作。

這種手動升級模式在以往的安全披露中相當重要。正如crypto.news 先前報導，Bitcoin Core 在 5 月披露了 CVE-2024-52911，此前有漏洞的 28.x 分支已達到生命週期終點。該缺陷在技術細節公開之前，已在 Bitcoin Core 29.0 中修復。

新手續費估算器融合記憶池與區塊歷史

Bitcoin Core 32 較為顯著的使用者面向變更之一，影響了 estimatesmartfee，這是錢包與應用程式用來計算交易手續費的 RPC。

迄今為止，Bitcoin Core 的主要估算器依賴於過去區塊中所包含交易的觀察確認行為。第 32 版新增了一個基於目前等待在節點記憶池內交易的獨立估算器。

新的記憶池估算器會根據當前待處理交易的狀況，同時產生經濟型和保守型估算。Bitcoin Core 在使用它之前會先檢查近期的區塊活動，並可在記憶池看起來過於稀疏或不健康時拒絕該估算。

當兩個系統都產生有效結果時，estimatesmartfee 會回傳較低的手續費估算。因此，新方法無法透過合併的預設模式，將既有的區塊政策建議推高；它的作用是在當前記憶池狀況支持的情況下，降低該建議。

這種設計可以在區塊空間昂貴的時期結束後更快做出反應。區塊歷史估算器可能會繼續納入近期確認的高手續費交易，而記憶池可能已經顯示出較少交易在競爭確認。

該軟體保留了應用程式使用先前方法的方式。新增的 fee_rate_estimator 選項讓使用者可以要求 block_policy、mempool_policy 或合併的預設行為。Bitcoin Core 會將新的記憶池估算器統計資料儲存在單獨的資料檔案中，以便在重新啟動後重新載入。

錢包手續費計算將使用合併的預設估算器。回應可以指出是哪個估算器產生了所選的手續費，而更高的詳細程度層級則會為需要更多細節的應用程式揭露記憶池健康統計資料。

區塊驗證獲得平行磁碟預取

Bitcoin Core 32 改變了節點在連接區塊時擷取交易資料的方式，特別是當所需資訊必須從儲存裝置讀取時。

該軟體現在可以在區塊驗證持續進行的同時，透過多個工作執行緒從鏈狀態資料庫預取先前的交易輸出，也就是所謂的 prevouts。預設為八個預取執行緒，營運者可將設定提高到 16，或將其設為零以停用平行擷取。

Prevouts 可識別交易輸入所花費的幣。節點需要該資訊來檢查輸入是否存在、是否尚未被花費，以及是否符合適用的驗證規則。

這項改進旨在減少節點處理包含尚未存在於較快記憶體快取中的輸入之區塊時，等待磁碟讀取所花費的時間。其效果會因儲存硬體、快取行為和節點配置而異。

Bitcoin Core 32 透過 -prevoutfetchthreads=<n> 公開此設定，讓營運者控制參與的執行緒數量。草案說明將此功能特別描述為區塊驗證效能改進。

另外的 RPC 變更讓營運者在 AssumeUTXO 背景驗證期間獲得更多資訊。在以快照為基礎的節點到達鏈尖端後，getblockchaininfo 現在可以回報仍在活動節點狀態背後執行的歷史鏈驗證進度。

安全修正關閉錢包與 HTTP 記憶體漏洞

Bitcoin Core 32 修正了一個在少數特定條件下影響非 Windows 系統的錢包通知漏洞。

草案說明指出，當節點以 -walletnotify 配置時，具有建立錢包權限的已驗證 RPC 使用者可以精心製作一個包含特殊替換字元的錢包名稱。在這些條件下，該名稱可能導致以 Bitcoin Core 處理程序權限執行任意命令。

第 32 版改變了錢包通知預留位置替換方式，使錢包名稱被視為字面文字。此版本也透過拒絕某些包含 . 或 .. 路徑元素的相對路徑名稱，收緊了錢包命名。

第二個問題在審查 Bitcoin Core 改寫的 HTTP 伺服器時浮現，該伺服器將在第 32 版取代 libevent。

開發者 Matthew Zipkin 在使用 Moonshot AI 的 Kimi K3 模型進行稽核後，發現了一條記憶體耗盡路徑，因而提交了 pull request #36123。當伺服器處理一個請求時，它可以繼續讀取並排入同一連線所傳送的資料，而沒有有效的大小限制。

初步分析顯示，該情況主要需要一個已驗證且能讓請求持續忙碌的用戶端。進一步測試發現，REST 流量在未經驗證的情況下也會造成類似問題。

一名審查者回報，16 個未經驗證的 REST 連線在約一分鐘內，將一個測試處理程序的記憶體從 46 MB 推高到約 3 GB。在修訂後的修正中，同一測試在 90 秒內使記憶體使用量增加約 3 MB，而修補前則為 3.2 GB。

該修補於 9 月 5 日合併，早於 v32.0rc1 被標記。由於改寫的 HTTP 伺服器是第 32 版的新增項目，這個特定缺陷在該伺服器出現在穩定版 Bitcoin Core 發行之前就被捕捉到了。

Kimi K3 的使用符合近期在比特幣軟體中進行 AI 輔助安全審查的模式。正如 crypto.news 在八月報導，Bitcoin Red Team 在掃描數百個與比特幣相關的開源專案後，記錄了 7,958 個潛在發現，儘管其中許多需要人工驗證才能被視為已確認的漏洞。

資源耗盡問題今年也出現在其他比特幣軟體中。在相關報導中，crypto.news 報導，Core Lightning 在審查 AI 生成的報告後確認了安全漏洞，並警告營運者升級或暫時使用離線模式。

PSBT 版本 2 成為四個 RPC 的預設值

Bitcoin Core 32 更改了四個與部分簽名比特幣交易（Partially Signed Bitcoin Transactions）搭配使用的命令所建立的預設格式。

createpsbt、walletcreatepsbt、converttopsbt 和 psbtbumpfee 將預設產生 PSBT 版本 2。開發者新增了一個可選的 psbt_version 參數，以便應用程式在必要時明確要求另一個受支援的版本。

PSBT 讓多個錢包、應用程式或硬體簽名裝置在完整的比特幣交易廣播之前交換交易資訊。將預設值移至版本 2 可能需要那些假設 Core 的 RPC 輸出會使用較舊格式的軟體進行測試。

此次更新並未移除要求先前版本的能力。圍繞受影響 RPC 命令建構的應用程式可以在測試版本 2 相容性時明確設定格式。

錢包工具在同一版本中還收到其他變更。一個新的 exportwatchonlywallet RPC 會建立一個描述符錢包檔案，其中包含公開描述符、交易歷史和地址簿資料，但不含私鑰。Bitcoin Core 的離線簽名教學現在使用該命令來建立線上僅觀看錢包。

另一個新命令 derivehdkey 讓錢包可以透過包含至少一個硬化步驟的路徑衍生擴展公鑰或私鑰，而 addhdkey 則允許新增 BIP32 擴展金鑰，而不會立即用它來產生輸出腳本。

PrivateBroadcast 也持續獲得維護。Crypto.news在六月報導，Bitcoin Core 31.1rc1 修復了一種在使用 PrivateBroadcast 時可能暴露來源 IP 位址的網路狀況。版本 32 在其發布說明草稿中記錄了進一步的 PrivateBroadcast RPC 和交易轉發變更。

目前的 Bitcoin Core 時程仍將 10 月 10 日列為標記 v32.0 的目標日期。於 9 月 15 日開啟的 RC 測試回饋討論串仍然活躍，開發者指示發現實際 Bitcoin Core 缺陷的測試者在最終發布前另行提交問題。