2015-11-05 IRC 會議摘要
概覽
日誌
主要議題
- Sigcache 效能
- 0.12 的效能目標
- 交易優先度
- sigops 洪水攻擊
- 鏈限制
簡短議題/備註
注意：cfields、mcelrath 和 BlueMatt（可能還有更多）因為日光節約時間而錯過了會議。
Scaling Bitcoin 工作坊的提案截止日期是 9 日。
檢查 0.11.2 RC 是否還有其他提交。一旦 6948 和 6825 合併，似乎就可以了。 我們需要相當快速地行動，因為已經有礦工在為 CLTV 投票（F2Pool）。此外，testnet 已經被 CLTV 鎖定，並且不斷分叉。 0.11.2 RC1 已於今天發布：https://bitcoin.org/bin/bitcoin-core-0.11.2/test/
大多數記憶體池限制分析假設了子付父，然而這還沒有為 0.12 準備好，所以我們應該在現有挖礦演算法的背景下考慮可能的濫用。
由於時間限制，選擇性手續費替代已推遲到下週會議，但大多數人似乎希望它在 0.12 中。sdaftuar 提醒我們需要向使用者明確說明，如果他們不想接受選擇性交易，他們需要做什麼。
Sigcache 效能
背景
簽名快取，用於提高效能（通過不必多次檢查簽名），並減輕一些攻擊，目前的預設限制為 50,000 個簽名。 Sipa 有一個拉取請求，提議： 將限制從條目數量改為 MB 將預設值更改為 40MB，對應 500,000 個簽名 儲存加鹽雜湊而不是完整條目 移除已在區塊中驗證的條目
會議評論
Sipa 對各種簽名快取大小在區塊中的命中率（有多少快取簽名在區塊中）進行了基準測試。 最大 sigcache 大小為 68MB，導致 3% 的未命中率。然而，有些區塊有極高的未命中率（60%），而其他區塊則沒有。可能是由於礦工運行不同的政策造成的。 Gmaxwell 提議始終對記憶體池交易運行腳本驗證，即使這些交易因客戶端政策而被拒絕進入記憶體池。 其結果是即使 300MB 的 sigcache 大小也只能降到 15% 的未命中率。所以有太多垃圾被傳播，無法保持任何合理大小的快取。 Gmaxwell 指出不檢查任何被拒絕的交易的缺點，即：可能有一些 DOS 攻擊，如果你設置的政策比典型網路更嚴格，你會增加未命中率，這可能導致競爭到底部。
會議結論
Sipa 繼續他的工作並尋找其他策略
0.12 的效能目標
背景
Bitcoin-core 0.12 計畫於 12 月 1 日發布。
會議評論
每個人都希望儘快包含 secp256k1，因為它有非常大的效能提升。 有些人希望包含 sigcache 拉取請求、BIP30、modifyNewCoins 和 createNewBlock 重寫（如果準備好的話）。 Wumpus 建議不要為 0.12 合併最後一刻的效能改進。
會議結論
應該審查提到的拉取請求，優先處理 CreateNewBlock
交易優先度
背景
每筆交易都被分配一個優先度，由年齡、大小和輸入數量決定。這使得一些交易免費。
會議評論
Sipa 認為我們應該完全擺脫當前的優先度，並用一個修改交易手續費或大小的函數來替換它。 有一個拉取請求可用，它優化了當前的交易優先度，從而避免了改變交易優先度定義所帶來的政治辯論。 Luke-jr 認為舊政策應該保持可能。
會議結論
檢查 PR #6357 是否足夠安全和高效。
sigops 洪水攻擊
背景
ECDSA 簽名檢查操作或 sigops 的數量目前限制為每個區塊 20,000 個。這是為了防止礦工建立需要很長時間才能驗證的區塊，因為這些操作很耗時。 然而，你可以建構具有非常高 sigops 計數的交易，由於大多數礦工不考慮 sigops 計數，他們最終得到非常小的區塊，因為達到了 sigop 限制。 這種攻擊在這裡有描述。
會議評論
建議考慮 sigops 數量相對於最大區塊大小與總大小的關係。意思是 10k sigops 交易目前將被視為 500kB 大小（僅對該單一交易，而不是對區塊）。 該建議在挖礦程式碼中很容易更改，但要將其插入到所有查看費率的地方，則更具侵入性。 如果這些交易沒有被記憶體池限制驅逐，這也會對記憶體池開放攻擊。 Luke-jr 有一個每 sigop 位元組限制，可以過濾掉這些攻擊交易。
會議結論
應該進行更多分析，人們似乎對修復它的總體方向感到滿意。
鏈限制
背景
在這個情境中，鏈是指連接的交易。當你發送一筆依賴於另一筆尚未確認的交易時，我們稱之為交易鏈。 理想情況下，礦工會考慮整個交易鏈，而不僅僅是每一筆單獨的交易（雖然據我所知這並未被廣泛實作）。因此，雖然單一交易可能沒有足夠的手續費，但一個依賴的交易可能有足夠高的手續費，使得挖取兩者都值得。 這通常被稱為子付父（child-pays-for-parent）。 由於你可以讓這些鏈變得非常大，因此可以通過這種方式堵塞記憶體池。 在最近的延展性攻擊中，任何進行多層深度交易的人都會遇到巨大的問題（在 let’s talk bitcoin #258 從 13:50 開始有很好的解釋） 提案和 github 連結。
會議評論
sdaftuar 的分析顯示 40% 的區塊包含超過提議限制的鏈。即使是小幅增加也無法解決問題。 這些鏈的可能來源：為其他交易支付手續費的服務（子付父）、一個樂意花費未確認找零的 iOS 錢包。一家企業確認他們在收到來自未花費鏈的比特幣時使用子付父。 這些長鏈可能直接傳送給礦工，在這種情況下，它們不會受到提議的傳播限制（以及延展性）的影響。 由於這是一個需要解決的問題，人們似乎對無論如何都要合併它感到滿意，提前溝通讓企業考慮這如何影響他們。
會議結論
合併「政策：降低交易鏈的預設限制」 Morcos 將在合併後寄信給開發者郵件列表。
參與者
morcos Alex Morcos
gmaxwell Gregory Maxwell
wumpus Wladimir J. van der Laan
sipa Pieter Wuille
jgarzik Jeff Garzik
Luke-Jr Luke Dashjr
phantomcircuit Patrick Strateman
sdaftuar Suhas Daftuar
btcdrak btcdrak
jouke ??Jouke Hofman??
jtimon Jorge Timón
jonasschnelli Jonas Schnelli
幽默時刻
20:01 wumpus #meetingend
20:01 wumpus #meetingstop
20:01 gmaxwell Thanks all.
20:01 btcdrak #exitmeeting
20:01 gmaxwell #nomeetingnonono
20:01 btcdrak #meedingexit
20:01 wumpus #endmeeting
20:01 lightningbot Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot .
20:01 btcdrak #rekt
致謝
本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 bitcoin-discuss 郵件列表，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。