IRC meeting summary for 2016-09-29

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

筆記 / 簡短議題

• Gmaxwell 提到了為守護程式設定 cron 模式的想法，它只是同步然後關閉，以便更輕鬆地保持區塊鏈副本的最新狀態。
• 下週的會議不太可能舉行（或參與者很少），因為大多數開發者都在前往米蘭 Scaling Bitcoin的途中。

主要議題

• 修剪和區塊中繼
• 移除檢查點
• Segwit 對抗未壓縮金鑰？

修剪和區塊中繼

背景

隨著 segwit 的引入，預期區塊會更大，從而對完整節點磁碟空間增加更大的壓力。有幾個想法圍繞添加服務標誌來表示區塊鏈已修剪，不會中繼歷史區塊。

會議討論

最簡單的解決方案是只添加一個標誌，表示你中繼有效的區塊和交易，但不中繼歷史區塊。當你想要多個範圍時會變得更困難，這樣節點就可以只託管一部分舊區塊。當你想以有效的方式支援分片時，它變得更加困難。

Sipa 一直在執行一些統計資料，關於從節點請求哪些區塊深度。他注意到 4 個有意義的範圍：

• 最上面的 2 個區塊（只是中繼，700 萬個請求中的 100,000 個）
• 深度達到 +/- 2500 個區塊（請求非常頻繁，每個區塊約 200-2000 個請求）
• 深度達到 +/- 10000 個區塊（比下一個範圍多請求幾次）
• 其餘的（每個區塊約 20 個請求）

Sipa 指出 4 個範圍可以用 2 個服務位元標誌完成。Wumpus 認為應該有一個服務標誌，並透過查詢表示範圍，這樣範圍的數量可以是可變的。

在「addr」訊息中添加節點範圍更加困難，gmaxwell 指出「addr」無論如何都需要相對快速地重做，因為這些訊息與 Tor 的新隱藏服務標準不相容。

Gmaxwell 之前正在開發一個提案，節點可以發出一個小種子，從中每個人都會知道它們將儲存歷史的哪些部分，但到目前為止，他無法使其既具有計算效率，又使對等節點永遠不會擷取它之前刪除的區塊。

Petertodd 指出區塊是線性下載的，所以我們可以利用這一點，確保具有一個範圍的節點追蹤具有相鄰範圍的節點。

如果服務位元用於表示服務最後 X 個區塊，它應該與最大修剪一致。Sipa 的資料表明深度達到 2000 個區塊的請求很多，而修剪節點的最小歷史記錄為 288 個區塊。

Morcos 建議當你落後少於 288 個區塊時，優先從修剪的對等節點下載，從而減輕完整歷史對等節點的負擔。

會議結論

• 從表示僅中繼深度 288 個區塊的服務位元開始，稍後可能添加另一個來表示更大的範圍。

移除檢查點

背景

每隔一段時間，舊的區塊雜湊就會硬編碼到 Bitcoin 軟體中。不同的實作選擇不同的檢查點位置。這些檢查點目前用於 3 種使用案例：

• 防止使用低難度 header 進行 header 洪水攻擊
• 跳過早期區塊中的簽名
• 估計進度

會議討論

Gmaxwell 提議完全移除檢查點。由於只有非常小比例的交易低於檢查點，並且自從 libsecp256k1 以來，簽名檢查只為同步時間增加了 15-20 分鐘。

為了防止 header 洪水攻擊，gmaxwell 提議永久增加最小難度（如果現有區塊破壞最小規則，則使用類似檢查點的規則繞過該規則）。

估計進度可以透過許多不同的方式完成。

Sipa 不相信，希望看到簽名跳過的替代方案，這可能會顯著改善事情。Gmaxwell 希望它是好的東西，因為否則可能會採用不謹慎的嘗試，例如 bitcoin classic 目前透過本地時鐘忽略超過 24 小時的簽名，這很容易被利用。

會議結論

• 制定提案以移除檢查點並用其他解決方案取代它

Segwit 對抗未壓縮金鑰？

背景

公鑰可以用兩種方式序列化：壓縮（33 位元組）或未壓縮（65 位元組）。自 Bitcoin QT 0.6 以來，使用壓縮版本。

會議討論

提案是在 segwit 交易中將未壓縮金鑰設為非標準。Sipa 指出在過去 2 小時內，未壓縮金鑰佔網路上使用金鑰的 0.7%。

Armory 仍然使用未壓縮金鑰。如果 segwit 強制壓縮金鑰，它將延遲 Armory 使用者採用 segwit。他們計劃無論如何都要有新的錢包結構，使用 BIP32 和壓縮金鑰以及 segwit 支援。Gmaxwell 認為壓縮金鑰支援可以完全在序列化 segwit scriptpubkey 的程序內部完成。

我們應該鼓勵所有錢包使用壓縮金鑰，並在需要時提供協助。

會議結論

• 在 segwit 中將未壓縮金鑰設為非標準
• 鼓勵錢包轉向壓縮金鑰

趣味環節

wumpus          otoh bittorrent has a fixed block size :)
sipa            wumpus: so do we *ducks*
btcdrak         inb4 Bittorrent XT
petertodd       btcdrak: I use Bittorrent Unlimited myself

gmaxwell        Might as well fit a cubic spline to the height vs txn count... and store the parameters.
sipa now remembers a song our student organization wrote to the melody of staying alive, called 'cubic spline'

與會者

免責聲明

本摘要由未參與討論的人編撰，因此任何錯誤均為摘要作者的責任，而非討論參與者的責任。