IRC meeting summary for 2017-03-23

• 本週會議記錄
• Meeting minutes by meetbot

主要議題

• Segwit 地址提案
• 錢包中的 DER 私鑰
• 反對二進位發布的聲明
• 被封鎖和需要審查的 PR

Segwit 地址提案

背景

Pieter Wuille 和 Gregory Maxwell 最近提出了一個用於原生隔離見證（segwit）scriptPubKey 的地址格式。

對話

Gregory Maxwell 開始對話：「我們可能在從太多人那裡獲得 1:1 評論方面犯了策略錯誤，導致郵件列表上的評論缺乏。郵件列表上的評論會很好，即使它們只是『我之前審查過這個，LGTM [Looks Good To Me]』。」

Peter Todd 建議：「沿著這些思路，我認為公開其中一些 1:1 評論可能對有興趣了解這些流程如何運作的新開發者有幫助。」

在討論優化 QR 碼編碼時，Jonas Schnelli 提到：「為 QR 碼設計額外的二進位地址標準可能不值得。也許它們只是暫時的？3-4 年後就沒有了？」

Maxwell 回答：「我認為為此可能不值得，但產業反饋會很好。」

Wuille 補充：「[QR 碼的]字母數字模式相當有效；與二進位相比只多 10%。它每個字元使用 5.5 位元，所以每 5 位元資料 5.5 位元相當不錯。」

Schnelli 然後問：「Bech32 編碼也可以用於私鑰（== 32 位元種子）嗎？」

Wuille 回答：「好問題！我們一直在考慮為私鑰使用更強的校驗和，可能是 12 個校驗和字元（這是 64 位元算術可以做到的最大值）。對於地址，你真的只關心[錯誤]檢測，但對於私鑰，你想要[錯誤]更正。使用 12 字元校驗和，更正 3 個錯誤是微不足道的，但也許我們可以找到一個可以更正 4 個的。」

Maxwell 補充：「找到一個更正 4 的 12 位數程式碼可能需要比我們這裡一百個核心更多的計算能力，儘管 [Wuille] 已經做了很多工作，將這個搜尋從完全難以處理變為合理。:) 我認為這項工作的優先級比我們可以進行的其他工作（如 utxo 資料庫重構和交易壓縮）要低得多」

在討論接近尾聲時，Maxwell 簡要談到了 bech32 編碼在防止資金被發送到錯誤地址方面的有效性：「如果使用者的錯誤率低於每個輸入地址 3.53 個錯誤，此程式碼的保護比 32 位元雜湊（如 base58 check 使用的）更好。由於大小寫調變，使用者使用此格式犯錯的可能性要小得多。如果使用者不太可能犯錯，那麼此方案的有效保護趨於無限。例如，每個字元 0.1% 的錯誤機率，錯誤字串未被檢測到的機率是 1:2⁶⁰ [0.0000000000000000867%]。

結論

會議中幾位尚未審查（或完成審查）提案的人將審查它，所有已經審查過的人都被鼓勵在郵件列表上分享他們的評估。

任何閱讀這些會議記錄的錢包作者或其他 Bitcoin 開發者都被鼓勵審查提案，讓社群知道他們是否暫時支援它，或提出他們對它的任何問題。

錢包中的 DER 私鑰

背景

Gregory Maxwell 描述了目前的情況：「DER 私鑰格式包括公鑰，以及所有 ECC 群組參數，和其他開銷，所有這些都打包在數百位元組的 ASN1 解析地獄中。」這對 Bitcoin 錢包中的每個私鑰都這樣做，即使所有 Bitcoin 私鑰使用相同的參數，並且這些參數已經為 Bitcoin Core 所知。

自 Bitcoin Core 0.13.0 以來，由 Bitcoin Core 預設設定創建的所有新錢包都使用 BIP32 階層式確定性（HD）錢包。使用單獨隨機生成金鑰的舊式錢包，以及使用 importprivkey RPC 匯入金鑰的錢包仍然受支援。

討論

沒有人反對更改錢包格式以在不使用 DER 的情況下儲存金鑰或 HD 種子。大多數討論涉及應如何管理此變更和其他類似的錢包變更，特別是確保它們易於測試，但錢包格式每個版本最多只變更一次。

結論

沒有明確的結論。在對話接近尾聲時，討論集中在使用待定功能的特殊旗標上；例如，Maxwell 寫道：「我不在乎我們是否為某人通過執行 bitcoind 加上 --force-wallet-screw-me-over-now-now-now 創建的錢包保留相容性」。

這種類型的旗標將允許測試和合併單獨的功能，但在所有針對特定版本的功能都已合併之前，預設情況下不會啟動。

反對二進位發布的聲明

背景

在會議開始前幾天，Bitcoin Core 專案的一個分叉僅發布了二進位版本，他們聲稱是出於安全原因。

討論

Gregory Maxwell 詢問開發者是否願意簽署一份關於 Bitcoin Core 承諾永遠不會在沒有原始碼的情況下發布二進位檔案的聲明。聲明開始：

Bitcoin 專案永遠不會要求使用者在不提供原始碼的情況下執行二進位檔案。如果它這樣做，你可以安全地假設該專案的實際貢獻者被鎖在某處的地下室。在這種情況下，請派遣救援。

Bryan Bishop 建議人們不僅派遣救援，還要派遣食物。

還有其他幾個建議來完善聲明，但沒有人反對該聲明。

結論

沒有明確的結論。可能 Maxwell 將繼續完善聲明並為其收集簽名。

被封鎖和需要審查的 PR

背景

Matt Corallo 建議：「每週呼籲『你被封鎖在哪個 [Pull Request (PR)] 上並想要審查』，儘管我之前這樣做時結果好壞參半。」

討論

• Corallo 請求 #9725：CValidationInterface 清理

• Wladimir van der Laan 和 Jonas Schnelli 請求 #9294：對找零輸出使用內部 HD 鏈（hd split）

• Gregory Maxwell 請求 #9959：Mining: 防止大型記憶池上的 CreateNewBlock 減速

還有關於使用 GitHub 專案看板或使用標籤追蹤審查請求的討論。

結論

鼓勵審查者專注於上述 PR。會議中沒有就使用專案看板或標籤進行請求的審查做出決定。

幽默時刻

<wumpus> proposed topics?

<btcdrak> holiday at the beach?

<petertodd> btcdrak: that's what the financial crypto conference is for

<kanzure> rationale section was good, although i think it would be worthwhile to
          describe the 'exhaustive search'

<gmaxwell> kanzure: we left out a lot of technical minutia about the construction
           which is interesting but not really relevant to the spec.

<sipa> earlier version explained finite field arithmetic and generator polynomials :)

參與者

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。