2015-10-22 IRC 會議摘要

日誌

• 本週日誌連結
• meetbot 會議紀錄

主要議題

• 記憶體池記憶體使用
• LevelDB 替代方案
• 中位過去鎖定時間與 CLTV

簡短議題/備註

BIP 9 Versionbits PR #6816 已準備好實作，需要更多審查。

bitcoin-dev 郵件列表已開始為期 3 個月的審核期，以及新列表 bitcoin-discuss。更多詳情：http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011591.html

「bitcoin.org 的 0.11.1 版本發布說明不正確。現在已經更正了。他們發布了初始 RC 的發布說明，而沒有更新它們。從流程上來說，未來最好注意這一點。」

記憶體池記憶體使用

背景

當一筆交易在網路中傳播時，它會被節點保存在記憶體中，直到它進入區塊為止。所有這些存放在記憶體中的交易被稱為記憶體池（memorypool）或簡稱記憶體池（mempool）。 正如我們在垃圾攻擊期間所見，如果有大量無法進入區塊鏈的交易積壓，這個記憶體池可能會變得非常大，導致節點崩潰。

為了防止這種情況發生，開發者建立了一個從記憶體池中拒絕和/或移除交易的機制。這個記憶體池限制本週已經合併。

另外相關的：資料庫快取大小已經有一個現有的限制，稱為「dbCache」。該預設值為 100MB。

會議評論

測試顯示配置的記憶體池限制與實際記憶體使用之間存在差異。這是由處理交易時的 UTXO 資料量造成的。 這些資料只有在處理區塊後才會清除（因此暫時超過 dbCache 中設置的快取限制）。

對此有 2 個「明顯的」解決方案：

1. 始終強制執行 UTXO 快取限制，就像始終強制執行記憶體池限制一樣。 缺點是如果你錯誤配置記憶體池限制，攻擊可以清除你的 UTXO 快取，這會顯著減慢驗證和傳播速度。

2. 在限制記憶體池時考慮 UTXO 快取。 缺點是你可以建構需要更多快取空間的交易，從而更容易踢出其他交易。

更理想的解決方案是在快取中優先處理記憶體池中的事物。 實現這一點的方法是從記憶體池中被驅逐的交易中踢出 UTXO，以及從從未進入記憶體池的交易中踢出。 這是 TheBlueMatt 正在進行的工作

會議結論

繼續研究和優化。

LevelDB 替代方案

背景

LevelDB 是比特幣目前使用的資料庫系統。由於這已經有一段時間沒有維護了，開發者正在尋找替代方案。

會議評論

jgarzik 開發了一個 SQLite 補丁 有些人擔心 SQLite 的效能是否足夠好，但還沒有基準測試結果。

會議結論

研究其他選項 做大量基準測試並報告結果

中位過去鎖定時間與 CLTV

背景

當建立一個區塊時，礦工會包含一個時間戳記。這個時間戳記必須介於前 11 個區塊的中位數和網路調整時間 +2 小時之間。因此這個時間戳記可以與實際時間有相當大的差異。 隨著鎖定時間交易的引入，這些交易只有在特定時間後才有效，礦工被激勵對時間撒謊，以便包含原本無效的鎖定時間交易（及其手續費）。 BIP 113 啟用在鎖定時間交易中使用前一個區塊的 GetMedianTimePast（前 11 個區塊的中位數）來對抗這種行為。使用者可以通過在他們的鎖定時間中增加 1 小時（6 個區塊）來補償這一點。

CLTV 代表 CheckLockTimeVerify，BIP65 通常簡稱為：在你真正嘗試使用 nLockTime 之前，你以為它是如何運作的。

會議評論

CLTV 已準備好合併（並且在撰寫本文時已經合併） 關於是否將中位過去鎖定時間僅作為記憶體池還是作為軟分叉添加的問題 總體問題是在 CLTV 部署中包含什麼，什麼僅作為記憶體池包含，什麼作為軟分叉包含。 中位過去鎖定時間違反了當前的「標準」行為，因此我們希望在中位過去鎖定時間軟分叉向前推進之前，該違規在網路中消失。

會議結論

審查 BIP-113：僅記憶體池的中位時間過去作為鎖定時間計算的終點 審查 CLTV 向後移植（在撰寫本文時已完成並合併） 將中位過去鎖定時間向後移植到 0.10 和 0.11

參與者

btcdrak         btcdrak
sipa            Pieter Wuille
gmaxwell        Gregory Maxwell
BlueMatt        Matt Corallo
morcos          Alex Morcos
petertodd       Peter Todd
CodeShark       Eric Lombrozo
jgarzik         Jeff Garzik
maaku           Mark Friedenbach
kanzure         Bryan Bishop
jcorgan         Johnathan Corgan
Luke-Jr         Luke Dashjr
jonasschnelli   Jonas Schnelli
sdaftuar        Suhas Daftuar

致謝

本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 bitcoin-discuss 郵件列表，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。