IRC meeting summary for 2016-03-10

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

Segregated witness (segwit) 協調

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

Pieter Wuille 開始說：「我的計劃是將 segwit 重新建立在 BIP9 [versionbits] 之上，新增 BIP9 倒帶邏輯以在軟分叉後升級後繼續，並建立一個新的 segnet [segwit 測試網]。」

從這裡開始的對話討論了標準性政策和新的比特幣地址類型：

標準性政策

[編輯註：BIP9 使用「active」一詞表示「對所有新建立的區塊強制執行」。舊的軟分叉使用具有不同含義的「active」，但為了一致性，下面的文字在所有情況下都使用 BIP9 的含義。]

Suhas Daftuar 要求討論標準性政策，這是節點預設遵循的可選政策，用於決定要中繼或挖掘哪些交易類型。segwit 軟分叉將建立一種新型交易，就像 BIP16 軟分叉建立 P2SH 交易類型一樣，正如在 P2SH 軟分叉啟動之前花費 P2SH 輸出的任何人（有人這樣做了）可能會被盜取該輸出中的比特幣一樣，在 segwit 軟分叉啟動之前花費 segwit 輸出的任何人也可能會被盜取該輸出中的比特幣，如果花費交易在區塊外傳送，或者包含它的區塊從最佳區塊鏈分叉出去。

「我相信我們決定建議錢包作者在 segwit 啟動後等待一段時間再使用[它]」，Daftuar 在 Alex Morcos 的同意下說，描述了一項將決定權留給錢包作者及其使用者的政策。Pieter Wuille 描述了將使用標準性規則的替代方案，「一種可能性是在啟動後 2 個[重新定位期]後才啟用 segwit 交易的中繼/記憶體池邏輯。」這是啟動後約一個月。「另一種可能性是謹慎行事，在軟分叉後版本發布之前不啟用錢包中的功能。」Wuille 既不認可也不拒絕這些替代方案；他只是將它們描述為選項。

Gregory Maxwell 沒有評論是否應該使用標準性政策，但對於 Bitcoin Core 自己的錢包，他建議：「我建議我們在軟分叉啟動後的後續版本中將使用 segwit 作為預設值。我建議使用[後續]版本[因為]這裡不需要自動行為。此外——使用它是一個相當大的行為變化，例如您將回應發出其他地址樣式。讓[使用者介面變更]由對使用者不可見的網路行為觸發並不好。」

行動項目： 討論似乎圍繞著將決定權留給錢包作者而不是建立臨時標準性政策，但沒有達成具體決定，Eric Lombrozo 建議討論轉移到其他主題，「這是可以在 segwit 已經部署並正在等待啟動後決定的事情」。

Segwit 地址類型

背景：segwit 的初始公告要求支援 segwit 的錢包可以透過兩種方式請求付款，一種方式使用完善的 P2SH 地址樣式；另一種將提供完全針對 segwit 最佳化的新地址樣式。BIP142 是該新地址樣式的提案，但由於專案內外的擔憂，對它的支援已從初始 segwit 實作計劃中刪除。

Wuille 開始討論：「我希望我們有一個 segwit 地址樣式作為標準的一部分。」Morcos 同意：「我認為我們應該這樣做，否則每個人都會將 [segwit] 嵌入 P2SH 中，這有點愚蠢。」

Lombrozo 解釋了為什麼它不是初始標準的一部分，「我們沒有推動 BIP142，因為擔心可怕的『新地址』。在[專案]內部，有些人討厭 base58；在外部，有些人仍然以『segwit 太難了』的廢話嘩眾取寵。我認為這是一場不值得現在打的戰鬥。」BtcDrak 表示同意最後一句話。

Maxwell 解釋了他為什麼反對 BIP142 的地址樣式：「[繼續]使用 base58 是糟糕的。」不太認真地（如表情符號所示），他繼續說：「我將拒絕與任何沒有透過電話向我讀過地址的人討論地址編碼。」

Matt Corallo 補充說：「在這裡為 segwit 找出地址不是我們的工作——這是錢包需要參與的事情——真正具有一些使用者體驗經驗的人，這裡不存在。」（原文強調。）Maxwell 同意：「是的，確實如此，但這也是為什麼在[發布 segwit 的]同時採用新地址類型不是一個好主意，它會妨礙這種協作。」

Wuille 仍然不相信：「我認為恰恰相反。」Maxwell 指出還有另一個理由暫時推遲建立新地址樣式，「[Wuille] 提出了擔憂，如果不盡快做某事，我們將永遠被[當前地址的] 80 位元安全性所困；我提醒他 […] 我們即將進行 checksig 改進，以將交易大小減少 30%，這也是建立新地址類型的好時機。」他所暗示的 OP_CHECKSIG 改進是允許使用 Schnorr 數位簽章演算法，這在 Bitcoin Core 的簽名和驗證函式庫 libsecp256k1 中已經支援。

行動項目： 無。[編輯註：正如 Corallo 和 Maxwell 所建議的，我認為如果閱讀此內容的錢包作者開始討論他們希望在新地址樣式中看到什麼以及他們認為應該如何（以及何時）部署它會很好。]

使用預生成簽署的 UTXO 進行初始區塊下載 (IBD)

背景：每個 Bitcoin Core 完整節點下載並處理最佳區塊鏈上的每個區塊，以建立當前未花費交易輸出 (UTXO) 的資料庫。這是可花費比特幣的清單以及它們可能被花費的條件（例如花費簽名必須符合什麼公鑰）。處理所有這些區塊是讓 Bitcoin Core 在第一次啟動時需要兩個小時或更長時間才能完全準備好的原因。Jonas Schnelli 提議為使用者提供某個相當近期區塊高度的預生成 UTXO 集副本，該集由備受推崇的社群成員簽署，以允許使用者跳過下載和處理除最近區塊之外的所有區塊。

Jonas Schnelli 開始說：「你們對我[使用預生成簽署的 UTXO 集執行初始區塊下載 (IBD)] 的方法有什麼看法？」

回饋完全是負面的：

• Luke Dashjr：「坦率地說，聽起來充其量是浪費時間。[我]更希望看到 [Bitcoin Core 以] SPV 模式啟動，直到 IBD 完成。」

• Morcos：「我認為這是個壞主意。核心開發者（或任何人）不應該在任何時候授權帳本的狀態。」

• Wladimir van der Laan：「這是有風險的，它給系統帶來了信任。你會信任誰來簽署這樣的東西？」

• Wuille：「這不是減少區塊服務；而是改變信任模型。」

行動項目： Schnelli 優雅地接受了回饋，提供了一個積極的表情符號，並說：「好吧…那麼讓我不要實作它。」

Bitcoin Core 0.11 的反向移植

背景：Bitcoin Core 的軟體生命週期文件說：「我們維護主要版本直到它們的『維護結束』。我們通常維護當前和以前的主要版本。所以如果當前版本是 0.12，那麼 0.11 也被認為是維護中的。一旦 0.13 發布，那麼 0.11 將被認為已達到『維護結束』。」

Morcos 開始說：「我們還需要將所有這些軟分叉 [BIP 9、68、112、113] 反向移植到 0.11；對嗎？」

Maxwell、van der Laan 和 Wuille 同意，van der Laan 說：「我認為反向移植到 0.11 是相當必要的；那只是往回一個版本」。

Dashjr 希望看到反向移植到 0.10，如果它們不太困難的話：「0.11 是必要的；0.10 是理想的；但我想我稍後會處理 0.10。」

Morcos 回答：「0.10？我希望你們願意跳過 0.11。我擔心這些主要的[反向移植的軟分叉]測試得有多好。」BtcDrak 似乎同意：「我會跳過 0.11」。

行動項目： Morcos 和 BtcDrak 討論了分工，每個人似乎都同意將所有 BIP 反向移植到 Bitcoin Core 0.11 系列。Wuille 總結：「我認為我們可以很快完成 [BIP] 9/68/112/113」。Morcos、van der Laan 和 BtcDrak 都同意，BtcDrak 說「68/112/113 從我這邊完成了；Morcos 想要新增更多 RPC 測試，這很好。」

VersionBits 預設區塊版本

背景：VersionBits BIP9 允許使用區塊標頭版本欄位作為位元陣列，以便礦工可以同時表示對多達 29 個軟分叉的準備就緒。根據目前的程式碼和提案，未表示對任何軟分叉準備就緒的礦工將建立「版本 4 區塊」，即與用於觸發和執行 BIP65 CLTV 軟分叉相同版本的區塊。

Daftuar 開始說：「現在 [pull request] #7575 將在第一個軟分叉啟動後恢復到版本 4 區塊，如果佇列中沒有其他軟分叉；我假設這是無意的？」

Wuille 回答說這實際上是有意的，「這[行為]對我來說似乎是正確的；舊版本 [4] 用於表示『沒有 versionbits』。」

Morcos 不確定這是正確的做法，「所有先前的軟分叉都要求礦工升級。我想做的是，在這第一個軟分叉中，要求[區塊標頭]版本大於 4。然後我們可以對不是[頂部位元為] 001 的位元欄位發出警告，除非它小於或等於 4，我們知道這些是無效的。」

頂部位元為 001000 的位元欄位被提議為一個好選項，Maxwell 說：「我喜歡 001000，因為它會鼓勵視覺化工具解析位元欄位而不僅僅是顯示整數。」這是因為將前三個位元設定為 001 在原始系統中相當於版本號 536,870,912，這在任何以這種方式顯示它的區塊鏈瀏覽器中看起來都非常奇怪。

行動項目： 沒有明確提及，但似乎預設版本位元欄位可能會將其頂部位元設定為 001000。

是否應該要求新的 VersionBits 預設版本

在前面的討論似乎以將預設版本位元欄位頂部位元設定為 001000 結束後，Pieter Wuille 想知道使預設版本大於或等於 5 是否應該是「共識[規則]？我更喜歡不引入新的共識邏輯，特別是當支援它的唯一論據是更好的警告保證時。」

Morcos 回答：「我想它不必是共識規則，但我認為如果它是共識規則，對我來說更清楚它沒有問題，因為這就是[以前的版本增加軟分叉]的工作方式。如果它不是共識規則，你不能確定舊節點會被警告規則已經改變[但]也許這不值得擔心。」（原文強調。）

Wuille 問：「我們擔心[礦工]可以繞過警告機制嗎？」軟分叉與硬分叉不同，因為大多數算力可以隨時開始執行軟分叉，而不會造成持久的鏈分裂。versionbits 和舊的軟分叉管理方法都允許礦工使用他們的算力向其他礦工表示他們準備好執行軟分叉，以便他們可以同時執行它，但沒有任何東西直接阻止礦工私下同意軟分叉。這意味著軟分叉警告機制取決於礦工的合作，試圖設計它以防止某種形式的繞過可能是浪費精力。

Morcos 似乎同意不將其作為共識規則，儘管它「對我來說似乎很奇怪：我覺得我們正在從舊系統過渡到新系統，過渡應該符合舊系統——但只要我們將預設值設為 00100，那麼我認為這只是理論上的擔憂。」

行動項目： 無。

結論

會議在預定結束時間結束，繼續討論如何為 versionbits 管理的軟分叉變更警告和警報。

娛樂時刻

wumpus: it's risky, it brings trust into the system
wumpus: who would you trust to sign something like that?
sipa:   Bob.
wumpus: yes, definitely Bob
Luke-Jr: XD
CodeShark: :p

參與者

免責聲明

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

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