2016-12-01 IRC 會議摘要

• 本週會議記錄連結
• meetbot 會議紀錄

備註 / 簡短議題

• 由於 segwit 變更了來自 JSON-RPC API 的資料格式，已提出一個拉取請求，添加一個選項以返回非 segwit 序列化，以便未及時升級其函式庫的使用者仍然可以使用 RPC 介面。
• JeremyRubin 的更好的 SigCache 實作已準備好進入，但缺少一些審查。

主要議題

• Main.cpp 拆分
• 錢包中的 vchDefaultKey
• HD 復原

Main.cpp 拆分

背景

TheBlueMatt 正在進行重構 main.cpp 的工作。這應該使程式碼對新開發者更容易接觸，並改進程式碼審查和測試。

會議討論

PR #9183（main.cpp 拆分的最終準備）已準備好合併，已經有很多 ACK。

在主要拆分之後，回移可能會變得更複雜。仍需回移到 0.13.2 的 PR 有：

• #9253（修復計算要使用的綁定通訊端數量）
• #9229（移除對 getaddrinfo_a 的呼叫）
• #9194（添加選項以透過 rpc 返回非 segwit 序列化）
• #9188（使孤兒父取得要求見證）
• #9239（停用 1 個區塊目標的手續費估算）
• #9252（在呼叫 ProcessNewBlock 或處理標頭（cmpctblock 處理）之前釋放 cs_main）

會議結論

• 合併 #9183（main.cpp 拆分的最終準備）
• 專注審查「需要回移」標籤
• 回移完成後拆分 main

錢包中的 vchDefaultKey

背景

vchDefaultKey 是「預設位址」概念的遺留物，該概念在古老的 0.4.0 版本中被移除。Wumpus 開啟了一個問題討論這個行為。

它目前除了用於確定是否剛建立新錢包之外未被使用。

會議討論

Sipa 希望擺脫這個，但是如果我們這樣做，降級到較舊的錢包版本將導致重新掃描失敗。

鑑於這並不是很緊急，所以不需要虛擬金鑰等駭客手法。0.14 可以停止依賴 vchDefaultKey，但仍然寫入它，然後在 0.15 中刪除 vchDefaultKey 並將最低版本提高到 0.14，這樣 0.15 錢包將永遠無法在 0.13 中開啟。

會議結論

• 使用版本控制在 0.15 之前擺脫 vchDefaultKey

HD 復原

背景

自 0.13 以來，新建立的錢包將根據 BIP32 使用階層式確定性金鑰生成。錢包轉儲將包含 HD 種子，但尚無法匯入此種子。

會議討論

Jonasschnelli 認為復原 HD 種子應該是一個單獨的工具。該工具將建立一個新的 wallet.dat 並在之後執行重新掃描。該工具可以與 RPC 和 UTXO 集互動以檢測間隙限制。

Wumpus 建議在進行額外工作之前，先審查並合併目前的錢包 PR。PR #9143（重構 ZapWalletTxes 以避免層違規）、#9256（修復更多 CWallet/CWalletDB 層違規）和 #8723（添加對靈活 BIP32/HD 金鑰路徑方案的支援）需要一些審查。

Gmaxwell 認為在修復路徑拆分問題之前，我們應該避免在 HD 支援中添加更多複雜性。問題在於找零輸出與接收金鑰在同一鏈上，因此你最終可能會將找零金鑰作為位址分發出去讓人們付款（對你隱藏他們的付款），或者如果你從 hd 資料復原錢包，找零可能會顯示為付款。

低懸果實可能是在金鑰池中添加「已使用」標記，並將 HD 錢包的預設金鑰池增加到 1000，因為目前的 100 真的很小。

會議結論

• 審查 #9143（重構 ZapWalletTxes 以避免層違規）、#9256（修復更多 CWallet/CWalletDB 層違規）和 #8723（添加對靈活 BIP32/HD 金鑰路徑方案的支援）
• 專注於拆分金鑰路徑

幽默時刻

gmaxwell      我剛注意到 #9188 還沒合併。
gmaxwell 看看自己是不是延遲的原因
gmaxwell 不是延遲的原因

參與者

免責聲明

本摘要編寫時未徵詢任何討論參與者的意見，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。