IRC meeting summary for 2016-03-03

• 本週記錄連結
• Meeting minutes by meetbot

VersionBits (BIP9) 軟分叉邏輯

背景：BIP9 是一種部署軟分叉的機制，取代了用於部署 BIP 34、66 和 65 的 IsSuperMajority() 機制。舊方法要求軟分叉按順序進行，因為礦工表示他們準備好執行軟分叉 3 號時，也必須表示他們願意執行軟分叉 2 號和 1 號。因此，我們目前會等待軟分叉 1 號完全執行後再嘗試軟分叉 2 號，並等待 2 號完全執行後再嘗試軟分叉 3 號。這可能造成延遲，並對下一個執行哪個軟分叉產生爭議。VersionBits 允許礦工表示準備執行最多 29 個不同的軟分叉，並提供一些其他優良功能，例如更好的執行時間可預測性。

今天的討論集中在 Pull Request (PR) #7575 和 BIP 最近的一些變更上，「只要（軟分叉）部署的開始/結束時間不重疊，（區塊標頭版本，即礦工用來表示準備執行的）位元就永遠不會模糊。（這意味著）不需要追蹤不同部署之間的相依性，（它們）只（需要）明智地選擇開始/結束時間」(Pieter Wuille)。幾位參與者對此表示滿意。

關於不同的 BIP9 議題，Gregory Maxwell 說：「考慮到低變異數觸發機制和啟動延遲，我仍然有點擔心啟動門檻可能太高。但我認為除了嘗試看看我們的第一個 versionbits 分叉是否無法在合理時間內啟動之外，別無他法。」VersionBits 的啟動門檻為 95%，與 IsSuperMajority() 使用的相同，但 VersionBits 是在 2,016 個區塊上測量，而不是 1,000 個區塊，並且每 2,016 個區塊僅測量一次，而不是像 IsSuperMajority() 那樣每個區塊都測量。這意味著即使其他所有礦工都發出準備信號，產生少於 5% 區塊的小型礦工仍然可能阻止分叉觸發，只是因為該小型礦工在該期間「幸運」地產生了超過 5% 的區塊。

Pieter Wuille 回應 Maxwell 的擔憂說：「如果需要，我們可以降低門檻；提高[它]更困難，因為這可能導致警告不會觸發。」

對話繼續討論如何優化 Bitcoin Core 的迴歸測試 (regtest) 模式，以測試 4,032 個區塊的長鏈，例如 versionbits 測量的那些。

本次討論的最終行動項目：

• Pieter Wuille 將對 PR #7575 進行一些變更
• 鼓勵所有共識協議開發者審查 #7575 和 BIP9，因為這些很可能很快就會用於一個或多個待處理的軟分叉。

交易積壓

背景：在會議前的幾天內，廣泛報導許多節點的記憶體池包含高於正常數量的未確認交易。雖然系統狀態的重大變化在任何情況下都值得調查，但最近發布的 Bitcoin Core 0.12.0 及其對記憶體池政策的重大變更可能使調查這一點比平常更重要。

[編輯註：這次討論有點漫無邊際，即使會議主持人說「好吧，我們正在離題」，也沒有任何正式的主題變更。我將其分為幾個小節以希望提高清晰度，但這使某些元素明顯脫離了線性順序。]

關於目前狀況，Maxwell 說：「現在每位元組超過 1 satoshi 的交易費用有所增加。低於該[每位元組費用]水平約一千兆位元組的長期背景垃圾負載對我來說似乎基本上沒有變化。」

Luke Dashjr 問：「有人調查過這些新交易是真實的還是垃圾訊息嗎？」Maxwell 回答：「有些人調查過；Peter Todd 在推特上發布了一些分析，強烈支持後者。」

Peter Todd 補充說：「是的，它們看起來像長鏈，最終一切都回到發送者那裡。但還沒有正式的書面報告[關於這項分析]。」

Alex Morcos 說「在我看來，積壓正在減少」。

選擇性 Replace-by-Fee (RBF) 使用

Peter Todd 指出 GreenAddress.it (GA.it) 錢包「在他們的 GitHub 儲存庫中有 RBF 程式碼」。Maxwell 同意：「GA.it 一直在致力於此；我認為他關於如何最好地支援使用額外輸出更新[交易]的設計陷入了困境。順便說一下，有了新的 Schnorr 聚合簽名提案，更新更多輸出將更具吸引力。」

Schnorr 聚合簽名提案將允許同一交易的多個輸入共享簽名欄位，如果它們都使用足夠相似的腳本（如果它們都由同一個錢包花費，這是預期的）。由於簽名是典型交易中最大的單一部分，能夠將多個簽名組合在一起而不損失安全性，可以顯著壓縮交易。由於 Replace By Fee (RBF) 交易中支付的費用基於交易大小，這種壓縮將使 RBF 在省錢方面比今天傳送單獨交易更有效率。

-paytxfee 語意變更

背景：在會議前大約 24 小時，開發者 Mike Gogulski 在 Bitcoin Core 儲存庫中開啟了一個問題，報告 -paytxfee 設定選項的行為隨著 Bitcoin Core 0.12.0 的發布而改變

「所以我認為發生了什麼，」Pieter Wuille 寫道，「是在某個時候我們將挖礦程式碼切換為每位元組而不是每千位元組。後來引入了[一個]全域[變數]，即使程式碼的其餘部分已更新為每位元組，它隱式地保留了『四捨五入到 1,000 位元組進行費用計算』的行為，只是現在，隨著全域[變數]的消失，我們實際上得到了準確的變更。」

由於使用此設定選項時交易大小以前會四捨五入，但現在正在精確計算，因此現在每位元組支付的費用低於使用 -paytxfee 旗標的使用者的預期。請注意，此語意變更僅影響手動設定此選項的使用者。

Alex Morcos 提到 -maxsigcachesize 基本單位也已變更；現在是以兆位元組為單位。他建議：「在變更任何選項或 RPC 呼叫的行為時有一個檢查清單 […] 我不確定有多少人會在兩英尺厚的發布說明中發現所有這些警告，但擁有它們仍然很好。」

FeeFilter

背景：Alex Morcos 最近提出的 draft BIP133 建議在 P2P 協議中新增一條新訊息，允許節點告訴其對等節點，它只想接收關於新交易的通知，如果這些交易支付的每位元組交易費用超過某個水平。請求過濾掉低費用交易的節點可以選擇它想要的任何每位元組費用水平。由於今天的節點無法告訴其對等節點它們不會處理低費用交易，因此相信引入此訊息將減少網路上浪費的流量。

討論極為簡短。Morcos 說：「它減少了約 40% 以上的交易傳送和接收頻寬」。Maxwell 回答：「太棒了」，還說「feefilter 很棒」。

Dashjr 建議 feefilter「需要某種『模式』來處理『我們如何測量大小』等問題，但[那]不是什麼大問題。」Morcos 有不同的看法：「我基本上認為我們在需要之前不引入複雜性。」Maxwell 同意：「我們不會用完訊息類型，所以我們可以稍後引入 modefilter」。

從長遠來看，Maxwell 補充說：「我預計中繼工作方式會在未來幾年發生重大變化；所以我們可能不應該在這裡過度設計。」

feefilter 的行動項目是更多審查和測試。

Child Pays For Parent (CPFP) 挖礦

背景：Suhas Daftuar 有一個進行中的 (WIP) pull request，透過考慮未確認交易加上其子交易的組合費率來幫助礦工建立更有利可圖的區塊。這不僅對提高礦工獲利能力有用，而且還允許使用者透過建立高費率的子交易來有效地為已經在礦工記憶體池中的交易新增費用，這通常稱為 Child [transaction] Pays For Parent [transaction] (CPFP)。

Daftuar 報告：「我在過去兩天一直在執行[該程式碼]。[我一直在]大約每 128 筆交易比較現有的挖礦演算法和新演算法。[當]查看找到區塊之前對 CreateNewBlock() [函數]的最後一次呼叫時，我看到最後 144 個資料點的費用/區塊有[顯著]增加。」

Maxwell 解釋了為什麼預期會有非微不足道的獲利能力增加：「我相信它應該會從我所看到的情況中對選擇產生一些相當大的差異。許多 OTHERBRAND [原文如此] 錢包的使用者沒有費用估算，總是花費未確認的找零，似乎經常產生非常低費用、非常高費用的鏈（在意識到他們需要從第一筆交易中支付更多費用之後）。」

關於用於測試獲利能力增加的方法的討論解釋說，該測試可能多次計算了一些交易，因此每個區塊捕獲的費用的確切增加可能少於測試所指示的。儘管如此，在其他條件相同的情況下，人們可以安全地假設礦工會樂於執行增加其潛在獲利能力的程式碼。

然後 Daftuar 報告了新程式碼在效能方面的成本。「所以有三個效能方面需要考慮：

1. 「記憶體池保持[相關交易及其費用的]索引的額外工作

2. 「在呼叫 TestBlockValidity() 之前 CreateNewBlock() 的部分

3. 「TestBlockValidity 花費的時間（[這]比 CreateNewBlock() 的其餘部分大得多，這就是為什麼我認為將它分開是有意義的）」

技術討論繼續，Daftuar 提供了他測試的數字。結果和測試方法可以在 PR #7594 和 #7600 中找到。在一種情況下，這個新程式碼似乎加快了與挖礦相關的過程，而在至少另一種情況下，減速似乎微不足道。

行動項目：「[讓]人們開始審查 CPFP [PR] #7594、#7598 和 #7600。」

後記：在會議後的討論中，Maxwell 向 Daftuar 建議「如果 CPFP 似乎相當穩定，我們可能會考慮要求一個中等規模的礦工執行它（與其他東西平行）；如果只有一個中等規模的礦工正在執行它，它將對網路具有大部分的可用性優勢。[…] 我建議這樣做的唯一原因是，至少有一些使用者的延遲可以透過[執行]它來避免。」Daftuar 似乎同意，並表示他將與 Maxwell 合作尋找礦工進行現場測試。

Segregated Witness (segwit) 狀態

背景：幾位開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證，並在特殊測試網上進行初步測試。隔離見證允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。

Eric Lombrozo 首先說：「幾天前我們有一個[鏈]分叉」。Wuille 回答：「我沒有時間調查；我希望這是由執行舊版本 [segwit] 程式碼的礦工造成的，而不是其他原因」。Lombrozo 承認「這是最有可能的 - 但我們還沒有縮小實際導致它的條件。」

Wuille 說：「我計劃很快做一個 segnet4，但我們需要先了解是什麼導致了這個問題。」

Morcos 問：「有人卡在短分叉上嗎」，Lombrozo 回答：「我認為可能還有一些」。Cory Fields 說「我有興趣看看那裡」。

Maxwell 建議一個除錯工具：「[如果] regtest 網路將其 git 構建資訊放在版本號中可能會很有用。[這]對隱私來說很糟糕，但[它]在這裡會很有用。」

行動項目是幾個人將致力於確定分叉的原因。

結論

會議在預定結束時間結束，議程上仍有一些項目。一些會後立即討論已被整合到本摘要中。

娛樂時刻

gmaxwell:  okay, we're going on a tangent.
sipa:      going on a tangent is a sin
morcos:    oh no
CodeShark: no trig puns
sipa:      I co-sign that

參與者

免責聲明

引用的討論內容經過修改，調整了大小寫、標點符號和拼寫以產生一致的句子。括號內的詞語和片段以及背景敘述和解釋性說明是由本摘要作者新增的，可能會意外改變某些句子的含義；如果您認為任何引用脫離了上下文，請聯絡我們，我們將糾正錯誤。

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