2015-10-29 IRC 會議摘要
概覽
日誌
主要議題
- 即將到來的軟分叉
- 鏈限制
- Clang format
- BIP68 和 BIP112 實作
簡短議題/備註
LevelDB 議題已經開始，但推遲到會議後，因為目前沒有移動到另一個資料庫的計畫。然而，鼓勵進行研究和測試。mcelrath 自願製作一個 LMDB 分支，jgarzik 已經有一個 sqlite 分支。
即將到來的軟分叉
背景
CheckLockTimeVerify（CLTV）又稱「在你真正嘗試使用 nLockTime 之前，你以為它是如何運作的」是一個計畫在十月底發布的軟分叉（結果是十一月初）。
會議評論
檢查是否有任何需要包含在此版本中但尚未包含的內容。Luke-jr 有一個拉取請求開放以添加錯誤修復。 檢查關於其他客戶端的軟分叉是否有任何協調。btcd 已經準備好了，bitcoinj 歷史上沒有實作任何軟分叉。
會議結論
僅以 CLTV 作為軟分叉發布。
鏈限制
背景
在這個情境中，鏈是指連接的交易。當你發送一筆依賴於另一筆尚未確認的交易時，我們稱之為交易鏈。 理想情況下，礦工會考慮整個交易鏈，而不僅僅是每一筆單獨的交易（雖然據我所知這並未被廣泛實作）。因此，雖然單一交易可能沒有足夠的手續費，但一個依賴的交易可能有足夠高的手續費，使得挖取兩者都值得。 這通常被稱為子付父（child-pays-for-parent）。 由於你可以讓這些鏈變得非常大，因此可以通過這種方式堵塞記憶體池。 在最近的延展性攻擊中，任何進行多層深度交易的人都會遇到巨大的問題（在 let’s talk bitcoin #258 從 13:50 開始有很好的解釋） 提案和 github 連結。
會議評論
25 作為限制仍然非常高，可以更低。 關於哪些統計資料和測量對這個提案有用和相關的討論。
會議結論
Morcos 將進行一些額外的測量來支持該提案。
Clang format
背景
就像 libconsensus 一樣，這是為了整理程式碼，但更多的是關於程式碼本身的樣式和格式。引用 gmaxwell 在 github 評論中的部分內容： 「樣式一致性有實際的好處；它幫助新手貢獻，因為他們更容易確保他們的工作在樣式上是可以的；儘管這可能被他們在開始之前必須安裝某個特定版本的 clang-format 所抵消。它簡化了審查，因為統一性創造了更好的期望；但重新格式化使查看歷史記錄變得更困難，這妨礙了審查。良好的樣式選擇（與僅僅一致相對）有時已經被證明可以降低軟體中的缺陷率——但對於什麼選擇是好的並沒有普遍的意見。」
會議評論
之前的提議是 clang-format file set <a b c …> 一旦完成，通過自動化維護這些檔案的格式。 意見分歧很大。從不要為現有檔案更改任何內容到讓我們更改整個比特幣儲存庫。 某些行為從一個 Clang 版本到另一個版本會改變，這將要求每個人使用相同版本的 clang format，這很繁瑣。
會議結論
沒有結論。
BIP68 和 BIP112 實作
背景
簡而言之：BIP 68 將序號欄位的含義更改為相對鎖定時間。BIP 112 使該欄位可以被比特幣腳本系統存取。
會議評論
關於 LockTime 函數跳過不存在的輸入的擔憂。 為了審查目的，btcdrak 結合了兩個拉取請求（https://github.com/bitcoin/bitcoin/compare/master…btcdrak:sequenceandcsv）
會議結論
兩個實作應該保持單獨的拉取請求。 在 BIP 68 之前部署 BIP 112 沒有用處。
參與者
gmaxwell Gregory Maxwell
dcousens Daniel Cousens
sipa Pieter Wuille
jgarzik Jeff Garzik
morcos Alex Morcos
Luke-Jr Luke Dashjr
wumpus Wladimir J. van der Laan
mcelrath Bob McElrath
jtimon Jorge Timón
jonasshnelli Jonas Schnelli
btcdrak btcdrak
petertodd Peter Todd
dstadulis Daniel Stadulis
dgenr8 Tom Harding
jeremyrubin Jeremy Rubin
warren Warren Togami
rusty Rusty Russell
sdaftuar Suhas Daftuar
致謝
本摘要最初由 Stefan Gilis（別名「G1lius」）編寫並發布至 bitcoin-discuss 郵件列表，並附有免責聲明：「請記住我不是開發者，所以有些內容可能不正確或完全錯誤。」版權歸公共領域所有。