IRC meeting summary for 2017-03-16

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

主要議題

• 錢包應如何處理長鏈未確認交易
• 移除帳戶系統的狀態
• 修訂 make check 測試

錢包應如何處理長鏈未確認交易

背景

Bitcoin Core 允許其錢包使用者創建未確認交易鏈。例如，交易 C 花費來自交易 B 的找零，而交易 B 本身花費來自交易 A 的找零。

如果你以這種方式創建超過 20 個未確認交易的鏈，Bitcoin Core 0.14.0（預設）會拒絕你在該鏈上創建的任何新交易。這是因為 Bitcoin Core 中的其他邏輯不允許超過 20 個交易的鏈進入其記憶池，以防止其他人濫用你節點的資源。

在會議時，至少有兩個獨立的人開啟了關於此問題的議題，想知道為什麼他們不能創建交易。

或者，Bitcoin Core 以前允許使用者創建超過 20 個未確認交易的鏈，但只是不轉發深度超過 20 的交易或將它們加入記憶池，直到它們的一些祖先被確認。這意味著當你創建第 21 個交易時，你的錢包會扣除你花費的金額（你的輸入），但不會立即貸記你任何找零輸出。

例如，如果你將 10 BTC 輸入花費到 0.1 BTC 輸出，你會期望你的餘額下降 0.1 BTC——但相反地，它會下降 10 BTC，直到至少前 20 個交易之一被確認。

作為折衷，Bitcoin Core 0.14.0 提供了一個命令列選項，允許使用者選擇他們想要的行為：預設限制 20 個鏈式交易或無限鏈式交易但延遲餘額更新。

這個議題已經在開發者之間討論過很多，在會議中談論它的開發者都不滿意目前的行為——但到目前為止，沒有人提出一個能夠提供良好使用者體驗而不需要大量程式碼變更來處理這種相當罕見情況的解決方案。

此外，整個情況因網路上常規錢包交易持續存在的交易延展性而加劇。如果祖先交易被修改，其所有後代都將在同一區塊鏈上無效。在這種情況下不會損失金錢，但錢包需要一種方法來了解這些後代交易現在無效，並相應地更新錢包餘額。

意見

在試圖描述問題時，Alex Morcos 說：「在 PR 上進行這種討論有點困難」。根據聊天期間的混亂程度，在 IRC 中討論似乎也很困難。

Gregory Maxwell 建議：「這是我們目前定義只是被破壞的跡象。它不應該與記憶池如此緊密耦合（例如，對於沒有記憶池的人，軟體應該如何使用？——這是一個支援的配置！）。」

Pieter Wuille 回答：「如果你不依賴記憶池，我認為讓錢包重複計數並不難」，Wladimir van der Laan 擴展說：「所以如果它發送一個交易，有人修改它，它會收到被修改的版本，它會重複計數。」

Wuille 也補充：「不花費未確認找零的錢包沒有這個問題」。

討論偏離了手續費提升的話題一段時間，然後回到主要議題，Maxwell 指出：「沒有延展性，基本上所有這些找零處理議題都不會存在，我認為，因為你永遠不會有可能重複計數你自己資金的情況。」

結論

在討論這個議題超過半小時後，Morcos 建議：「好吧，我們偏離了軌道。現在——也許下一個議題，我們在思考這兩條路徑後一週後重新訪問這個」，這得到了所有會議參與者的熱烈贊同。

移除帳戶系統的狀態

背景

到 2010 年末，幾個網站提供的網路錢包和交易所基本上是 Bitcoin 軟體之上的一個薄層（它還沒有被稱為 Bitcoin Core）。在那段時間，Bitcoin 引入了一個帳戶系統，允許單個 Bitcoin 實例追蹤多個帳戶中的餘額。

後來，網路錢包和交易所實作了自己的會計後端，從那時起，Bitcoin Core 的帳戶系統大多未被使用——然而它使許多 RPC 呼叫複雜化，除了執行多使用者網路錢包之外，對任何事情都不是特別有用。（即將推出的功能，多錢包，將為想要分割不同比特幣集合的使用者提供真正的錢包分離。）

因此，在過去幾個版本中，與帳戶系統相關的所有功能都被標記為已棄用，並且正在被移除或轉換回帳戶起源的標籤系統。

討論

Wladimir van der Laan 總結了狀態：「可以很簡短：自上次討論以來沒有進展，因為我們需要先有一個標籤 API，然後才能考慮棄用帳戶。」

Matt Corallo 說：「這絕對應該在 0.15 中發生，IMO [in my opinion]」，Wladimir 同意但補充：「我同意，儘管 multiwallet 對我來說有更高的優先級。」

然後討論轉移到關於多錢包的議題，主要是哪些 pull request 對本週審查開發者有用，包括 PR#9294 和 PR#8694。

結論

審查上述 pull request 以在 multiwallet 上取得進展，並在標籤 API 上工作以移除帳戶系統。

修訂 make check 測試

背景

Bitcoin Core 提供了一個 makefile 目標 check 來執行專案的單元測試。該專案隨著時間推移編寫了越來越多通過 RPC 介面執行的整合測試，這些測試由 Travis 持續整合（CI）伺服器自動執行，該伺服器測試每個 Bitcoin Core pull request，可以通過執行 qa/pull-tester/rpc-tests.py 手動執行

討論

Jonas Schnelli 問：「將 rpc 加入到 make check 有什麼好處？」

Wladimir van der Laan 回答：「make check 理想上應該進行相當快速的檢查，一些 RPC 測試符合這個條件，但整個套件可能需要太長時間。」

討論繼續確保 make check 執行速度合理快，包括增加在多個 CPU 核心上執行它的能力。

結論

John Newberry 總結：「好的，聽起來至少在 make check 中進行一些 RPC 測試沒有根本性的反對。我會開啟一個 PR，我們可以在那裡繼續討論。」

幽默時刻

<wumpus> gmaxwell: yup. don't know if you saw the clang fsafe-stack
         issue that messes up deterministic signing

<gmaxwell> wumpus: I didn't.

<wumpus> gmaxwell: let me dig it up
         gmaxwell: https://github.com/bitcoin-core/secp256k1/issues/445

<gmaxwell> wumpus: holy fuck!

（上述內容的背景：Bitcoin Core 和 libsecp256k1 的測試發現了編譯器中引入的錯誤，可能會造成嚴重問題。）

<gmaxwell> without malleablity basically none of these change handling issues
           would exist, I think.
           as you'd never have a case where you might double count your
           own funds.

<wumpus> unfortunately we're stuck with malleability

<morcos> not if we use flextrans
         (sorry)

<gmaxwell> hah

<jonasschnelli> heh

<wumpus> flextrans, lol

<BlueMatt> trolol

參與者

免責聲明

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