2015-10-15 IRC 會議摘要
概覽
日誌
主要議題
- 記憶體池限制
- sendheaders BIP
- versionbits
- dev/discuss 列表政策
- CHECKSEQUENCEVERIFY
記憶體池限制
背景
當一筆交易在網路中傳播時，它會被節點保存在記憶體中，直到它進入區塊為止。所有這些存放在記憶體中的交易被稱為記憶體池（memorypool）或簡稱記憶體池（mempool）。 正如我們在垃圾攻擊期間所見，如果有大量無法進入區塊鏈的交易積壓，這個記憶體池可能會變得非常大，導致節點崩潰。
為了防止這種情況發生，開發者正在嘗試找到一種方法來限制這個記憶體池，也就是一種從記憶體池中拒絕和/或移除交易的機制。這裡最困難的部分是確保節點不會因為濫用這個機制而受到攻擊。 到目前為止，開發者採用 TheBlueMatt 的丟棄最便宜的交易並將最低傳播費用設置為該費用提案。
會議評論
在測試時，sipa 遇到了需要 200ms 才能被接受進入記憶體池的交易。 由於這是他第一次對此進行基準測試，而且拉取請求不應該對這些時間產生影響，因此可能與此無關。然而，無論如何，這樣的時間都是不好的。 sipa 測試中的平均時間是 4ms。（會議後 Morcos 做了一些基準測試，確認這不是此 PR 特有的，並指出異常值來自 CheckInputs 和 HaveInputs（正如你所猜測的，與檢查輸入有關） 關於為什麼我們應該將最低傳播費用（節點傳播交易的最低費用）恢復到 1000（它已被設置為 5000 以快速修復記憶體池問題）的問題，sipa 認為它也應該浮動，否則灰塵限制會變得無效。
會議結論
審查 PR 6722 透過丟棄最便宜的交易並將最低傳播費用設置為該費用來限制記憶體池 Morcos/sipa 將做更多基準測試並對 PR 發表評論（morcos 的基準測試結果）
sendheaders BIP
背景
send headers BIP 從 BIP 複製/貼上： 自從在 0.10 中引入「標頭優先」下載區塊以來，除非區塊能夠連接到（有效的）標頭鏈，否則不會被處理。因此，區塊傳播通常的運作方式如下：
- 節點（N）使用「inv」訊息宣布新的頂端，包含區塊雜湊
- 對等節點（P）以「getheaders」訊息（請求到新頂端的標頭）和「getdata」訊息請求新頂端本身來回應「inv」
- N 以「headers」訊息（包含新區塊的標頭以及 P 未知的任何前面的標頭）和包含新區塊的「block」訊息回應 然而，在宣布建立在頂端上的新區塊的情況下，如果節點 N 只是宣布新區塊的區塊標頭，而不僅僅是區塊雜湊，並節省對等節點生成和傳輸 getheaders 訊息（以及所需的區塊定位器）的時間，通常會更有效率。
會議評論
關於如何推進的問題。如何讓節點知道你想要區塊標頭而不是區塊雜湊。 選項：
- 擴展版本訊息。
- 有一個可以發送標誌的「options」訊息。
- 在連接時儘早發送「sendheaders」訊息，以便立即知道對等節點希望如何宣布區塊。
- 在任何時間發送「sendheaders」訊息，將對等節點希望的區塊宣布方式從雜湊更改為標頭。
沒有人喜歡進一步擴展版本訊息。 相對於「sendheaders」訊息，「options」訊息沒有強大的優勢。 讓訊息在早期發送可能過於限制。morcos 的可能使用案例：「未來的某些優化完全可能會說，我想向這些對等節點發送 sendheaders，因為他們向我宣布了很多新內容，而不是向其他節點發送，因為他們沒有」。 大多數人喜歡這只能啟用，所以沒有訊息可以返回接收區塊雜湊。這就是 BIP 的起草方式。
會議結論
sdaftuar 為 BIP 提交拉取請求以獲得分配的編號，並按起草的方式繼續推進 BIP。
versionbits
背景
BIP 9 目前軟分叉是通過 isSuperMajority 機制完成的，意思是當最後 X 個區塊中有 95% 的版本號高於 Y 時，分叉就會被部署。 一種新的做法目前正在開發中，它使用版本號的所有位元，被恰當地稱為 versionbits。因此，分叉不是在版本大於（例如）00000000011（3）時發生，而是在（例如）第 3 位元被設置時發生（即 00100000011）。 這樣一來，軟分叉可以同時且獨立地部署。
會議評論
從 IRC 複製/貼上，因為我不知道這具體是什麼意思： CodeShark：所以現在它只是一個實作 versionbits 邏輯的單元，但沒有演示其用法 我認為最好在單獨的 PR 中實際整合，但我可以添加一個演示 sipa：單獨的提交，同一個 PR - 我認為我們需要一個可以作為整體合併的東西，以便能夠看到整個東西是否容易向後移植
Codeshark（正在實作 versionbits）還有一些其他評論，但似乎沒有人審查過它，所以進一步討論也沒什麼用處。
會議結論
dev/discuss 列表政策
背景
bitcoin-dev 郵件列表僅用於技術討論。有些事情不屬於那裡，但無論如何都需要討論。 現在這是在 bitcoin-dev 中完成的，但這個數量變得太大了。 最近也有大量非常不適當的帖文湧入，程度達幼稚園級別。 對於不屬於 bitcoin-dev 但無論如何都需要討論的事情，正在建立一個新列表，即 bitcoin-discuss，以及兩者的明確政策和審核。
會議評論
Bitcoin-discuss 已經建立，但管理員密碼沒有分發給願意指導審核的 jgarzik。 同時已經提出了單獨的審核提案。 人們只是希望它繼續推進。
會議結論
由於提出審核方案的人都不在場，我們讓他們相互討論並公開發布他們的決定。
CHECKSEQUENCEVERIFY
背景
CheckLockTimeVerify（CLTV）重新利用了 nSequence 欄位（nSequence 是 4 個位元組，用於排序時間鎖定交易，但這從未被使用過）。然而，沒有辦法在比特幣腳本中使用這些值。 CheckSequenceVerify（CSV）使這個欄位可以被比特幣腳本存取。
編輯：結果這不完全正確，因為是相對鎖定時間重新利用了 nSequence 欄位。
會議評論
CLTV 幾乎完成了。 檢查 maaku 移動其中一個位元以允許其他實作具有更好的粒度是否有任何異議。 只要我們使用盡可能少的位元，確切的語義對大多數人來說就不那麼重要。 sipa 指出了一個可能影響錢包的錯誤。 CSV 不在月底的目標上，儘管已經做了很多工作並取得了進展。
會議結論
- 審查並 ACK/NACK 6312 BIP-68：僅記憶體池的序號約束驗證
- 審查並 ACK/NACK 6566 BIP-113：僅記憶體池的中位時間過去作為鎖定時間計算的終點
參與者
wumpus Wladimir J. van der Laan
sipa Pieter Wuille
btcdrak btcdrak
gmaxwell Gregory Maxwell
morcos Alex Morcos
maaku Mark Friedenbach
CodeShark Eric Lombrozo
BlueMatt Matt Corallo
sdaftuar Suhas Daftuar
warren Warren Togami
GreenIsMyPepper Joseph Poon
davec Dave Collins
cfields Cory Fields
jonasschnelli Jonas Schnelli
幽默時刻
19:21 sdaftuar 聽起來每個人都同意起草的 BIP 了？ 19:21 wumpus 是的 19:21 gmaxwell 我認為是的。 19:22 davec 是的 19:22 sipa 嗯，唯一有疑慮的人是 cfields，他似乎不在這裡 :) 19:22 gmaxwell sipa：他也可以稍後提出疑慮！ 19:22 cfields 該死！ 19:22 sipa cfields：太遲了！ 19:22 gmaxwell 哈 19:23 cfields 我真的連續錯過了第三次這個會議嗎？
致謝
本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 bitcoin-dev 郵件列表，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。