IRC meeting summary for 2018-04-12

• 本週會議記錄連結
• MeetBot 會議記錄

本週會議討論的主題包括：專案成員希望審查者在下週重點關注的拉取請求、是否要取消錢包中一個奇怪且很少使用的功能（IsMine 裸多重簽章）的相容性、如何安全地改進多錢包支援，以及在升級 Bitcoin Core 可重現二進位發行版的建置環境時，如何處理一些不再支援的軟體。

高優先級審查

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

討論： 本週建議關注的 PR 如下：

1. 在驗證的同時平行建置交易索引（#11857），由 Jim Posen 和 Wladimir van der Laan 提名。此 PR 將選用的交易索引（允許使用者透過 txid 查詢歷史交易）移到單獨的資料庫中。這將允許使用者在節點執行時啟用或停用交易索引，而不必等待數小時（即使在快速硬體上也是如此）。此 PR 也為 Bitcoin Core 新增額外的獨立索引奠定了基礎，這些索引可以啟用諸如 BIP 157 和 158 中描述的輕量客戶端改進隱私區塊過濾等功能。

   在會議之前，此 PR 已經收到一些正面的審查，但要求了一些變更，現在已經完成，因此會議中的討論集中在讓這些變更本身得到審查。

2. 非 HD 錢包升級到 HD 的路徑（#12560），由 Van der Laan 提名。此 PR 新增了一個新的 sethdseed（設定 HD 種子）RPC，允許使用者為 BIP32 階層式確定性（HD）錢包設定種子值。這可用於請求 Bitcoin Core 自行產生新種子，或將種子變更為從目前執行的 Bitcoin Core 外部獲得的值（例如從備份中）。此外，此 PR 允許舊版非 HD Bitcoin Core 錢包的使用者使用 -upgradewallet 命令列參數升級到 HD 錢包。

   會議中的討論指出，此 PR 可能有一個尚未解決的問題，但主要需要來自其他貢獻者的審查。

3. 將費用估算器移到 validationinterface/cscheduler 執行緒（#11775），由 Van der Laan 提名。此 PR 對 Bitcoin Core 程式碼中的一些內部介面進行後端變更，然後變更 Bitcoin Core 的費用估算器以使用其中一個介面，使其能夠存取對費用估算有用的其他資訊。此 PR 還對費用估算器在處理邊緣情況的方式上進行了一些小改進。

   在會議之前，此 PR 的作者（Matt Corallo）提議將此 PR 拆分為針對不同部分變更的獨立較小 PR。會議期間的討論指出，審查者正在等待這件事發生後才進一步審查。

4. 引入 getblockstats RPC 來[提供可用於]繪製圖表的資料（#10757），由 Jorge Timón 提名。此 PR 新增了一個新的 RPC，回傳關於指定區塊的各種詳細資訊和統計資料。

   會議中的討論看到一位貢獻者同意審查此 PR。

討論期間提到的一個問題是 GitHub 最近頁面載入失敗的問題，持續時間相當長。這個問題已經變得足夠頻繁，以至於會議參與者透過引用 GitHub 在錯誤頁面上顯示的圖畫——一隻獨角獸——來提及這個問題。

如何處理裸多重簽章上的 IsMine

背景： 裸多重簽章是指支付給多個公鑰而不使用更常用的 P2SH 或 segwit 位址。Bitcoin Core 的錢包目前會掃描任何裸多重簽章付款，以查看是否使用的每個公鑰都是使用者錢包的一部分，如果是，則將付款分類為 IsMine，表示使用者可以花費它。

討論： Pieter Wuille 提出了這個主題。他將目前的行為描述為「愚蠢、惱人、毫無意義且難以維護」。對於愚蠢和毫無意義，問題可能是當所有公鑰都屬於同一個錢包時，多重簽章並不比單一簽章提供任何額外的安全性，但使用多重簽章確實比單一簽章花費更多。對於惱人和難以維護，問題是這種行為需要額外的程式碼，並且使開發者更難以朝著 Wuille 先前描述的改進錢包設計邁進。

Wuille 接著描述了他的擔憂：「可能已經有現有的輸出給它。我不知道是否是這樣，但僅僅停止支援它聽起來很可怕。」經過一番討論，Wuille 澄清他並不是提議刪除允許這些付款的擁有者花費它們的程式碼；相反，Bitcoin Core 將不再自動看到這些付款。

Corallo 和 Wuille 之間的進一步討論提供了對問題的生動描述：要在所需的新錢包模型中支援這種舊行為，需要產生 N³ 個組合，其中 N 是使用者擁有的私鑰數量。預設情況下，Bitcoin Core 產生 2,000 個私鑰，因此錢包需要產生難以管理的 80 億個組合。

持續的討論圍繞著 Wuille 的 PR #12874，該 PR 停用目前的行為並為需要它的使用者提供一個解決方法。Corallo 提到現有的 RPC importaddress 已經為解決方法提供了必要的重要功能。

結論： 儘管會議參與者贊成在有合理方法的情況下保留現有功能，但討論似乎傾向於刪除裸多重簽章上的 IsMine，並在發行說明中提及解決方法。

動態錢包載入/卸載

背景： 舊版本的 Bitcoin Core 只能在特定節點上使用單一內建錢包實例。這在版本 0.15.0 中擴充為允許多個錢包實例，但 Bitcoin Core 的舊部分（例如啟動時讀取的命令列選項）假設使用者只有一個錢包實例，因此它們會同時對所有載入的錢包進行操作。John Newbery 的拉取請求 #10740 透過允許使用者在執行時使用新提議的 RPC 載入、卸載甚至可能建立錢包來為此提供解決方法。

討論： Joao Barbosa 提出了這個主題，建議「…錢包管理應該使用共享指標」。這將有助於確保如果使用者在執行時請求卸載錢包，則可以在卸載錢包之前處理涉及該錢包的待處理請求。另一種情況可能是錢包在操作過程中意外消失，這可能會導致意外和有害的影響。Barbosa 已開啟 PR #11402 來進行此提議的變更。

此提議似乎沒有爭議，討論轉向其他改進以及應該實作這些改進的順序。Jonas Schnelli 建議 Bitcoin Core 首先需要一個 createwallet RPC，以便可以在執行時建立錢包，並且可以停用命令列錢包選項（或可能僅限於單錢包使用）。Pieter Wuille 指出，如果沒有執行時載入錢包的方法，執行時的 createwallet 會很奇怪，因為你必須重新啟動 Bitcoin Core 才能使用剛建立的錢包。

Luke Dashjr 建議順序為「載入 -> 建立 -> 卸載」，因為「卸載是複雜的部分」，可能是因為同時處理多個程序在載入的錢包上工作的潛在問題。Newbery 同意並對 Schnelli 的建議「將卸載從現有 PR 中拆分出來」做出了正面回應。

Wladimir van der Laan 建議「卸載可能應該分兩個階段：請求後，RPC 和 GUI 失去對它的存取權。然後它等待目前的操作完成。然後真正[卸載]該東西。」

結論： Newbery 同意他將修改他的 PR，在 PR 本身上說他將「將此 PR 的範圍縮小到只有一個 loadwallet RPC。接下來應該是 createwallet RPC，然後是 unloadwallet。（unloadwallet 是大部分困難所在）。」

Gitian 更新

背景： Bitcoin Core 使用一個稱為 Gitian 的系統，以一種任何擁有電腦和網際網路連線的人都可以完全重現的方式建置其發行二進位檔案，允許任何人驗證發行二進位檔案是經過同行審查的原始碼的產物。隨著 Bitcoin Core 的變更、建置目標作業系統的變更以及其他軟體可用性的變更，Gitian 建置環境需要更新以處理這些變更。

討論： Luke Dashjr 提出了這個主題，似乎與專案希望將 Gitian 使用的作業系統切換到即將推出的 Ubuntu 18.04 LTS 有關。Dashjr 的擔憂是「我們需要 vmbuilder 的替代品或其他東西，因為 Canonical 尚未更新它以支援任何最新版本。」Vmbuilder 是一個工具，允許在常規作業系統下建立和執行子作業系統，以便在其中建置軟體。vmbuilder 的一個理想功能是它可以在虛擬機器中建立子作業系統，將其與主要作業系統完全隔離，有助於防止你正在建置的程式碼中的任何問題影響實際的作業系統。

Wladimir van der Laan 建議使用 debbootstrap（Debian bootstrap），這是一個早於 vmbuilder 的工具，它使用 chroot 而不是虛擬機器，允許它欺騙正常軟體認為它正在單獨的作業系統中建置，但它並沒有做任何重要的事情來防止惡意軟體攻擊主要作業系統。儘管其他開發者（如 Cory Fields）贊成遷移到 debootstrap，Dashjr 仍然擔心並說：「我想修復 vmbuilder 可能不是太不合理的努力，也許我會嘗試一下。」

Andrew Chow 補充說，他「正在考慮為 Gitian 新增 Docker 支援，這樣我們將使用預設的 Ubuntu docker 映像，然後從那裡建置。」Docker 可能比 chroot 更安全，但通常不如虛擬機器安全。Dashjr 指出，Docker 也僅限於大多數桌上型電腦和伺服器使用的 x86_64 平台，而一些專案貢獻者認為在其他平台上建立一些可重現的建置是有利的，這些平台可能沒有 x86_64 上發現的問題，例如與 Intel Management Engine 相關的問題。

結論： 切換到 debootstrap，同時 Dashjr 可能致力於讓 vmbuilder 再次運作。長期而言，Fields 正在努力全面改革系統。

幽默時刻

<wumpus>      #topic dynamic wallet load/unload (promag)
<instagibbs_> what's the controversy in this topic :)
<sipa>        it should happen, duh
<sipa>        how and when is another :)

參與者

免責聲明

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