IRC meeting summary for 2018-04-19

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

本週會議討論的主題包括：GitHub 頁面載入的週期性問題、專案成員希望審查者在下週重點關注的拉取請求、某些原始碼檔案之間的不良相依性分離、輕量客戶端模式的設計，以及後 BIP150 身份驗證協定的更新（具有改進的隱私性）。

高優先級審查

背景： 每次會議，Bitcoin Core 開發者都會討論哪些拉取請求（PR）是會議參與者認為在接下來一週最需要審查的。其中一些 PR 是貢獻者特別希望在下一個版本中看到的程式碼相關；其他則是阻礙後續工作的 PR，或需要大量維護（重新基底）才能保持在待處理狀態的 PR。鼓勵任何有能力的審查者前往專案的目前高優先級 PR 列表。

討論： 在討論特定議題之前，幾位團隊成員提到他們在載入 GitHub 上的某些頁面時遇到慢性問題，特別是如上週會議記錄中所報告的，有大量討論的拉取請求。其中一些拉取請求被列為高優先級審查。GitHub 支援團隊先前已被幾位會議參與者告知此問題，並在會議期間發送了更多通知。

作為潛在的解決方法，有人建議可能應該關閉並重新開啟有大量討論的拉取請求作為新的拉取請求，以便審查可以繼續。也討論了其他解決方法，例如使用具有無痕/私密模式或行動檢視的網頁瀏覽器。

本次會議具體討論的唯一 PR 是：

1. 除非被監視，否則不要將裸多重簽章輸出視為 IsMine（#13002），由 Pieter Wuille 提名。此 PR 刪除了 Bitcoin Core 錢包中對罕見（且相當奇怪）的多重簽章使用的預設支援，簡化了錢包，為未來可能的升級做準備。此功能的使用者仍然可以手動使用這種類型的多重簽章，並將在發行說明中提供遷移說明。

循環相依性

背景： Bitcoin Core 是用 C++ 程式語言編寫的，它允許將如何使用函式的資訊與實際使函式運作的邏輯分開。將定義分離到標頭檔（.h）和邏輯分離到 C++ 檔案（.cpp）可以使將專案劃分為一組較小的獨立模組變得更容易，這些模組可以更容易地審查和推理。

討論： Pieter Wuille 提出了這個主題，「我想知道我們是否應該針對 .cpp 檔案相互引入彼此的 .h 檔案（但不是 .h 檔案相互引入）這種類型的循環相依性制定政策。對於編譯器來說，這不是循環相依性，但它確實意味著這兩個模組不能真正獨立使用，並且通常是分離不良的跡象。[…] 有幾個開放的 PR 引入了它們，所以我想在這裡提出來，看看這是否應該成為 PR 合併的阻礙，還是只是『如果引入了就試著在之後修復它』。我對兩者都可以接受。」

Cory Fields 回答說「確實聽起來像是可能的不良設計，至少應該在 PR 中證明其合理性。」幾位會議參與者表示同意。

結論： 普遍同意在 PR 中發現問題時發表評論，但不要求在合併之前總是解決問題，特別是在理想的 PR 的情況下，解決問題可能會使已經很大的程式碼變更集變得更大且更難審查。

輕量客戶端模式設計

背景： Bitcoin Core 作為全節點運作，這意味著它遵循具有最多工作量證明的有效區塊鏈。有人提議 Bitcoin Core 也提供一種降低能力的模式，在該模式下，它遵循具有最多工作量證明的區塊鏈，而無需檢查鏈上的每個區塊是否有效。全節點模式需要下載每個區塊，但輕量模式只需要下載每個區塊的標頭以及與支付給使用者的交易相關的一些資料，這將大大減少頻寬需求。

討論： Jonas Schnelli 提出了這個主題，並參考了他的 PR #10794，該 PR 提議引入輕量客戶端模式，而不將其整合到錢包中。提議的程式碼允許使用者停用區塊的自動下載，並使用 requestblock RPC 手動請求他們想要的特定區塊。這可以在稍後透過未來的 PR 擴充，以允許錢包請求下載運作所需的特定資訊。

Schnelli 問道：「我想獲得一些關於輕量客戶端模式的回饋，[特別是]『requestblock』設計，[那]是我們應該遵循還是放棄的東西。」經過一番討論後，他澄清說：「我只想知道這個概念是否有意義 […] 擁有一個輕量客戶端模式。」

Pieter Wuille 說：「擁有客戶端模式的想法——對我來說[絕對]有意義——但這在很大程度上取決於如何以及是什麼。」Samuel Dobson 也贊同這個概念。

Luke Dashjr 只支援輕量客戶端模式的概念，作為「在背景建置到全節點」過程中的一個步驟。基本想法是 Bitcoin Core 可以作為輕量客戶端啟動，讓使用者幾乎立即開始接收和花費比特幣，然後悄悄下載和驗證成為全節點所需的歷史區塊。

Wuille 不同意：「擁有一個你自己執行的全節點，然後擁有多個專門連線到它的客戶端節點，這是一個完全有效的使用案例。但輕量[客戶端]在背景升級到全[節點]也是一個非常好的使用案例。」

持續的討論集中在啟用輕量客戶端模式和在 Bitcoin Core 中分離節點和錢包程序之間的差異和相似性，這是另一個正在進行的工作。

Wuille 解釋說：「我不認為目標應該是將錢包與節點分離到不同的程序中，然後在兩者之間發明一個協定，而不是讓錢包作為輕量客戶端執行。使用[點對點網路協定]作為節點和錢包之間的通訊的優勢（這是當你將錢包視為輕量節點時所得到的）是它實際上[是]模組化的：你可以執行任何錢包軟體或任何節點軟體。」（原文強調。）

Wuille 還解釋說，將輕量客戶端模式完全實作到 Bitcoin Core 中可能不像某些人預期的那樣是一項大工作，因為它可以「重複使用所有現有的全節點程式碼和 P2P [網路協定]實作，[並]只是[不]進行驗證。」

關於這個主題的最後評論指出，需要在 P2P 網路協定中實作 BIP150/BIP151/BIP158，以便輕量客戶端節點擁有開發者希望的所有功能。Schnelli 計劃繼續他對 BIP151 的工作，並且（會議中未提及）其他開發者正在為 Bitcoin Core 中的 BIP158 支援奠定基礎。

與其他討論交織在一起，Cory Fields 提到阻礙他能夠審查的一個因素是 Bitcoin Core 目前的下載邏輯。「在我看來，[這個邏輯]應該在堆積更多之前進行一些清理/封裝。」Suhas Daftuar 表示同意，Wuille 也是（他幫助編寫了一些目前的程式碼）。

結論： 幾位參與者同意審查並評論 #10794。可能需要更多討論來說服所有人輕量客戶端模式是一個好主意，但幾位參與者確實對基本想法表示熱情。

私密身份驗證協定的更新

背景： BIP150 提出了一個協定，允許兩個節點相互驗證它們的連線。如 BIP 所述，這有助於檢測中間人攻擊，並允許經過身份驗證的對等點存取受限操作。

討論： Pieter Wuille 提出了這個主題，「如一些人所知，[Gregory Maxwell] 和我一直在思考比 BIP150 具有更好隱私性的身份驗證協定。目標是設計一個協定，其中一個節點有一個或多個私鑰，另一個節點有一個或多個公鑰。第二個節點了解[第一個]節點的私鑰之一是否與[其]公鑰之一匹配，但沒有其他資訊。擁有私鑰的節點甚至不知道身份驗證是否成功，或者不知道它被查詢的是哪些金鑰。」

在簡短回答了一些問題後，他繼續說：「想法是我們的大多數連線無論如何都是未經身份驗證的（並且應該[是，因為它們是與點對點網路上的隨機對等點]）所以，無論你給經過身份驗證的節點什麼特權，如果身份驗證失敗，你就不會給予。這有一個非常酷的特性，即使你不關心對方是誰，你也可以總是執行此身份驗證協定。[…] 如果你總是執行身份驗證協定（但如果你對身份驗證不感興趣，則使用隨機產生的公鑰[保證不匹配]）[中間人攻擊者]無法找出你在做什麼——他們必須假設你正在嘗試身份驗證。」

先前嘗試的描述設計這樣一個協定是可用的。Wuille 指出，該文件中描述的協定已損壞，但該文件包含的設計理由仍然有用。

「無論如何，事實證明這很困難，」Wuille 說。「我們有一個協定可以使用一個[私鑰]和一個[公鑰]——這意味著你有時需要執行[它]很多次，這不會帶來很好的指紋屬性。我正在與一些人交談以擴充它。」

Cory Fields 對協定的目的表示了一些困惑。Wuille 澄清說：「[新協定]的全部意義在於避免為應該是無身份的東西擁有可發現的身份，但有時你有一個已經信任的節點（由於外部原因，例如你自己執行它），在這種情況下，你會為[它]配置一個帶有已知公鑰的 addnode。」Bitcoin Core 的 addnode RPC 目前允許你根據其 IP 位址連線到特定節點。

Mark Erhardt 提供了額外的解釋：「例如，如果你想用輕量客戶端連線到你自己的節點，你查詢的唯一有效金鑰是你家用節點的。如果你想防禦女巫攻擊，你可以查詢已知朋友的列表並接受其中任何一個。如果你只想嚇跑[中間人]，你會查詢隨機金鑰。」

Jonas Schnelli 問道：「我猜這個協定需要比[現有的] BIP150 更多的密碼分析？」Wuille 回答說：「我正在與 Dan Boneh 討論它。」Boneh 是一位著名的密碼學家和史丹佛大學的電腦科學教授，他先前曾幫助研究和開發與比特幣相關的密碼協定。

Wladimir van der Laan 指出：「作為 BIP150 的未來繼任者，這會很好——儘管我認為這項研究不應該阻止任何人在[更]短期[基礎上]實作 BIP150 並擁有可運作的東西。」Wuille 表示同意。

結論： 據推測，Wuille 和 Maxwell 將繼續進行該協定的工作，可能會得到 Boneh 和其他人的幫助。鼓勵在此期間繼續實作 BIP150 的工作。

幽默時刻

<jonasschnelli>  I guess this protocol would require more cryptoanalysis
                 then the exiting BIP150
         <sipa>  jonasschnelli: that's ok, i'm talking to dan boneh about it
<jonasschnelli>  Good!
 <meshcollider>  Dan is the solution to all crypto problems

參與者

免責聲明

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