IRC meeting summary for 2017-04-20

• 本週會議記錄
• Meeting minutes by meetbot

註記 / 短議題

• 沒有報告 RC2 的問題，0.14.1 應該發布。（0.14.1 在會議後 2 天發布）

• 在 github 中有一些關於錢包處理地址重複使用和粉塵的有趣討論。任何對該主題感興趣的人可能想查看 PR #10233 上的討論以及從那裡連結的 PR。

主要議題

• 手續費估算
• 地址重複使用
• 高優先級審查

手續費估算

背景

在 Bitcoin Core 錢包中，你可以選擇希望看到交易確認的區塊數量，錢包將根據節點記憶池中交易的手續費率估算適當的手續費率。網路上的交易數量每日和每週都有很大變化，這使得這成為一個困難的平衡練習，既要確保交易在定義的時間範圍內得到確認，又要試圖讓使用者支付最小的手續費。

Morcos 一直在改進手續費估算演算法，並且根據上週會議的要求，撰寫了新手續費估算演算法的高層次描述。

會議意見

Morcos 在 #10199 中寫了一堆改進，但也有一些他想要反饋的開放問題。將改進的另一部分加入到更高層次的描述中是有意義的。手續費估算器足夠複雜，我們應該維護一個單獨的描述，甚至可能像許多主要協定功能一樣有一個實際的規範。

Gmaxwell 注意到該文件可能需要更多關於可靠性估算以及它如何合併桶的細節。總的來說，他補充說，我們應該嘗試使其足夠詳細，以便如果學術界出現並僅根據描述撰寫論文（他們會這樣做），結果對我們有用。

Morcos 也有一個計劃將估算器從記憶池中解耦，這建立在 BlueMatt 的 CValidationInterface 之上。

Gmaxwell 認為我們應該嘗試在未來保存更多的狀態，例如他有些節點每月停機時間不超過幾分鐘，但無法達到進行最準確手續費估算所需的兩週運行時間。

Jonasschnelli 想知道啟動後估算的可用速度有多快，以及它是否適用於修剪節點。Morcos 澄清修剪是無關的，對於 N 個區塊的目標，它需要至少 2*N 個區塊才能給你一個估算。之後它會保存資料，所以你可以重新啟動節點並立即獲得手續費估算。

會議結論

• Morcos 將向 gist 文件加入新的變更和澄清。

地址重複使用

背景

由於會議還有時間，開發者開始談論地址重複使用問題和可能的解決方案。

一個已經被積極利用了很長時間的隱私問題是，人們向已經花費過的地址進行接近粉塵的支付，這樣你再次從它們花費，在新交易中創建一個雪球效應，將你的所有交易連結在一起。

會議意見

Gmaxwell 注意到最新的討論是由一個經營賭博網站的使用者推動的，他關心這個，因為他的客戶收到了連結回他的交易。然而，這對每個人來說都是一個隱私問題。

Gmaxwell 修復這個問題的建議是創建一個單獨的隔離餘額，其中任何地址或特定 TXO 可以手動隔離。然後調整硬幣選擇演算法以始終一次性花費對特定地址的所有支付。一旦地址被花費過，自動將其加入到隔離餘額中。

Wumpus 和 BlueMatt 喜歡這個想法，但不確定是否將其作為預設策略。BlueMatt 舉了一個可能的問題的例子，商家收到一半的付款，從該地址花費，收到另一半，但沒有意識到他得到了付款，因為資金會被隔離。Morcos 喜歡自動隔離的想法，但不太認同預設花費所有輸入的想法。

Gmaxwell 認為如果最終目標不是將其作為預設，資源投資是不值得的。Wumpus 認為如果我們認為無論如何都有用，這是值得的。

會議結論

• 作為第一步，在硬幣選擇演算法中引入從給定地址自動花費所有資金。

高優先級審查

• PR #10148（使用非原子刷新進行區塊重放）在其目前的形式下，沒有多頭，只需要更多審查，也許還需要更多測試。
• Luke-jr 注意到 multiwallet 已經 rebase，nits 已經修復。CWalletDB 仍然需要一些認真的重構，但這應該在不同的 PR 中完成。

幽默時刻

jcorgan       clearly this calls for Deep Fee Estimation
gmaxwell      die
jcorgan       tell me what you *really* think
luke-jr       no no, Xtreme Deep Fee Estimation!
gmaxwell      I have a lovely algorithim for an efficient limited memory 2D exponentially weighed moving average somewhere...
sipa          Xthin fees

morcos        ok, so this sounds like general agreement that this is a good idea and has degenerated into arguing about defaults. all development discussion in a nutshell!

參與者

免責聲明

本摘要是在沒有任何討論參與者輸入的情況下編寫的，因此任何錯誤都是摘要作者的責任，而非討論參與者。