2016-02-11 IRC 會議摘要
概覽
會議記錄
主要議題
- BIP68 審查
- 軟分叉邏輯（BIP9）
- squash/rebase 建議
簡短議題
Cfields 仍在處理網路堆疊的改造，他希望下週準備好。合併這種變更的最佳時機是在發布視窗開始時，所以大約是現在。否則我們將不得不推遲到 0.14
Petertodd 正在撰寫關於欺詐證明的文章/論文/部落格文章，以及一些相關的資料結構工作。Maaku 想與他合作處理欺詐證明和 prev-block 證明，因為他自己對此進行了探索。
BIP68 審查
背景
BIP 68 透過序列號訊號發送的共識強制交易替換。 BIP68 實作 僅記憶池 在會議後合併。
會議討論
BIP68 和 112 在作為軟分叉安全之前不需要記憶池部署，然而我們總是在軟分叉邏輯之前合併僅政策的實作。 軟分叉需要更多的審查和單元測試。
會議結論
將僅記憶池實作合併到 master，當軟分叉準備好時將記憶池 + 軟分叉回溯到 0.12.x。 審查/測試 BIP112 #7524（重新基底版本）
軟分叉邏輯（BIP9）
背景
BIP 9 目前軟分叉是透過 isSuperMajority 機制完成的，意思是當最近 1000 個區塊中有 95% 的版本號高於 X 時，分叉就會部署。 目前正在開發一種新方法，使用版本號的所有位元，適當地稱為 versionbits。 因此，不是在版本大於（例如）00000000011（3）時發生分叉，而是在（例如）第 3 位元被設定時發生分叉（即 00100000011）。 這樣軟分叉就可以同時且獨立地部署。
會議討論
需要 BIP 9，因為有太多未完成的軟分叉，可能會延遲所有軟分叉。然而，我們不應該因為 BIP9 開發的延遲而阻止有價值的軟分叉。 當另一個 isSuperMajority 軟分叉尚未完成時，我們可以透過 BIP9 進行部署。 目前 BIP9 實作的問題是：Codeshark 的版本有很多程式碼，似乎做了很多不相關的事情，而 Rusty 的版本從未有快取層使其高效。 Petertodd 指出它需要在資料庫中新增一些東西來儲存旗標，然而 sipa 提供了一個解決方案，為每個區塊計算一次狀態，之後保持不可變，並在啟動時重新計算。這樣你就不必在 chainstate 中儲存任何東西。 Morcos 退出了 BIP9 的工作。如果沒有其他志願者，jtimon 將會做。
會議結論
在 BIP9 合併之前進行 isSuperMajority 軟分叉。
squash/rebase 建議
背景
pull request 通常由幾個不同的提交（對程式碼的變更）組成。這些提交可以壓縮成一個提交。在先前討論的 BIP68 實作上，對於要壓縮什麼和不壓縮什麼進行了一些討論。
會議討論
提交有邏輯功能，你想講述一個你如何變更程式碼的故事，這很容易審查，不一定是你的時間順序變更。如果你有大量的「修復問題 X」，其中 X 是在同一個 pull 中引入的，那是沒有用的。 一個擔憂是壓縮對正在審查的人來說很煩人。 Sipa 指出，有一個本地審查腳本會很好，它儲存你審查過的提交/樹，然後向你顯示與你之前審查的內容的差異。
會議結論
一般規則是：做任何更容易閱讀和審查的事情。
與會者
wumpus Wladimir J. van der Laan
sipa Pieter Wuille
morcos Alex Morcos
maaku Mark Friedenbach
jtimon Jorge Timón
petertodd Peter Todd
gmaxwell Gregory Maxwell
paveljanik Pavel Janik
cfields Cory Fields
sdaftuar Suhas Daftuar