IRC meeting summary for 2016-08-04
概覽
筆記 / 簡短議題
- 幾位開發者和礦工在舊金山見面，他們前往史丹佛大學會見應用密碼學和電腦安全研究員 Dan Boneh。雖然與短期開發無關，但由 kanzure 製作的文字記錄具有非常高的訊噪比。
- NicolasDorier 建立了一個 IRC ##libconsensus bikeshedding 聊天室，討論如何處理 libconsensus。設計將呈現給更大的群體以獲得回饋。
主要議題
- 0.13.0
- segwit 記憶體池延展性 DoS
0.13.0
背景
Bitcoin Core 團隊正在朝 0.13.0 發布版本努力（完整時程表），RC2 自 2016-07-31 起可用。
會議討論
Sipa 注意到我們忘記反向移植 PR #8438/#8365（Treat high-sigop transactions as larger rather than rejecting them）。#8438 可以等到 0.13.1。
Luke-jr 指出發布說明在 blockmaxsize/blockmaxweight 方面仍然不恰當，wumpus 回覆他應該調整他的 PR 以僅變更發布說明。Gmaxwell 和 sipa 仍需要在發布說明中添加一些內容。
Luke-jr 想知道從 0.13.1 降級的失敗模式應該是什麼，以及是否需要為此進行變更。它應該給出硬錯誤或重新索引。如果它還沒有這樣做，可能值得再做一個 RC，包括修復此問題和 #8438。
會議結論
- 檢查是否真的需要降級保護
segwit 記憶體池延展性 DoS
背景
在審查 segwit 時，petertodd 注意到攻擊者可能能夠透過發送具有延展見證資料的交易來使節點對交易視而不見。在議題 #8279 中進一步討論。
會議討論
Sipa 更傾向移除「無效見證不會導致插入拒絕快取」規則，理由是它所做的只是防止攻擊者向你隱藏有效交易，但它並不能完全防止，因為他們可以宣布但永遠不發送交易。
Bluematt 想知道對於 segwit 節點使用 txid 而不是 wtxid 進行 inv’ing 的理由是什麼。Sipa 澄清這會複製很多邏輯（記憶體池、孤立、快取等），並且至少會造成潛在的加倍，因為你可能會從 pre-segwit 和 post-segwit 節點收到相同交易的 inv，一次使用 txid，一次使用 wtxid，而無法判斷它們是相同的。使用 txid 和 wtxid 進行 inv’ing 是一個解決方案，但如果我們採用這種方式，我們也應該將資源資訊添加到所有 inv（費用、大小、sigops 等），sipa 補充說。
Morcos 提議強制使用 feefilter，完全驗證交易，這樣我們就可以懲罰向我們發送無效內容的對等節點。不要將任何見證交易放入拒絕快取，然後評估拒絕快取繼續有用的程度，或者是否有違反策略的 segwit 交易在彈跳。Sipa 喜歡這個想法，但認為這對 0.13.1 來說是一個很大的變更。
對此沒有明確的解決方案。
會議結論
- 從「不要將任何見證交易放入拒絕快取」開始
與會者
| IRC nick | Name/Nym |
|---|---|
| sipa | Pieter Wuille |
| gmaxwell | Gregory Maxwell |
| wumpus | Wladimir van der Laan |
| btcdrak | BtcDrak |
| kanzure | Bryan Bishop |
| cfields | Cory Fields |
| sdaftuar | Suhas Daftuar |
| jonasschnelli | Jonas Schnelli |
| jeremyrubin | Jeremy Rubin |
| luke-jr | Luke Dashjr |
| jtimon | Jorge Timón |
| morcos | Alex Morcos |
| instagibbs | Gregory Sanders |
| NicolasDorier | Nicolas Dorier |
| BlueMatt | Matt Corallo |
| MarcoFalke | Marco Falke |
免責聲明
本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。