IRC meeting summary for 2018-05-24

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

本週會議討論的主題包括：在產生版本 0.16.1 的第一個候選版本之前需要解決的問題、是否應該稍微延遲交易轉發以潛在地增加支付者隱私、如何儲存 Bitcoin Core GUI 和守護程序內部設定的設定，以便兩個程式都可以存取它們，以及 Bitcoin Core 是否應該新增掃描 UTXO 集的功能，即使它（假設性地）在未來可能不會以可掃描的形式儲存 UTXO 集。

[需要為] 0.16.1 [做什麼]

背景： Bitcoin Core 貢獻者正在努力發布 Bitcoin Core 0.16.1，這是一個維護版本，將包含錯誤修復和小改進。

討論（記錄）： Wladimir van der Laan 提出了主題，並直接討論了需要做的事情，這似乎是獲取拉取請求（PR）#13317 的審查。關於與 0.16.1 無關的 PR 是否應該獲得高優先級，有一些討論，Van der Laan 反對「我認為我們現在應該專注於 0.16.1；我們下週會再回到其他高優先級的東西。」

提出了兩個 PR 用於向後移植，#12172 和 #12431，但都被反對為有問題或不必要。

結論： 鼓勵審查者查看 #13317。

每個網路群組的隨機延遲以混淆交易時間

背景： 很多年前，當 Bitcoin 軟體收到一筆交易時，它很快就會嘗試將其轉發給其他對等點。這允許交易分析組織連線到大量節點，並假設他們從中接收交易公告的第一個節點可能是建立它的節點（或至少是最早轉發它的節點之一）。在 Bitcoin 版本 0.2.10 中，新增了一個功能，導致節點在將新交易轉發給不同群組的對等點之前等待不同的時間；這導致交易在網路中以較不可預測的方式傳播，以增加支付者隱私。後續版本改進了這個基本功能。

PR #13298 描述了上述方法的可能對策：交易分析組織多次連線到每個節點，增加他們更早而不是更晚聽到交易的機會，因此增加他們從中接收交易的第一個節點是其原始發送者的機會。同一個 PR 還提供了一種方法，透過使隨機延遲基於網路群組（大塊 IP 位址）而不是個別節點，來使多個連線對分析組織來說更昂貴，因此分析組織需要存取特定的 IP 位址範圍才能獲得成為早期接收者的相同機會

討論（記錄）： Pieter Wuille 提出了這個主題並描述了他想看到的：「我想簡要提出 #13298 […] 這對 P2P 交易轉發可能產生重大影響，它需要超越『程式碼是否運作』的審查。但它也只是本地政策，而不是需要 BIP 的東西[我認為]。也許沒有更多要說的了，[我]只是希望讓人們考慮一下。」

P2P 交易轉發上可能的重大影響是延長交易（但不是區塊）從其發起對等點傳播到 90% 或更多其他節點所需的時間。

結論： 沒有討論，只是建議審查者訪問 PR，考慮其影響，並提供任何建議的評論。

GUI 修剪設定和可寫入的設定檔

背景： Bitcoin Core 提供命令列選項和使用者可編輯的設定檔（bitcoin.conf），但它也允許使用者在圖形使用者介面（GUI）中變更一些相同的設定。目前這兩組設定儲存在不同的位置，因為 GUI 無法變更設定檔（在某些系統上，它是唯讀的，並且在所有情況下它可能包含使用者評論和格式，自動設定編輯器可能會破壞）。但是，這會產生幾個問題，其中使用者在一個地方變更設定，它意外地在另一個地方套用或不套用。共享設定的最新案例是 PR #13043，它為 GUI 新增了控制先前可從命令列和設定檔使用的修剪的能力。

討論（記錄）： Sjors Provoost 提出了這個主題，並建議了三個解決在不同 Bitcoin Core 程式之間共享設定的儲存位置問題的解決方案：

1. 「忽略這個問題。」繼續使用目前的系統。

2. 「走可寫入設定檔的路線。」（稍後討論會進入更多細節。）

3. 「以不同的方式解釋缺少 prune= 設定。」給設定檔中指定的選項優先於 GUI 中配置的選項。

Provoost 補充說：「如果我們選擇[選項] 2，那麼我想提名 PR[] 進行優先審查。」該 PR 新增了一個新的 bitcoin_rw.conf 檔案，用於軟體修改的設定。與 Qt 設定不同，該檔案可以在 Bitcoin Core 的守護程序和 GUI 之間共享，並且該檔案將被明確標記為不打算支援評論、基於空白的格式和其他人工編輯的便利性。

Jonas Schnelli 抱怨說：「我們想要四(!)層設定嗎？設定[檔] <-> 啟動[命令列介面參數] <-> Qt 設定 <-> 第 4 層 [bitcoin_rw.conf]。」

Provoost 解釋說：「我也想完全擺脫 Qt 設定 […] 我在 PR[] 中編寫了從 QTSettings 遷移的程式碼。」Schnelli 對此選項感到滿意並說：「感謝 [Provoost] 為此工作！」

Gregory Sanders 建議「使用者可以在很大程度上遷移到 [bitcoin_rw.conf]，除非他們需要唯讀。」Wladimir van der Laan 反對這一點：「嗯，bitcoin.conf 是用於人工編輯的；[bitcoin_rw.conf] 是機器可寫入的，所有評論都將被丟棄，等等…」

結論： 沒有明確的結論；會議參與者似乎贊成繼續建立 bitcoin_rw.conf 來儲存軟體修改的設定。關於目前開放的修改設定的 PR 是否應該等待 bitcoin_rw.conf 可用後才合併，或者應該使用現有的次佳 Qt 設定機制，有一些未解決的討論。

ScanTxOutSet RPC 命令

背景： Bitcoin Core 軟體維護著每個未花費交易輸出（UTXO）的鍵值資料庫——即每個可花費的比特幣群組以及為了花費它們需要滿足的條件。該資料庫不是為一次由多個程式存取而設計的，並且不是 API 穩定的，這意味著其他程式無法輕鬆地從中讀取，因此目前沒有便捷的方法讓其他程式從 UTXO 集中檢索資訊。

討論（記錄）： Jonas Schnelli 提出了這個主題並介紹說：「Pieter Wuille 對在 PR #12196 中提議的 scantxoutset 命令提出了擔憂。在繼續 PR[] 之前，我們可能想討論它是否有意義[…]。掃描功能允許無需掃描區塊的 UTXO 掃掠（rawsweeptransaction）。你可以傳入 n 個公鑰/位址，甚至 [HD 錢包擴充公鑰]和查找視窗，它會給你回傳所有未花費的[輸出]（甚至還有一個 rawsweeptransaction 到單一位址）。」

Wuille 描述了他的擔憂：「我只是提到我們最好不要承諾具有在未來難以維護的功能。[例如，在可能的未來使用] UHF 模型，在沒有索引的情況下實作 UTXO 集的掃描需要瀏覽區塊鏈。」[注意：討論中標記為「UHF」的在其他地方稱為「UHS」；請參閱連結。]

Johnathan Corgan 建議：「如果我們想鼓勵人們將 bitcoind 視為『真實來源』，而不是建立他們自己的東西，給他們更容易存取『資料庫』會有所幫助。」

Wuille 承認這個問題「不那麼令人擔憂[因為更容易]現在透過 [Jim Posen 的]背景索引工作新增選用索引。之前，新索引總是需要在驗證程式碼中到處進行醜陋的修改。」

結論： 「這正在變成一場哲學討論，」Wuille 在討論接近尾聲時評論道。沒有明確的結論，但似乎如果新增了 scantxoutset RPC 或類似的 RPC，可能會在發行說明中新增警告，指出它可能需要在未來啟用選用索引。

幽默時刻

[...Things start to break...]
     <mquin> [Global Notice] [...] There are ongoing issues with
             services that are being looked into - please bear
             with us
      <sipa> fun.
<instagibbs> err what
    <wumpus> services massacre
   <cfields> irc unicorns...
             let's move to slack!
             (/s)
    <wumpus> :-(

參與者

免責聲明

本摘要是在沒有討論參與者任何輸入的情況下編譯的，因此任何錯誤都是摘要作者的責任，而不是討論參與者的責任。特別是，從討論中摘錄的引言的大小寫、標點符號和拼寫已被修改以產生一致的句子。方括號中的單詞和片段，以及背景敘述和說明，都是由本摘要的作者新增的，可能不小心改變了某些句子的含義。如果你認為任何引言被斷章取義，請開啟一個議題，我們將更正錯誤。