IRC 會議摘要 2015-12-17
概覽
記錄
主要議題
- 錢包中的手續費替換處理
- 0.13 的 C++11
錢包中的手續費替換 (RBF) 處理
背景
目前當節點看到一個花費相同輸出的交易時，它會忽略它。使用 RBF，如果新交易有更高的手續費，它會替換記憶池中的當前交易。 這允許諸如花費「卡住」的交易、向交易添加更多收款人以防止鏈接等功能。
由於有些人接受零確認交易，而這會使雙重支付變得極其容易，所以這被設為選擇性。 發送者可以通過改變所有輸入的 nSequence 欄位來選擇使用 RBF。 這是即將推出的 0.12 版本的記憶池策略。 在 reddit 上有一篇很好的 FAQ 式貼文關於它。
會議意見
0.12 的功能凍結自 12 月 1 日起生效，除了錯誤修復外，現在 0.12 分支中的內容將被發布。 #7219 使 RBF 策略成為可選的（0 = 從不，1 = 總是，2 = 選擇性加入）可能不會進入 0.12。 jonasschnelli 和 harding 要求為 RBF 錢包策略提供好的想法以及處理這個問題的方法。 Android 錢包透過點擊提升 UI 來提升手續費（透過 CPFP）。 添加提升手續費相當簡單，做更多如添加輸入和輸出可能會使當前錢包變得非常複雜。 對於包含輸入和輸出，你會想要準備一個包含 A+B 的已簽署交易和另一個只包含 B 的已簽署交易，該交易花費 A 中建立的找零輸出。 對於 0.13，我們希望至少看到一個手續費提升選項和一些原始交易指令來修改錢包交易。
會議結論
0.13 的 C++11
背景
C++11 是 C++ 語言的更新。它提供新的功能、擴展的標準函式庫等。 Zerocash 必須用一些 c++11 函式庫編寫，一些 IBLT 模擬程式碼是用 c++11 編寫的，他們希望將其回收用於最終的 core 提交。
會議意見
未解決的建置問題是相依性相容性和 Travis 的編譯器。 對 boost 函式庫有一些擔憂，因為它是共識關鍵的。在 0.13 之前移除 boost 的使用（在共識中）消除了這種擔憂。 風險是我們不可逆地陷入 C++11 並在 0.13 發布時發現大部分使用者群無法處理它。 如果程式碼開始差異太大，回移也更困難。 更多的測試會很好，但 travis 拉取測試器已經很慢了，所以添加更多設定可能不好。 可能有第二個免費的替代方案可以並行建置更多設定。 zero-cash 和 bitcoin core 團隊都希望在許多平台上對這些東西進行自動化測試，這可以由 buildbot 完成。 我們也可以向發行版尋求協助。 Wumpus 準備好在 travis 建置/通過後立即將建置切換到 std=c++11。
會議結論
- 每個人都希望 0.13 有 C++11
- 將一些建置切換到 C++11
##參與者
wumpus Wladimir J. van der Laan
cfields Cory Fields
sipa Pieter Wuille
jonasshnelli Jonas Schnelli
petertodd Peter Todd
Luke-Jr Luke Dashjr
nwilcox Nathan Wilcox
zookolaptop Zooko Wilcox-O'Hearn
sdaftuar Suhas Daftuar
harding David A. Harding
jgarzik Jeff Garzik
btcdrak btcdrak
幽默時刻
19:03 petertodd wumpus：v0.12 分支中的 RBF 處理是將要發布的嗎？也就是說，我們已經功能凍結了嗎？
19:04 wumpus 是的，我們在 12 月 1 日已經功能凍結了
19:04 petertodd 酷
19:04 petertodd 或者我應該說，冰凍
( ••) ( ••)>⌐■-■ (⌐■_■) YYYYYYYEEEEEAAAAAAAAAAHHHHHHHHHHHH
致謝
本摘要最初由 Stefan Gilis（又名「G1lius」）編譯並發布到 bitcoin-discuss 郵件列表，並附有免責聲明：「請記住我不是開發者，所以有些事情可能不正確或完全錯誤。」並將版權置於公共領域。