IRC meeting summary for 2018-05-10

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

本週會議討論的主題包括：會議參與者最希望看到審查的拉取請求、如果頁面繼續無法可靠載入是否可能離開 GitHub、如何修復效能退化、在記憶體中儲存交易腳本資料的未來設計，以及是否建立額外的審查佇列。

高優先級審查

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

討論（記錄）： 具體討論的 PR 包括：

• [wallet] loadwallet RPC - 在執行時載入錢包（#10740）。 這是一組 PR 之一，如果被接受，將允許 Bitcoin Core 在 Bitcoin Core 0.15.0 中新增的多錢包模式的背景下，在執行時建立、載入和卸載錢包。在會議中，Joao Barbosa 建議此 PR「已經可以了」，Wladimir van der Laan 說它「應該非常接近可合併。」

• BIP 158：輕量客戶端的緊湊區塊過濾器（#12254）。 此 PR 允許 Bitcoin Core 為區塊中包含的一些資訊產生緊湊索引。然後可以與輕量客戶端共享這些索引，以允許它們確定區塊是否包含與客戶端錢包相關的資訊，此時客戶端可以請求下載整個區塊（可能來自不同的對等點）。

在討論具體 PR 時，第 n 次提到了 GitHub 頁面無法載入（顯示獨角獸主題錯誤）的問題。Matt Corallo 說：「如果這個獨角獸問題持續存在，我們將不得不離開 GitHub。大多數情況下，如果你重新整理足夠多次或登出，它就會工作，但當重新整理次數約為 10 次時，這兩個都不是解決方案，[並且]我們不能使用一個一半的貢獻者無法載入 PR 的平台。」

Wladimir van der Laan 回答說：「同意。GitHub 這樣基本上是無用的。」其他參與者分享了他們有時解決問題的技巧。

結論： 鼓勵審查者訪問專案的目前高優先級 PR 列表。沒有討論離開 GitHub 的具體計劃；會議參與者似乎希望 GitHub 會修復他們的系統。

在 CTransaction 中快取見證雜湊

背景： 當 Bitcoin Core 需要將交易儲存在記憶體中時，它使用 CTransaction 資料類型。這包含足夠的資訊來為交易建構見證交易識別碼（wtxid 或見證雜湊）。CTransaction 資料類型可以擴充為包含見證雜湊的預先計算（快取）副本。

討論（記錄）： Marco Falke 提出了這個主題，引用了 PR #13011，並介紹了主題：「見證雜湊用於所有鬆散交易，因此快取它會加速驗證（例如 [AcceptToMemoryPool] 和緊湊區塊轉發）。此外，對於沒有見證的交易，見證雜湊等於『正常雜湊』[txid]，因此重新掃描/重新索引存在開銷，[但它]目前是最小的（因為沒有很多具有見證的交易）。快取見證雜湊的收益遠遠超過重新掃描/重新索引期間的任何開銷，[我認為]。當然，我們可以在未來的 PR 中重新設計重新掃描。」

Pieter Wuille 提供了相反的觀點：「[缺點]是它使交易[在記憶體中]變大，並將一些驗證特定邏輯硬編碼到交易資料結構中（例如，它也會影響從磁碟提供區塊等）。」

Matt Corallo 贊成該提議，「[優點]是我們糾正了顯著的效能退化。」

Wuille 建議分離用於交易的資料類型，以便在不需要時不需要產生和儲存見證雜湊。Wladimir van der Laan 似乎同意，說「讓我們不要為了急於前進而把程式碼搞得一團糟。」

還討論了提議的變更是否應該向後移植到 Bitcoin Core 的下一個小版本。Corallo 贊成向後移植，但 Van der Laan、Cory Fields 和 Alex Morcos 反對（儘管可能不是強烈反對）。

結論： 沒有明確的結論。PR #13011 在討論期間被新增到目前高優先級 PR 列表中。

一個大的 malloc

背景： 在 Bitcoin Core 編寫的 C++ 程式語言中，記憶體配置（Memory ALLOCation）的主要函式稱為 malloc()。目前，如 PR #13062 中所述，交易中腳本的記憶體配置方式是最佳化快取 scriptPubKeys，但在其他情況下效能次佳。該 PR 致力於將記憶體中腳本的儲存與它們在程式中的存取方式分開，以便儲存和存取（表示）都可以最佳化。

討論（記錄）： Cory Fields 提出了這個主題並介紹說：「[Pieter Wuille] 和我簡短討論過這個：[…] 每個區塊的腳本資料一個 malloc。[那]讓我想知道是否值得變更 P2P [網路協定訊息]格式以更適合配置（下次我們變更某些東西時，不是單獨為此）。」

Jonas Schnelli 提供了一個範例，Fields 確認了：「像 inv 大小在實際 inv 資料之前。」

隨後的討論不是集中在 Fields 的原始觀點上，而是集中在 PR #13062 用於在記憶體中儲存腳本的方法（稱為 span）的優點和缺點上。反對 span 的是 Matt Corallo，至少「除非有證明的用途」。

贊成 span 的是 Fields 和 Wuille。Fields 說：「[它]對我來說似乎絕對必要，如果我們要解開我們的子系統。」Wuille 同意，說：「完全正確：它將表示與處理抽象化。」

Corallo 反駁說：「為什麼？如果它只是在 CScript 上操作，它應該只在 CScript 上操作。」經過更多討論後，Corallo 說他理解潛在的優勢，但仍然希望在進行變更之前看到它在可合併的 PR 中使用，「是的，我明白了，我喜歡這個選項…當我們有使用者時。」

結論： 沒有明確的結論。Wuille 和 Fields 可能需要投入更多努力來證明他們方法的優勢，然後才能接受與其相關的 PR。

審查協調

背景： Bitcoin Core 專案目前有超過 250 個開放的 PR，幾乎所有 PR 都需要審查（或額外審查）才能考慮合併。多年來，貢獻者一直在說，他們希望專案有更多人花更多時間審查 PR。

討論： Jim Posen 提出並介紹了這個主題，「[除了高優先級 PR 列表外]，我認為還有空間建立另一個已被概念 ACK 的事物列表，供人們審查，以便每個人審查不同的東西，並且有一些實際的協調。」

Pieter Wuille 建議相對較新的網站 BitcoinACKS.com，Posen 同意「很棒」。Wuille 支援 Posen 的想法，「對什麼是概念 ACK（以及類似地，鼓勵人們快速概念 ACK/NACK）有更好的概述會很好。」

Wladimir van der Laan 反對這個想法，說「現在每個人都可以在[目前高優先級列表]上有一個阻礙他們的 PR，這應該促進合作。」Matt Corallo 同意，「百萬小 PR 審查方法不會讓我們作為專案取得任何進展，[但]審查高優先級列表上的事物確實會（至少對我來說）。」

結論： 沒有明確的結論。Corallo 個人總結說：「我認為我們這週不會比過去 10 次討論這個問題時取得更多進展。」

幽默時刻

<morcos> i'm back
<wumpus> welcome back!
  <sipa> hi back, i'm pieter
<morcos> oh man...

 <cfields> well another option is std::allocator magic,
           without having to switch to Span
  <wumpus> noooo
  <wumpus> no magic
 <cfields> wumpus: i can't argue with that, it looks like voodoo
    <sipa> damn cool voodoo.
    <sipa> but voodoo.
  <wumpus> c++ is already too much voodoo
    <sipa> let's switch to BASIC

    <sipa> bitcoinacks.com ? :)
<BlueMatt> apparently it doesnt distinguish between nacks and acks
    <sipa> ha.
  <wumpus> lol that's an interesting bug
    <sipa> "nack" "nack" "nack" "merged!"

參與者

免責聲明

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