IRC meeting summary for 2017-05-18

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

註記 / 短議題

• 新的手續費估算器已經合併。現在執行 master 將清除你的舊手續費估算。Morcos 將嘗試進行改進，使其對 0.15 更無縫。

主要議題

• 客戶端過濾
• 修剪節點服務
• bytes_serialized

客戶端過濾

背景

為了讓輕量級 SPV 客戶端不必下載整個區塊鏈內容，創建了 BIP37。此 BIP 通過對等網路協定使用布隆過濾器，讓完整節點向 SPV 客戶端發送一小部分交易，其中包括 SPV 客戶端錢包所需的所有相關交易。

隨著時間推移，這種方法似乎沒有最初想像的那麼強大。

• BIP37 中預期的隱私作為布隆過濾器概率性質的結果最終不存在。
• 隨著區塊鏈變得更大，完整節點上有顯著的處理負載，因為它們必須處理整個區塊鏈以服務同步的 SPV 客戶端。這也使其容易受到 DoS 攻擊。
• SPV 客戶端不能有強大的安全性期望，因為默克爾路徑允許它們驗證輸出是可花費的，但它不能證明輸出稍後未被花費。

已經提出了許多改進這種情況的想法，都有各自的權衡。最近 Roasbeef 一直在進行基於 golomb 編碼集的想法，它比布隆過濾器小，但需要更多 CPU 時間。

會議意見

首先，這將是節點預先計算和儲存的東西。讓區塊承諾這個可以稍後完成。

Gmaxwell 對 golomb 編碼的效能持懷疑態度，但他有興趣看到它。

Roasbeef 建議兩個過濾器，一個用於包括輸出點和腳本資料推送的超輕量級客戶端，另一個用於包括見證堆疊、sig 腳本資料推送和交易 ID 的更複雜查詢。Gmaxwell 評論加入見證資料具有長期影響，因為從現在起幾年後，我們可以期望大多數節點不會儲存超過一年前的見證資料。Roasbeef 澄清包含見證資料的理由是允許輕客戶端有效地掃描隱形地址之類的東西。然而，在實踐中沒有人這樣使用它，任何實作它的人都通過中心化伺服器進行掃描。Sipa 的偏好是只有輸出點和完整的 scriptPubKeys。資料推送相對於完整 scriptPubKey 的唯一優勢是對於裸多重簽名，但那些在實踐中並不真正使用。

Jonasschnelli 補充 Kallewoof 對通過 p2p 網路通過布隆過濾提供過濾器有一個草案實作

會議結論

• Roasbeef 將製作一個包含會議反饋的 BIP（郵件列表文章）

修剪節點服務

背景

目前修剪節點不會宣告自己擁有任何區塊，因此它們不向其他對等節點提供任何區塊。隨著區塊鏈大小的持續增長，修剪節點的數量在未來可能會增加。

非修剪的完整節點通過 NODE_NETWORK 宣告自己，Jonasschnelli 在 2017-05-27 會議中建議製作一個訊息來宣告轉發並能夠提供最後 144 個區塊（1 天的區塊）的修剪節點，即 NODE_NETWORK_LIMITED。

會議意見

Sipa 有一些可用資料，顯示從他的節點下載的每個區塊的相對深度，排除緊湊區塊。它確認 144 個區塊太小，修剪最小值 288 更好。Gmaxwell 認為 BIP 不應該有任何餘地/緩衝，只需宣告它們實際儲存的內容。如果結果證明節點沒有你需要的所有區塊，你可以連線到其他人。它也應該只說明需要儲存的區塊數量，而不要與時間有任何聯繫，因為輕客戶端在標頭同步後知道它們落後多少區塊，與時間無關。Gmaxwell 補充 BIP 還應該提到你可以為整個鏈提供標頭。

會議結論

• Jonasschnelli 將把反饋納入 BIP。

bytes_serialized

背景

目前 gettxoutsetinfo 有一個稱為 bytes_serialized 的欄位，它基於 UTXO 集資料的某種理論序列化，以顯示資料庫以位元組為單位的大小。然而，在實踐中，這不是 UTXO 集在磁碟上佔用多少空間的好指標。

會議意見

Wumpus 認為應該有一種中立的方式來表示 UTXO 大小，不依賴於特定資料庫格式的估算。他可以接受它只是以中立格式的鍵和值的大小，不考慮 levelDB 前綴壓縮。

更改 bytes_serialized 的格式允許更改定義。

我們也應該在 gettxoutsetinfo 中報告實際磁碟使用量。

Wumpus 認為重新命名該欄位也是有意義的。

會議結論

• PR #10195 將移除 bytes_serialized，Sipa 將創建一個單獨的 PR 來加入新的 disk_size 和 bogosize 來取代它。

高優先級審查

• Ryanofsky 希望對 #10295（將一些 WalletModel 函數移動到 CWallet）進行更多審查，因為它阻礙了他的 IPC PR。
• Jonasschnelli 加入了 #10240（加入 HD 錢包自動恢復功能）

幽默時刻

wumpus        time to close the meeting I think
instagibbs    2 minutes
luke-jr       defer BIP148 to next week?
wumpus        luke-jr: oh forgot about that one
luke-jr       it's okay, a week might be good anyway
gmaxwell      I'm sure you can discuss it in one minute.
gmaxwell      :p
kanzure       we need a meeting extension block
luke-jr       gmaxwell: well, to be fair, we've never had a formal time limit for meetings..
luke-jr       :p
instagibbs    it's a standardness rule...
kanzure       it was to prevent spam
gmaxwell      I like that they're limited. even though I always spend another half hour in resulting discussions.
gmaxwell      kanzure: that limit was temporary!
sipa          we should revert to the original limit of 24 hours
luke-jr       sipa: IMO the original limit was 5 hours
luke-jr       sipa: since that's how long until the day changes in UTC
gmaxwell      luke-jr: That isn't consistent with Craig Wright^W^WSatoshi's vision!
luke-jr       gmaxwell: it's consistent with tonal though
cfields       sipa: nah, let's just use an accounting trick and have meetings on a plane zooming through timezones.
cfields       I'm pretty sure we can cram 2 days into 1 that way :p
gmaxwell      too bad they stopped flying the concord.
sipa          you just need a plane circeling the arctic

參與者

免責聲明

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