、Low-S 簽名規(guī)則與最小中繼費用提升)
Bitcoin Core 0.11.1 版本解析upnp 緩沖溢出修復(fù)、Low-S 簽名規(guī)則與最小中繼費用提升【免費下載鏈接】bitcoinBitcoin Core integration/staging tree項目地址: https://gitcode.com/GitHub_Trending/bi/bitcoin本文基于 Bitcoin Core 官方 0.11.1 版本發(fā)布說明release-notes-0.11.1.md展開完整覆蓋該安全更新版本的升級/降級注意事項、三項關(guān)鍵變更upnp 漏洞修復(fù)與默認禁用、Low-S 簽名強制校驗、最小中繼費用默認值提升的設(shè)計動機并結(jié)合當前倉庫源碼說明相關(guān)機制在代碼中的落點幫助讀者理解 0.11.1 為何要求盡快升級以及這三項變更對節(jié)點行為、交易傳播和挖礦策略的實際影響。版本定位與安全升級建議0.11.1 是一個安全修復(fù)版本minor version release官方建議“盡快升級至該版本”。該版本基于 0.11 分支通過回移backport多個 0.12 開發(fā)分支上的修復(fù)集中處理了網(wǎng)絡(luò)層漏洞、交易可塑性攻擊面和中繼費用策略三個問題。發(fā)布說明明確了兩點使用前提升級操作若運行的是舊版本先將其完全關(guān)閉老版本可能需要幾分鐘才能徹底退出再執(zhí)行安裝程序Windows、替換/Applications/Bitcoin-QtmacOS或覆蓋bitcoind/bitcoin-qt二進制Linux。降級風險由于 0.10.0 起引入了 headers-first 同步與并行區(qū)塊下載區(qū)塊文件與數(shù)據(jù)庫不再向后兼容0.10 之前的版本詳見下節(jié)。升級與降級區(qū)塊存儲不再向后兼容發(fā)布說明的“Downgrade warning”一節(jié)解釋了 0.10.0 之后的數(shù)據(jù)目錄為何無法直接用于更早的版本區(qū)塊亂序存儲區(qū)塊文件按收到順序而非高度順序?qū)懭氪疟P早期版本及部分配套工具無法處理這種布局用更早版本執(zhí)行 reindex 也會失敗區(qū)塊索引包含“只有頭沒有塊”的條目新的區(qū)塊索引數(shù)據(jù)庫會保存尚未下載對應(yīng)區(qū)塊的頭部記錄headers-first 同步的必要數(shù)據(jù)結(jié)構(gòu)早期版本不識別這種狀態(tài)。因此發(fā)布說明給出的降級建議是對整個數(shù)據(jù)目錄做備份否則降級后節(jié)點需要重新同步或從 bootstrap.dat 導(dǎo)入。完全同步完成的 0.10 數(shù)據(jù)目錄在舊版本上“可能”可以直接使用但官方明確聲明這不受支持且在舊版本嘗試 reindex 時隨時可能出錯。需要注意這一兼容性約束不影響錢包的前向/后向兼容性——發(fā)布說明指出從 0.11.x 降級到 0.10.x 未發(fā)現(xiàn)已知錢包問題。變更一修復(fù)捆綁 upnp 的緩沖溢出并默認禁用 upnp漏洞背景0.11.1 將捆綁的 miniupnpc 庫更新至 1.9.20151008修復(fù)了其在初次網(wǎng)絡(luò)發(fā)現(xiàn)階段的 XML 解析器緩沖溢出對應(yīng) Cisco Talos 的 TALOS-2015-0035 報告該漏洞由 Aleksandar Nikolic 發(fā)現(xiàn)。適用范圍有一條重要限定該漏洞只影響官方分發(fā)的可執(zhí)行文件其中捆綁了舊版 miniupnpc不影響從源碼自行編譯或使用發(fā)行版軟件包的用戶。默認禁用 upnp除修復(fù)外0.11.1 還通過 PR #6795合并提交4dbcec0net: Disable upnp by default默認關(guān)閉了 upnp 功能。發(fā)布說明給出的權(quán)衡是代價IPv4 網(wǎng)絡(luò)上可達節(jié)點數(shù)量可能下降節(jié)點無法再通過 upnp 主動為自身打洞/映射端口收益使未來的 libupnpc 漏洞不再構(gòu)成結(jié)構(gòu)性網(wǎng)絡(luò)風險——即即使第三方庫再出漏洞攻擊面也默認不存在。這一“默認禁用、需要時再手動開啟”的思路與-upnp命令行參數(shù)配合使用用戶如需恢復(fù) upnp 行為需在配置中顯式開啟而非依賴默認值。變更二中繼與挖礦前強制校驗 Low-S 簽名這是 0.11.1 中影響最深遠的策略變更對應(yīng) PR #676971cc9d9Test LowS in standardness, removes nuisance malleability vector。技術(shù)動機ECDSA 簽名存在天然的二義性對同一個(r, s)s也可以表示為n - sn為曲線階。兩種形式都數(shù)學上有效導(dǎo)致同一筆交易可以被構(gòu)造出不同的 txid。Bitcoin Core 自 2013 年 9 月提交a28fb70e起生成的簽名就是規(guī)范化“低 S 值”low-S形式但該實現(xiàn)直到 2014 年 3 月的 0.9 版本才進入正式發(fā)布Bitcoinj 保持了相近的兼容期Bitcoinjs 與 Electrum 則更新更晚。0.11.1 要求節(jié)點在**中繼relay和挖礦mining**時拒絕非低 S 形式的簽名其定位在發(fā)布說明中寫得很明確共識行為完全不變consensus behavior is unchanged——這不是軟分叉不修改鏈上有效性規(guī)則若廣泛部署可消除 SIGHASH_ALL 的 P2PKH 交易上最后一個已知的“騷擾型”可塑性nuisance malleability攻擊向量代價是會阻塞大多數(shù)由“足夠過時”的軟件構(gòu)造的交易它不替代 BIP62 或類似機制礦工仍可協(xié)作篡改交易也不替代錢包軟件對可塑性的妥善處理發(fā)布說明引用了 Andrychowicz 等人的論文《On the Malleability of Bitcoin Transactions》作為背景它只是消除了那種“便宜且惱人”的 DoS 攻擊手段。當前源碼中的實現(xiàn)落點從當前倉庫的源碼結(jié)構(gòu)看低 S 校驗已經(jīng)演化為一條清晰的調(diào)用鏈簽名校驗的核心函數(shù)是CPubKey::CheckLowSsrc/pubkey.cpp。其實現(xiàn)先用ecdsa_signature_parse_der_lax寬松解析 DER 編碼簽名再調(diào)用secp256k1_ecdsa_signature_normalize——若規(guī)范化改變了簽名返回非 0說明原始簽名的 S 不在半階以下即非 low-S 形式該校驗被集成進腳本解釋器的驗證標志體系見 src/script/interpreter.cpp 中對CPubKey::CheckLowS的調(diào)用成為腳本驗證流程的一環(huán)而不僅是 0.11.1 時期的“標準性測試”——從源碼結(jié)構(gòu)看這意味著當前版本的低 S 約束已從 mempool 準入策略升級為腳本驗證層的一部分模糊測試亦覆蓋該路徑src/test/fuzz/key.cpp 斷言合法簽名通過CheckLowS而非法簽名被拒絕。理解這一演進對把握 0.11.1 的意義很重要當年它作為“標準性規(guī)則”引入以避免過早破壞兼容隨后在共識參數(shù)框架下逐步成為驗證標志體系的一部分這正是發(fā)布說明中“Consensus behavior is unchanged”這一聲明在后續(xù)版本中被重新定義的過程。變更三-minrelaytxfee默認值從 0.00001 提升到 0.00005調(diào)整內(nèi)容與動機0.11.1 將-minrelaytxfee的默認值由0.00001BTC/kvB 提升到0.00005BTC/kvBPR #6793e7bcc4aBump minrelaytxfee default。發(fā)布說明解釋了背景當時的**交易洪泛transaction flooding**導(dǎo)致節(jié)點內(nèi)存池mempool急劇膨脹造成節(jié)點內(nèi)存占用失控這是一個臨時措施用于橋接到動態(tài)費用估計機制合并之時該機制隨后進入了 0.12 版本該數(shù)值在 0.11 的發(fā)布說明中已被建議采用0.11.1 正式落地。當前源碼中的實現(xiàn)落點在當前倉庫中這一參數(shù)體系的演進痕跡清晰可見默認值常量定義于 src/policy/policy.hDEFAULT_MIN_RELAY_TX_FEE{100}即 100 satoshi/kvB。對比 0.11.1 時期的 50 satoshi/kvB0.00005可以看到中繼費用下限在此后進一步上調(diào)注釋亦明確它是“-minrelaytxfee的默認值交易中繼的最低費用”命令行參數(shù)在 src/init.cpp 注冊幫助文本說明了其語義“低于此費率BTC/kvB的手續(xù)費在中繼、挖礦與交易創(chuàng)建時視為零費用”src/kernel/mempool_options.h 將該常量作為 mempool 參數(shù)結(jié)構(gòu)的初始值src/node/mempool_args.cpp 中還存在static_assert(DEFAULT_MIN_RELAY_TX_FEE DEFAULT_INCREMENTAL_RELAY_FEE)說明最小中繼費與增量中繼費-incrementalrelayfee在結(jié)構(gòu)上被約束為同值二者共同定義了 mempool 限容與替換策略的費率下限費用估計器側(cè)src/policy/fees/block_policy_estimator.h 的注釋特別提到MIN_BUCKET_FEERATE歷史上繼承自DEFAULT_MIN_RELAY_TX_FEE并要求后者變更時同步更新——這印證了發(fā)布說明中“臨時措施橋接至動態(tài)方法”的歷史脈絡(luò)0.12 引入的估計器確實從此常量繼承了其最低費率桶。對運維的直接含義是若節(jié)點顯式配置了低于新默認值的-minrelaytxfee仍會按配置值執(zhí)行而跟隨默認值的節(jié)點在 0.11.1 之后會把 50 satoshi/kvB 以下的交易視為“零費”交易在 mempool 已滿時優(yōu)先淘汰或拒絕這類低費交易。0.11.1 完整變更日志發(fā)布說明收錄的 16 項行為級變更如下PR 編號與合并提交哈希均沿用原文檔PR合并提交變更說明#64382531438openssl規(guī)避配置文件加載/競態(tài)問題#6439980f820更新 Debian netinstall 的 URL 位置#63848e5a969qt對 SSL 連接強制 TLS1.0#647192401c2Dependsqt 升級至 5.5#622493b606a對未請求區(qū)塊的處理更加嚴格#6571100ac4elibbitcoinconsensus避免多線程環(huán)境下的崩潰#6545649f5d9timedata 采樣最多保存 200 個#6694834e299[QT] 修復(fù) thin space 換行斷行問題#67031cd7952向 0.11 回移 bug 修復(fù)#67505ed8d0b向 v0.11 回移 recent rejects#676971cc9d9標準性中測試 LowS消除騷擾型可塑性向量#6789b4ad73fminiupnpc 更新至 1.9.20151008#6785b4dc33e向 v0.11 回移(strCommand tx)中若 AlreadyHave() 則直接返回#64120095b9a測試新建 socket 是否可被 select()#67954dbcec0net默認禁用 upnp#6793e7bcc4a提升 minrelaytxfee 默認值其中除三項重點變更#6769、#6789/#6795、#6793外其余多為安全加固與穩(wěn)定性回移openssl 配置競態(tài)、Qt TLS 版本下限、libbitcoinconsensus 多線程崩潰、未請求區(qū)塊的更嚴格處理均屬于“防御縱深”類修復(fù)與 0.11.1 作為安全版本的定位一致。致謝發(fā)布說明感謝了為 0.11.1 直接貢獻代碼的 21 位貢獻者Adam Weiss、Alex Morcos、Casey Rodarmor、Cory Fields、fanquake、Gregory Maxwell、Jonas Schnelli、J Ross Nicoll、Luke Dashjr、Pavel Janík、Pavel Vasin、Peter Todd、Pieter Wuille、randy-waterhouse、Ross Nicoll、Suhas Daftuar、tailsjoin、?tcDrak、Tom Harding、Veres Lajos、Wladimir J. van der Laan以及提供代碼審查與安全研究支持的貢獻者IRC 用戶 timothy 報告了相關(guān)問題miniupnp 漏洞由 Cisco Talos 的 Aleksandar Nikolic 發(fā)現(xiàn)譯文則來自 Transifex 平臺的翻譯社區(qū)。小結(jié)0.11.1 雖然只是一個 0.11 分支上的小版本但三項變更各自奠定了后續(xù)版本的重要機制upnp 默認禁用確立了第三方網(wǎng)絡(luò)庫“默認關(guān)閉”的風險管理范式Low-S 強制校驗消除了當時 P2PKH 交易上最后剩余的廉價可塑性攻擊向量其校驗邏輯在今天的倉庫中仍能以CPubKey::CheckLowS與腳本驗證標志的形態(tài)被追蹤-minrelaytxfee提升到 0.00005則是 mempool 洪泛治理的臨時手段為 0.12 動態(tài)費用估計器的引入鋪平了道路——當前源碼中估計器最低費率桶繼承該常量、且與-incrementalrelayfee保持靜態(tài)斷言相等的結(jié)構(gòu)正是這一演進的直接證據(jù)。對仍在維護歷史節(jié)點數(shù)據(jù)或研究節(jié)點策略演進的讀者這份發(fā)布說明與 0.11.0 發(fā)布說明、0.12.0 發(fā)布說明 串聯(lián)閱讀可以完整還原 2015 年前后 Bitcoin Core 交易策略的轉(zhuǎn)型過程?！久赓M下載鏈接】bitcoinBitcoin Core integration/staging tree項目地址: https://gitcode.com/GitHub_Trending/bi/bitcoin創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Bitcoin Core 0.11.1 版本解析：upnp 緩沖溢出修復(fù)、Low-S 簽名規(guī)則與最小中繼費用提升
Bitcoin Core 0.11.1 版本解析upnp 緩沖溢出修復(fù)、Low-S 簽名規(guī)則與最小中繼費用提升【免費下載鏈接】bitcoinBitcoin Core integration/staging tree項目地址: https://gitcode.com/GitHub_Trending/bi/bitcoin本文基于 Bitcoin Core 官方 0.11.1 版本發(fā)布說明release-notes-0.11.1.md展開完整覆蓋該安全更新版本的升級/降級注意事項、三項關(guān)鍵變更upnp 漏洞修復(fù)與默認禁用、Low-S 簽名強制校驗、最小中繼費用默認值提升的設(shè)計動機并結(jié)合當前倉庫源碼說明相關(guān)機制在代碼中的落點幫助讀者理解 0.11.1 為何要求盡快升級以及這三項變更對節(jié)點行為、交易傳播和挖礦策略的實際影響。版本定位與安全升級建議0.11.1 是一個安全修復(fù)版本minor version release官方建議“盡快升級至該版本”。該版本基于 0.11 分支通過回移backport多個 0.12 開發(fā)分支上的修復(fù)集中處理了網(wǎng)絡(luò)層漏洞、交易可塑性攻擊面和中繼費用策略三個問題。發(fā)布說明明確了兩點使用前提升級操作若運行的是舊版本先將其完全關(guān)閉老版本可能需要幾分鐘才能徹底退出再執(zhí)行安裝程序Windows、替換/Applications/Bitcoin-QtmacOS或覆蓋bitcoind/bitcoin-qt二進制Linux。降級風險由于 0.10.0 起引入了 headers-first 同步與并行區(qū)塊下載區(qū)塊文件與數(shù)據(jù)庫不再向后兼容0.10 之前的版本詳見下節(jié)。升級與降級區(qū)塊存儲不再向后兼容發(fā)布說明的“Downgrade warning”一節(jié)解釋了 0.10.0 之后的數(shù)據(jù)目錄為何無法直接用于更早的版本區(qū)塊亂序存儲區(qū)塊文件按收到順序而非高度順序?qū)懭氪疟P早期版本及部分配套工具無法處理這種布局用更早版本執(zhí)行 reindex 也會失敗區(qū)塊索引包含“只有頭沒有塊”的條目新的區(qū)塊索引數(shù)據(jù)庫會保存尚未下載對應(yīng)區(qū)塊的頭部記錄headers-first 同步的必要數(shù)據(jù)結(jié)構(gòu)早期版本不識別這種狀態(tài)。因此發(fā)布說明給出的降級建議是對整個數(shù)據(jù)目錄做備份否則降級后節(jié)點需要重新同步或從 bootstrap.dat 導(dǎo)入。完全同步完成的 0.10 數(shù)據(jù)目錄在舊版本上“可能”可以直接使用但官方明確聲明這不受支持且在舊版本嘗試 reindex 時隨時可能出錯。需要注意這一兼容性約束不影響錢包的前向/后向兼容性——發(fā)布說明指出從 0.11.x 降級到 0.10.x 未發(fā)現(xiàn)已知錢包問題。變更一修復(fù)捆綁 upnp 的緩沖溢出并默認禁用 upnp漏洞背景0.11.1 將捆綁的 miniupnpc 庫更新至 1.9.20151008修復(fù)了其在初次網(wǎng)絡(luò)發(fā)現(xiàn)階段的 XML 解析器緩沖溢出對應(yīng) Cisco Talos 的 TALOS-2015-0035 報告該漏洞由 Aleksandar Nikolic 發(fā)現(xiàn)。適用范圍有一條重要限定該漏洞只影響官方分發(fā)的可執(zhí)行文件其中捆綁了舊版 miniupnpc不影響從源碼自行編譯或使用發(fā)行版軟件包的用戶。默認禁用 upnp除修復(fù)外0.11.1 還通過 PR #6795合并提交4dbcec0net: Disable upnp by default默認關(guān)閉了 upnp 功能。發(fā)布說明給出的權(quán)衡是代價IPv4 網(wǎng)絡(luò)上可達節(jié)點數(shù)量可能下降節(jié)點無法再通過 upnp 主動為自身打洞/映射端口收益使未來的 libupnpc 漏洞不再構(gòu)成結(jié)構(gòu)性網(wǎng)絡(luò)風險——即即使第三方庫再出漏洞攻擊面也默認不存在。這一“默認禁用、需要時再手動開啟”的思路與-upnp命令行參數(shù)配合使用用戶如需恢復(fù) upnp 行為需在配置中顯式開啟而非依賴默認值。變更二中繼與挖礦前強制校驗 Low-S 簽名這是 0.11.1 中影響最深遠的策略變更對應(yīng) PR #676971cc9d9Test LowS in standardness, removes nuisance malleability vector。技術(shù)動機ECDSA 簽名存在天然的二義性對同一個(r, s)s也可以表示為n - sn為曲線階。兩種形式都數(shù)學上有效導(dǎo)致同一筆交易可以被構(gòu)造出不同的 txid。Bitcoin Core 自 2013 年 9 月提交a28fb70e起生成的簽名就是規(guī)范化“低 S 值”low-S形式但該實現(xiàn)直到 2014 年 3 月的 0.9 版本才進入正式發(fā)布Bitcoinj 保持了相近的兼容期Bitcoinjs 與 Electrum 則更新更晚。0.11.1 要求節(jié)點在**中繼relay和挖礦mining**時拒絕非低 S 形式的簽名其定位在發(fā)布說明中寫得很明確共識行為完全不變consensus behavior is unchanged——這不是軟分叉不修改鏈上有效性規(guī)則若廣泛部署可消除 SIGHASH_ALL 的 P2PKH 交易上最后一個已知的“騷擾型”可塑性nuisance malleability攻擊向量代價是會阻塞大多數(shù)由“足夠過時”的軟件構(gòu)造的交易它不替代 BIP62 或類似機制礦工仍可協(xié)作篡改交易也不替代錢包軟件對可塑性的妥善處理發(fā)布說明引用了 Andrychowicz 等人的論文《On the Malleability of Bitcoin Transactions》作為背景它只是消除了那種“便宜且惱人”的 DoS 攻擊手段。當前源碼中的實現(xiàn)落點從當前倉庫的源碼結(jié)構(gòu)看低 S 校驗已經(jīng)演化為一條清晰的調(diào)用鏈簽名校驗的核心函數(shù)是CPubKey::CheckLowSsrc/pubkey.cpp。其實現(xiàn)先用ecdsa_signature_parse_der_lax寬松解析 DER 編碼簽名再調(diào)用secp256k1_ecdsa_signature_normalize——若規(guī)范化改變了簽名返回非 0說明原始簽名的 S 不在半階以下即非 low-S 形式該校驗被集成進腳本解釋器的驗證標志體系見 src/script/interpreter.cpp 中對CPubKey::CheckLowS的調(diào)用成為腳本驗證流程的一環(huán)而不僅是 0.11.1 時期的“標準性測試”——從源碼結(jié)構(gòu)看這意味著當前版本的低 S 約束已從 mempool 準入策略升級為腳本驗證層的一部分模糊測試亦覆蓋該路徑src/test/fuzz/key.cpp 斷言合法簽名通過CheckLowS而非法簽名被拒絕。理解這一演進對把握 0.11.1 的意義很重要當年它作為“標準性規(guī)則”引入以避免過早破壞兼容隨后在共識參數(shù)框架下逐步成為驗證標志體系的一部分這正是發(fā)布說明中“Consensus behavior is unchanged”這一聲明在后續(xù)版本中被重新定義的過程。變更三-minrelaytxfee默認值從 0.00001 提升到 0.00005調(diào)整內(nèi)容與動機0.11.1 將-minrelaytxfee的默認值由0.00001BTC/kvB 提升到0.00005BTC/kvBPR #6793e7bcc4aBump minrelaytxfee default。發(fā)布說明解釋了背景當時的**交易洪泛transaction flooding**導(dǎo)致節(jié)點內(nèi)存池mempool急劇膨脹造成節(jié)點內(nèi)存占用失控這是一個臨時措施用于橋接到動態(tài)費用估計機制合并之時該機制隨后進入了 0.12 版本該數(shù)值在 0.11 的發(fā)布說明中已被建議采用0.11.1 正式落地。當前源碼中的實現(xiàn)落點在當前倉庫中這一參數(shù)體系的演進痕跡清晰可見默認值常量定義于 src/policy/policy.hDEFAULT_MIN_RELAY_TX_FEE{100}即 100 satoshi/kvB。對比 0.11.1 時期的 50 satoshi/kvB0.00005可以看到中繼費用下限在此后進一步上調(diào)注釋亦明確它是“-minrelaytxfee的默認值交易中繼的最低費用”命令行參數(shù)在 src/init.cpp 注冊幫助文本說明了其語義“低于此費率BTC/kvB的手續(xù)費在中繼、挖礦與交易創(chuàng)建時視為零費用”src/kernel/mempool_options.h 將該常量作為 mempool 參數(shù)結(jié)構(gòu)的初始值src/node/mempool_args.cpp 中還存在static_assert(DEFAULT_MIN_RELAY_TX_FEE DEFAULT_INCREMENTAL_RELAY_FEE)說明最小中繼費與增量中繼費-incrementalrelayfee在結(jié)構(gòu)上被約束為同值二者共同定義了 mempool 限容與替換策略的費率下限費用估計器側(cè)src/policy/fees/block_policy_estimator.h 的注釋特別提到MIN_BUCKET_FEERATE歷史上繼承自DEFAULT_MIN_RELAY_TX_FEE并要求后者變更時同步更新——這印證了發(fā)布說明中“臨時措施橋接至動態(tài)方法”的歷史脈絡(luò)0.12 引入的估計器確實從此常量繼承了其最低費率桶。對運維的直接含義是若節(jié)點顯式配置了低于新默認值的-minrelaytxfee仍會按配置值執(zhí)行而跟隨默認值的節(jié)點在 0.11.1 之后會把 50 satoshi/kvB 以下的交易視為“零費”交易在 mempool 已滿時優(yōu)先淘汰或拒絕這類低費交易。0.11.1 完整變更日志發(fā)布說明收錄的 16 項行為級變更如下PR 編號與合并提交哈希均沿用原文檔PR合并提交變更說明#64382531438openssl規(guī)避配置文件加載/競態(tài)問題#6439980f820更新 Debian netinstall 的 URL 位置#63848e5a969qt對 SSL 連接強制 TLS1.0#647192401c2Dependsqt 升級至 5.5#622493b606a對未請求區(qū)塊的處理更加嚴格#6571100ac4elibbitcoinconsensus避免多線程環(huán)境下的崩潰#6545649f5d9timedata 采樣最多保存 200 個#6694834e299[QT] 修復(fù) thin space 換行斷行問題#67031cd7952向 0.11 回移 bug 修復(fù)#67505ed8d0b向 v0.11 回移 recent rejects#676971cc9d9標準性中測試 LowS消除騷擾型可塑性向量#6789b4ad73fminiupnpc 更新至 1.9.20151008#6785b4dc33e向 v0.11 回移(strCommand tx)中若 AlreadyHave() 則直接返回#64120095b9a測試新建 socket 是否可被 select()#67954dbcec0net默認禁用 upnp#6793e7bcc4a提升 minrelaytxfee 默認值其中除三項重點變更#6769、#6789/#6795、#6793外其余多為安全加固與穩(wěn)定性回移openssl 配置競態(tài)、Qt TLS 版本下限、libbitcoinconsensus 多線程崩潰、未請求區(qū)塊的更嚴格處理均屬于“防御縱深”類修復(fù)與 0.11.1 作為安全版本的定位一致。致謝發(fā)布說明感謝了為 0.11.1 直接貢獻代碼的 21 位貢獻者Adam Weiss、Alex Morcos、Casey Rodarmor、Cory Fields、fanquake、Gregory Maxwell、Jonas Schnelli、J Ross Nicoll、Luke Dashjr、Pavel Janík、Pavel Vasin、Peter Todd、Pieter Wuille、randy-waterhouse、Ross Nicoll、Suhas Daftuar、tailsjoin、?tcDrak、Tom Harding、Veres Lajos、Wladimir J. van der Laan以及提供代碼審查與安全研究支持的貢獻者IRC 用戶 timothy 報告了相關(guān)問題miniupnp 漏洞由 Cisco Talos 的 Aleksandar Nikolic 發(fā)現(xiàn)譯文則來自 Transifex 平臺的翻譯社區(qū)。小結(jié)0.11.1 雖然只是一個 0.11 分支上的小版本但三項變更各自奠定了后續(xù)版本的重要機制upnp 默認禁用確立了第三方網(wǎng)絡(luò)庫“默認關(guān)閉”的風險管理范式Low-S 強制校驗消除了當時 P2PKH 交易上最后剩余的廉價可塑性攻擊向量其校驗邏輯在今天的倉庫中仍能以CPubKey::CheckLowS與腳本驗證標志的形態(tài)被追蹤-minrelaytxfee提升到 0.00005則是 mempool 洪泛治理的臨時手段為 0.12 動態(tài)費用估計器的引入鋪平了道路——當前源碼中估計器最低費率桶繼承該常量、且與-incrementalrelayfee保持靜態(tài)斷言相等的結(jié)構(gòu)正是這一演進的直接證據(jù)。對仍在維護歷史節(jié)點數(shù)據(jù)或研究節(jié)點策略演進的讀者這份發(fā)布說明與 0.11.0 發(fā)布說明、0.12.0 發(fā)布說明 串聯(lián)閱讀可以完整還原 2015 年前后 Bitcoin Core 交易策略的轉(zhuǎn)型過程?！久赓M下載鏈接】bitcoinBitcoin Core integration/staging tree項目地址: https://gitcode.com/GitHub_Trending/bi/bitcoin創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考