2018-06-21 IRC 會議摘要

• 在 BotBot.me 或 MeetBot 上查看本週的日誌
• MeetBot 的會議記錄

本週會議討論的主題包括專案成員希望審查者在未來一週重點關注的拉取請求、何時揭露與簽名警報系統相關的 Bitcoin Core 0.12.0 及更早版本的已知 DoS 漏洞以及啟動 DoS 攻擊的機制（中本聰的警報簽名金鑰）、bitcoin-dev 郵件列表的託管變更、預設情況下如何選擇要包含在新交易中的輸入、處理多錢包模式下新錢包的載入、改進的私鑰備份和恢復，以及繼續致力於建立機器可寫配置檔案。

審查阻礙者[高優先級審查]

背景： 每次會議，Bitcoin Core 開發人員都會討論會議參與者認為在未來一週最需要審查的拉取請求（PR）。其中一些 PR 與貢獻者特別希望在下一個版本中看到的程式碼相關；其他 PR 則是阻礙進一步工作或需要大量維護（重新基底）以保持待處理狀態的 PR。鼓勵任何有能力的審查者訪問專案的當前高優先級 PR 列表。

討論（日誌）： Pieter Wuille 列出了目前列表中的三個 PR（#13062、#12196 和 #13425），並詢問是否有人想提名其他 PR。João Barbosa 建議 #13100，它新增了一個開啟錢包的選單項目，但它還沒有完全準備好，所以 Wuille 將等到準備好再新增它。

警報金鑰[公開揭露]

背景： 2010 年，有人建立了一個協定有效的區塊，建立了超過 1840 億比特幣。中本聰鼓勵使用者停止挖礦，並很快發布了 Bitcoin 的更新版本，在追溯軟分叉中更正了該行為，但他隨後向 Bitcoin 軟體新增了一種機制，允許他簽署「警報」訊息，可以直接通知節點營運者問題，甚至預設情況下關閉可能導致金錢損失的某些節點功能。在中本聰對 BitcoinTalk.org 論壇的最後一篇文章中，他寫道：

「安全模式」警報是 0.3.9 溢位錯誤後的臨時措施。我們可以說使用者可以使用「-disablesafemode」執行，但為了外觀起見，最好不要使用它。它從來沒有打算作為長期功能。安全模式仍然可以透過看到更長（更大的總 PoW）無效區塊鏈來觸發。

隨著時間的推移，後續的 Bitcoin Core 開發人員穩步棄用、停用和移除警報功能，在 0.12.1 版本中預設關閉它，在 0.13.0 版本中完全移除它，在 0.14.0 版本中硬編碼最終警報，並（2016 年 11 月）宣布即將公開揭露中本聰建立的警報簽名金鑰。在 Bitcoin Core 0.12.1 以下版本中發現與警報機制相關的拒絕服務（DoS）漏洞後，揭露被無限期延遲，如 2017 年 3 月 9 日每週會議中所討論，當時影響了大約 2,600 個節點。

討論（日誌）： Bryan Bishop 請求並介紹了該主題，「我正在考慮釋出私有[警報簽名]金鑰。[這]會很好地讓它公開並消除該責任。我特別有興趣聽到其他有充分理由不揭露金鑰的人的意見。在宣布[計劃公開揭露]以來的一年多時間裡，我認為沒有提出太多。」

Gregory Maxwell 說，「所有受支援的 [Bitcoin Core] 版本都完全[移除了簽名警報系統]，所以現在釋出聽起來相當不錯——除非 0.12 之前的節點仍然很受歡迎，我不相信它們是。」

Luke Dashjr 引用他的節點掃描系統說，3% 的節點執行 0.12 版本，「0.61%『其他』版本，其中包括 0.12 之前的所有版本。」Pieter Wuille 使用 Bitnodes 掃描系統發現了類似的統計資料，該系統使用不同的掃描方法。

關於舊版本 Bitcoin Core 中與簽名警報訊息相關的漏洞，Maxwell 說，「我懷疑我們不知道所有漏洞。我知道至少兩個，但我停止尋找了。」Andrew Chow 說他知道三個。

DoS 漏洞不僅影響 Bitcoin，還影響複製了 Bitcoin Core 程式碼並目前使用舊版本的山寨幣。當揭露漏洞時，任何擁有山寨幣警報簽名金鑰的人都將能夠執行這些 DoS 攻擊。在討論這個問題時，Chow 說，「[但]如果山寨幣更好地控制了它們的警報金鑰，發布 Bitcoin 的金鑰和相關漏洞應該不是問題。」

結論： 沒有明確的結論。Bishop 似乎可能會繼續努力負責任地揭露警報金鑰和（可能）與其相關的漏洞。沒有人反對這一點，儘管 Matt Corallo 確實說他認為「釋出警報金鑰的實用性有限。」

Bitcoin-dev 郵件列表

背景： bitcoin-dev（Bitcoin 開發）郵件列表在過去幾年中一直託管在 lists.linuxfoundation.org。

討論（日誌）： Bryan Bishop 請求並介紹了該主題：「Linux Foundation 正在從電子郵件協定遷移，將不再託管 bitcoin-dev 郵件列表。有一個遷移計劃，但它仍在調查中。」

關於列表目前的傳遞問題進行了一些簡短的討論，表達了希望現有舊文章的 URL 保持有效，以及其他遷移問題。

結論： Bishop 將向郵件列表發送一封電子郵件，希望在遷移到新主機網域之前，一旦他有更多細節就會提供。

幣選擇

背景： 幾位開發人員一直在努力改進 Bitcoin Core 的幣選擇——它如何選擇要花費哪些比特幣（輸入）——以同時改善隱私、減少交易大小和降低費用。目前的選擇協定從分支定界（BnB）演算法開始，該演算法嘗試在可用輸入和發送金額之間找到匹配。如果這不起作用，則需要一個備用演算法。單次隨機抽取（SRD）演算法隨機將額外輸入新增到部分交易中，直到輸入的總和等於或大於正在花費的金額（包括費用）。

本週的討論是上週討論的延續，關於同一主題。

討論（日誌）： Andrew Chow 請求並介紹了該主題，「我對[單次隨機抽取]備用內容進行了大量模擬（連結）。我看到這個策略有兩個問題：找零可能非常小，錢包中 UTXO 的平均數量相當高。問題是我們是否可以接受這些權衡，或者我們是否需要找到更好的演算法。」

Gregory Maxwell 說，「[如果我沒記錯的話]，[單次隨機抽取]沒有什麼根本性的東西使它對使[分支定界]更好地工作有好處，而是它是 [Mark Erhardt] 在那裡嘗試的第一個替代方案。」

Chow 補充說，「嗯，在 [Erhardt] 的模擬中，[單次隨機抽取]表現得相當好，而且非常簡單。儘管我想我們現在可能看到不同的結果。」

討論了各種額外的策略及其權衡，但該主題開始變得對一個有時間限制的純文字會議的簡短部分來說變得複雜。

結論： Chow 建議，「也許這個幣選擇討論最好親自用白板進行，」結束會議討論，儘管 Maxwell 指出，「這會排除無法參加的人。」推測討論將在 PR #13307 和可能的其他地方繼續。

多錢包會話持久性

背景： Bitcoin Core 的開發分支（「master」分支）包含允許使用者在多錢包模式下動態載入和卸載單個錢包的程式碼。例如，您可以擁有一個「個人」錢包和一個「商業」錢包，每個都可以單獨開啟或關閉。

討論（日誌）： Jonas Schnelli 請求並介紹了該主題，「我想在 Bitcoin Core 重新啟動後需要重新載入已載入的錢包不是理想的——特別是在修剪模式下。」也就是說，建立或載入錢包然後重新啟動 Bitcoin Core 而不更改配置檔案的使用者將不得不在下次載入該錢包時重新掃描區塊鏈的最新部分。更糟糕的是，如果重新掃描需要的某些區塊已被修剪，使用者將無法使用錢包。

幾位會議參與者建議這就是正在開發可寫 Bitcoin 配置檔案（rwconf）的原因。有關背景，請參見 PR #11082 和 2018 年 5 月 24 日和 2018 年 6 月 7 日的每週會議記錄。

結論： 「好吧，我猜 rw/config 解決了這個問題，所以 /topic，」Schnelli 說。

Bech32x

背景： 幾位 Bitcoin Core 貢獻者一直在努力建立一種新的序列化格式，用於備份和恢復 Bitcoin 私鑰、HD 錢包種子、HD 錢包擴展私鑰和 HD 錢包擴展公鑰。主要目標是用一個新標準取代目前流行的 base58check 和 BIP39 標準，該標準不僅檢測錯誤，還可以為使用者自動更正其中幾個錯誤。該提議格式的當前想法重複使用為建立 bech32 原生 segwit 地址格式而執行的一些工作，因此工作在名稱「bech32x」下進行（但這可能稍後會改變）。

討論（日誌）： Jonas Schnelli 請求並介紹了該主題，「Bech32x 目前具有距離 27 BCH，可更正到 7 個字元，感謝 [Pieter Wuille]。現在的想法是有三個『級別』的更正。[…] 對於 512 位元金鑰材料，七個字元不超過 5% 的更正[所以至少對於該情況需要更多]。」

Wuille 提出提供三個使用者可以選擇的程式碼。Gregory Maxwell 說，「我認為使其普遍可由使用者選擇不好。使用者通常無法做出有用的決定——但使格式支援多個程式碼在我看來似乎沒問題，儘管它可能會降低編寫精緻解碼器的可能性，因為這將是更多的工作。」

Wuille 說，「我們可以確保它們使用相同的欄位和擴展，以便大部分恢復程式碼可以共享。」Wuille 和 Maxwell 繼續談論為此目的選擇最佳 BCH 程式碼的細節。

結論： 會議結束的時間在討論期間發生，Maxwell 說，「稍後繼續。」

RWConf [可寫 Bitcoin 配置檔案]

此主題在會議期間被請求，但沒有足夠的時間。儘管如此，一些參與者在會議結束後立即留下來討論它。

背景： 如 2018 年 5 月 24 日會議中所討論，幾位貢獻者正在努力建立一個機器可寫配置檔案，該檔案將在 Bitcoin Core 的守護程式和 GUI 之間共享，以便當使用者在一個程式中更改設定時，它將在另一個程式中以相同的方式設定。在 2018 年 6 月 7 日會議中提出了建立新配置檔案的特定問題，但最熟悉該主題的人不在場；他在這次會議後討論中在場。

討論（日誌 rwconf）： Luke Dashjr 請求了該主題，並在會議後透過詢問 AJ Towns 是否反對 Dashjr 回復 Towns 的一個提交（該提交更改了 Bitcoin Core 啟動時如何處理命令列和配置檔案參數）來介紹它。這將解決 Dashjr 在建立可寫配置檔案時遇到的問題。

Pieter Wuille 建議了一個額外的機制，Towns 指出了 Dashjr 提案與網路配置相關的潛在問題。然而，Towns 說，「無論如何，我不反對更改地圖內容，[它]只是我能看到的獲得相對理智行為的最簡單方法。」

結論： 沒有明確的結論。推測 Dashjr 將繼續致力於建立機器可寫配置檔案。

幽默

<gmaxwell>  I doubt we know all the vulnerabilities.
            I know of at least two but I stopped looking.
<achow101>  gmaxwell: I believe I know of three
<gmaxwell>  Also depends on how you count. :)
<achow101>  that too
    <sipa>  i tend to count using the ring of integers

參與者

免責聲明

本摘要在編寫時未徵求討論參與者的意見，因此任何錯誤都是摘要作者的過失，而非討論參與者的過失。特別是，從討論中摘錄的引文在大小寫、標點符號和拼寫方面進行了修改，以產生一致的句子。括號中的詞語和片段以及背景敘述和說明由本摘要的作者新增，可能無意中改變了某些句子的含義。如果您認為任何引文被斷章取義，請開啟 issue，我們將更正錯誤。