IRC meeting summary for 2017-03-02

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

主要議題

• 0.14.0 版本發布
• 優先審查和合併請求
• 0.15 版本的主要功能
• Segwit 啟動後的 GetBlockTemplate 行為
• CreateNewBlock 呼叫 TestBlockValidity 與否，以及 CreateNewBlock 快取
• （空白）

0.14.0 版本發布

背景

Bitcoin Core 0.14.0 的第二和第三個候選版本（RC2 和 RC3）在上週會議後發布。

0.14.0 的許多主要升級都是效能改進。

意見

簡短討論了已發布一週的 RC2 和最近發布的 RC3 的狀態。沒有開發者知道任何問題，有一人回報看到 RC 測試者的一些正面評論。

結論

兩位會議參與者建議如果 RC3 沒有發現問題，將在 3 月 7 日星期二發布 Bitcoin Core 0.14.0 的最終版本。

優先審查和合併請求

背景

當多個不同的程式碼庫變更建議各自以不同方式編輯相同的程式碼行時，就會產生無法由自動化版本控制軟體解決的衝突。相反地，開發者需要手動審查每個衝突的變更，並找出要保留哪個變更，或是否需要將變更組合在一起。

解決這些衝突耗時且大多數開發者認為相當煩人，特別是因為如果第一個開發者的建議變更在任何後續開發者開始工作之前合併到程式碼庫中，通常可以避免這種情況。

此外，由於程式碼在解決衝突時經常變更，變更後的程式碼通常需要由 Bitcoin Core 有限的經驗豐富的程式碼審查者重新審查。

基於這些原因，開發團隊試圖優先審查和合併可能導致許多衝突變更的 Pull Request（PR）。

意見

Alex Morcos 開啟話題：「我想簡短討論合併 #9602 的時機。因為，假設我們要這樣做，最好盡快處理，這樣就不會變成 rebase/審查的惡夢。我還有大量建立在其之上的手續費估算變更。」

Matt Corallo 回覆：「很快會完成審查，但到目前為止看起來不錯。我同意它應該快速合併。」

Suhas Daftuar 補充：「我也在進行一些挖礦調整，我寧願直接建立在 9602 之上。」

Corallo 提出另一個優先審查請求：「我想 Luke 的 dont-use-pwalletMin 的東西重新 rebase 也是個麻煩。那是 #8775。」

結論

Wladimir van der Laan 表示：「盡快審查和合併 #8775 和 #9602，它們容易變成 rebase/合併的惡夢。」

0.15.0 的主要功能

註：這是在前面的 rebase 議題期間討論的。

背景

Gregory Maxwell 開始討論：「可能不是在這次會議中，但人們思考他們希望 0.15 的主要功能是什麼，並確保我們足夠早地在這些事情上取得進展，以便它們實際上能夠在那裡，這可能是有用的。:) 我覺得至少我個人想要在 0.14 中有些東西，但直到太晚才給予足夠的關注。」

Wladimir van der Laan 進行調查，看是否有人有「大型即將到來的軟分叉專案會壟斷所有人」，但 Maxwell 回答：「所有類似的東西都因 segwit 而暫停！」因此 Wladimir 建議「這意味著對於 0.15，我們可以專注於軟體功能而不是網路/共識功能。」

討論

Alex Morcos 問：「我們沒有任何不基於 segwit 的軟分叉建議在佇列中嗎？讓我們利用 BIP 9！」Pieter Wuille 回答：「提高最低難度，可選的 UTXO 承諾，…」

• 提高最低難度有望成為從共識相容的完整節點（如 Bitcoin Core）中移除區塊鏈檢查點的最後一步。檢查點在 Bitcoin 0.3.2 中加入以「鎖定到此點的區塊鏈」，這降低了某些攻擊的有效性，但也提供了一種可以覆蓋 Bitcoin 基本規則之一的機制：網路帳本是具有最多工作量證明（PoW）的有效區塊鏈。

  提高最低難度會使攻擊更昂貴（因為它們必須包含比現在相同攻擊多得多的 PoW），而不會妨礙 Bitcoin 正常使用 PoW 在有效鏈之間進行選擇。

  更多背景資訊，請參見 2016 年 10 月 27 日會議期間的討論，以及 IBD using chainwork（在 Bitcoin Core 0.13.2 中發布）和 assumed valid blocks（在 Bitcoin Core 0.14.0 中發布）。

• 可選的未花費交易輸出（UTXO）承諾可以幫助提高輕量級錢包的安全性。這是多位貢獻者主要獨立工作但共享想法，已經兼職研究數年的主題。本摘要的作者不知道任何具體的提案，甚至在技術社群中獲得初步的廣泛接受。

Morcos 也建議：「我腦海中的一個主要功能，但有點複雜，所以可能需要一些討論是否要它（以及何時），那就是自動化手續費提升。」Maxwell 建議不同的名稱：「我會用『預先計算手續費提升』取代『自動化手續費提升』」。

• 預先計算手續費提升由 Maxwell 在會議中簡要描述：「當你簽名時，預先簽署所有提升，使用 locktime…這樣它們不會干擾錢包加密…甚至可以在你離線時交給其他人。」

  例如，Alice 會告訴 Bitcoin Core 她想在接下來的 10 個區塊內支付給 Bob，並指示她願意支付的最高手續費是多少。

  Bitcoin Core 會使用其現有的手續費估算功能，以及 Bitcoin Core 0.14.0 中引入的可選手續費提升功能，創建一個初始版本的交易給 Bob，支付預期在 10 個區塊內確認的交易的最低手續費。同時，Bitcoin Core 也會創建可能另外 9 個版本的交易，第一個使用 nLockTime 確保它直到從現在起兩個區塊才能被加入；第二個時間鎖定直到從現在起三個區塊；等等…

  這些後續交易中的每一個都會支付比原始交易稍高的手續費（最高到 Alice 指示的最高手續費），以增加礦工挖掘該交易的激勵。

  因為交易的所有版本都會在 Alice 發送初始交易時簽署，她只需要解鎖她的錢包一次。此外，因為交易的所有後續版本都會使用 nLockTime，Alice 可以無需信任地將這些交易的副本分發給其他人，以便在她離線的情況下稍後廣播。

  簡而言之，如果必須的話，軟體會自動提供 Alice 的最高手續費，但如果可以的話會支付較低的手續費——確保 Alice 在不需要額外努力的情況下獲得盡可能接近最佳價格的費用。

結論

沒有明確的結論。據推測，開發者將專注於在即將到來的一週發布 0.14.0，然後將花更多時間討論 0.15 的目標。

Segwit 啟動後的 GetBlockTemplate 行為

註：這也是在前面的 rebase 議題期間討論的。

背景

Segwit 被設計為在 segwit 啟動後給予礦工一個選擇：

1. 礦工可以像現在一樣生產舊式區塊，但這些區塊不能包含任何 segwit 交易（因此礦工可能會收到較少的交易手續費）。

2. 礦工可以生產 segwit 式區塊並挖掘 segwit 交易，獲取任何額外的可用手續費。要做到這一點，單獨礦工和礦池營運商需要將他們的軟體更新到支援 segwit 的版本。

單獨礦工和礦池的軟體從 Bitcoin Core 的 GetBlockTemplate（GBT）遠端程序呼叫（RPC）獲取未確認交易列表和其他挖礦資訊。

Bitcoin Core 預設目前只允許礦工使用 BIP9 versionbits 發出支援 segwit 的信號，如果他們已經使用 GBT 對 segwit 相容的挖礦軟體進行了升級（或偽造）。然而，Bitcoin Core 預設也會在 segwit 啟動時停止為任何尚未升級到 segwit 相容軟體的礦工提供 GBT 結果；下面引用的會議評論解釋了為什麼做出這個選擇。

意見

Gregory Maxwell 開始討論：「我認為我們應該重新考慮 segwit 工作方式的一些事情：在 segwit 啟動後我們不會在沒有設定旗標的情況下進行挖礦，並且我們在沒有旗標的情況下不設定 versionbit。」

Suhas Daftuar 解釋：「我們這樣做是為了 segwit 不能在礦工實際上沒有挖掘 segwit 交易的情況下啟動。我的擔憂（在我們到達現在這個點之前）是 segwit 可能在 0 個礦工挖掘的情況下啟動，然後記憶池可能會被不會確認的交易攻擊。」

Maxwell 的回答是：「是的，但我認為那是個錯誤。所以如果他們不這樣做會怎樣？那麼最初 segwit 交易的容量就會較少，直到他們升級，他們會在手續費上損失。」

Alex Morcos 同意並補充：「只要我們知道有些礦工在挖掘它們，這似乎我們現在處於這個點。」Daftuar 也同意現在放寬安全條件，Matt Corallo 似乎也同意。

結論

沒有明確的結論，但會議參與者之間似乎普遍同意將 Bitcoin Core 更改為在 segwit 啟動時繼續挖掘有效的舊式區塊，對於那些不使用 segwit 旗標呼叫 GBT 的礦工。

CreateNewBlock 呼叫 TestBlockValidity 與否，以及 CreateNewBlock 快取

背景

Bitcoin Core 中為礦工組裝新區塊的主要函數稱為 CreateNewBlock（CNB）。作為向礦工提供創建區塊之前的最後一步，會呼叫一個 TestBlockValidity（TBV）函數，確保創建的區塊如果礦工找到所需的工作量證明，將是有效的——被其他節點接受。

Bitcoin 礦工 James Hilliard（Lightsword）已經開啟了一個 Pull Request（PR），從 CNB 中移除 TBV（#9858）和一個使其可選的替代 PR（#9859），解釋：「在這裡獲得無效模板永遠不應該發生，除非 bitcoind 內部有錯誤，所以這個 TestBlockValidity 呼叫只是一個內部健全性檢查」。

更多關於 TBV 的背景，請參見上面連結的議題中的討論。

意見

Pieter Wuille 建議這個議題，Gregory Maxwell 開始討論：「我們需要讓 TBV 脫離關鍵路徑。我不是很同意 Lightsword 對它的看法——我認為我們有一些程序測試我們正在交給礦工的區塊是很重要的。它不需要在關鍵路徑中。」

Alex Morcos 進一步解釋：「將它留在關鍵路徑中的缺點是額外 150 毫秒的空區塊挖礦。」

Pieter Wuille 列舉了選項：「一個簡單的（只是擺脫測試）；或一個困難的（後台驗證、快取、…）」

關於後台和快取的技術討論隨之而來，參與者贊成兩者，但還沒有明確的設計，因此可能需要更多討論。

Morcos 建議：「老實說，我認為更重要的方向應該是開始用更好的框架替換 GBT [GetBlockTemplate]。」Wuille 和 Maxwell 回答說，改變 TBV 的使用方式和 GBT 替換似乎是兩個獨立（正交）的議題；Morcos 同意但補充：「也許我的意思是我們應該設計更好的東西，這樣它就會告訴我們我們想要從 CNB/TBV 中得到什麼。並記錄設計，這樣我們就不會忘記…即使我們還沒有做到。」

沒有人反對實驗性設計，但似乎也沒有人對此熱衷。

討論轉向在接收到新區塊和驗證該區塊之間的短時間內進行無驗證挖礦的可能性。Morcos 描述了這如何工作：「從網路獲取新區塊 -> 假設有效 -> 標記記憶池中所有其交易為可能已使用 -> 從剩餘的 CNB -> 尚未驗證新頂端或 TBV 新模板，如果我們找到一個區塊，那就這樣吧。」

Maxwell 指出：「在那種情況下，你會延長一個無效區塊，這很糟糕（延長無效區塊非常糟糕，即使是相對短暫的間隔，因為它會大幅放大輕客戶端的風險——特別是因為挖礦設備可能會在舊工作上停留數十秒）。」

Matt Corallo 在想類似 Morcos 的東西：「我更傾向於不依賴驗證很快——在獲取區塊模板所需的 100 毫秒內挖掘空區塊，並在驗證期間轉發區塊。」

Maxwell 提到他寫的一個草案 BIP，以減少無驗證挖礦對輕客戶端安全的損害。Corallo 贊成：「我認為當我們回傳空區塊時，我們應該實作那個 :) 我很樂意在輕客戶端中實作它。」

此時討論回到技術細節，專注於挖礦軟體如何處理 Bitcoin Core 回傳的空區塊以及礦池軟體回傳的空區塊。

結論

沒有明確的結論。所有在場的開發者似乎都致力於改善情況，但沒有人直接贊成 #9858 或 #9859 中的解決方案。會議後約 10 分鐘，這些 PR 的作者在 IRC 上變得可用，並開始與開發者討論可以進行的潛在短期優化，同時進行更重要（但長期）的工作。

議題：（空白）

在前面關於在急需結果時生成空區塊模板的對話期間，Pieter Wuille 提醒大家會議只剩 5 分鐘用於其他議題，導致 Gregory Maxwell 匆忙建議「空訊息」的議題。關於這個議題的整個討論在下面的幽默時刻部分轉述。

幽默時刻

<sipa> we're running out of time
       any other topics?

<gmaxwell> quick, empty messages

<sipa>

<luke-jr>

<wumpus>

<gmaxwell>

<luke-jr> inb4 trolls use this as proof we obey gmaxwell

<gwillen>

<BlueMatt> lulwut

<wumpus> #topic

<sipa> it's "lolwut", BlueMatt.

<BlueMatt> lulzwutz

<wumpus> cleared the topic, too, now we can cleanly exit the meeting

<gmaxwell> We should appoint a subcommittee to investigate the spelling of lolwut/lulwut.

<wumpus> #endmeeting

參與者

免責聲明

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