IRC meeting summary for 2016-06-09

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

主要議題

• 編譯時間 / 記憶體使用量
• segwit 更新
• 緊湊區塊測試

註記 / 簡短議題

• Bitcoin Core 的功能凍結預定在下週，所有需要合併的功能都應該在那之前合併。Cfields 有 2 個 p2p 重構 PR 他希望合併，這些可以在凍結後完成，因為那些不是新功能。
• 在上次會議的評論關於軟體生命週期頁面之後，Btcdrak 和 David Harding 一直在努力更新該頁面，使其更清晰和更具代表性，在這裡以及進一步在這裡，這需要審查。

編譯時間 / 記憶體使用量

背景

問題 6658（建置需要 >1GB 記憶體）和 7471（用 512 MB RAM 建置沒有太多空間）討論了編譯時對 RAM 的需求不斷增加。

會議評論

Gmaxwell 指出我們不能再使用預設設定在僅有 2GB RAM 的主機上編譯，而我們的文件說 1.5GB。

TheBlueMatt 準備了一個補丁，將所有記憶體池內容移出，顯然可以將其恢復到 1.5GB。但他還沒有提出 pull request。

Wumpus 指出使用 Clang 建置通常在相同編譯設定下使用的記憶體要少得多。

編譯時間可能與記憶體使用量相關，因為磁碟尋找/讀取存取可以忽略不計。

為 ARM 和 AARCH64 新增二進位建置將減少關於記憶體問題的抱怨。Cfields 正在致力於此。使用者目前可以使用交叉編譯，但是 gmaxwell 指出許多使用類似 raspberry pi 系統的人沒有另一個 linux 主機。

會議結論

Cfields 計劃為 0.13 新增不帶 GUI 的 ARM 二進位檔案（會議後在 PR #8188 中完成）

Segwit 更新

背景

開發者正在致力於軟分叉，以在比特幣主網上引入隔離見證。隔離見證 (segwit) 允許交易簽名資料儲存在用於產生交易識別符的雜湊資料之外，消除所有已知形式的第三方可塑性，允許完整節點在不下載所有簽名的情況下編譯當前的 UTXO 集，並為欺詐證明奠定基礎，這可以允許輕量級 (SPV) 客戶端幫助執行更多共識規則。segwit 軟分叉還允許礦工用 4 位元組的 segwit 資料替換 1 位元組的區塊空間，增加使用 segwit 的錢包的交易容量。隔離見證 BIP：BIP141、BIP142、BIP143、BIP144 和 BIP145

會議評論

在程式碼減去軟分叉可以進入 0.13 之前，仍有一些錯誤需要修復。Sipa 指出下一批補丁將解決所有問題。

Luke-jr 希望最大見證程式長度為 75 位元組，而不是現在的 40 位元組。他認為沒有必要限制（低於 75，因為高於 75 將需要更多變更和額外測試），較小的限制很可能會阻止未來的軟分叉。稍後擴充限制將需要硬分叉。Sipa 認為應該不需要超過 256 位元雜湊 + 一些版本控制中繼資料，設定更多會給人一種印象，或者正如 petertodd 所闡述的：會給人一種印象，比特幣比那更破碎。Gmaxwell 加入並認為他看到的最大危害是允許更大的大小可能會限制未來使 UTXO 條目大小受限的能力。但是進一步限制可以稍後發生。他還指出將來可以透過使用不同的版本類型信號來擴充這一點，但這將需要除了當前承諾之外的新承諾。

會議結論

討論繼續，並被推遲到會議外。

緊湊區塊測試

背景

BIP152：「緊湊區塊中繼」是 BlueMatt 提出的一個想法，透過對應該在節點記憶體池中的交易使用短交易 ID 來減少區塊中繼期間使用的頻寬。作為副作用，這也會減少區塊傳輸延遲。

會議評論

公共網路上有許多節點執行緊湊區塊，一切似乎運作良好。Instagibbs 製作了一個圖表。Gmaxwell 一直在執行修改版本的測試，將雜湊大小減少到 16 位元，透過使碰撞更常見來測試圍繞碰撞的罕見邊緣情況。兩個大型礦池一直在執行它，其中一個位於中國的防火長城後面。

Cfields 想知道是否討論過緊湊區塊的服務位元。之前提出的論點是服務位元應該僅用於關鍵所需的服務。由於它可能會足夠快地變得普遍，所以不需要。只有礦工才真正需要它，但他們無論如何都應該手動管理他們的連接。

會議結論

• 與區塊擷取邏輯的互動需要更多審查。
• 審查者應該停止使用 sipa 的分支，因為 PR #8068 已在 shared_ptr 工作 之上重新建立。
• 審查 PR #8084（將最近接受的區塊和交易新增到 AttemptToEvictConnection）

娛樂時刻

wumpus       #link https://github.com/bitcoin/bitcoin/issues/7471
cfields_     wumpus: thanks
wumpus       eeh that's the wrong one
gmaxwell     wumpus: unthanks

Lightsword   maybe we should just have a service bit for flagging fast relay nodes/miners in general for preferential peering rather than making it flag compact blocks specifically
sipa         Lightsword: we should also have an evil bit that abusive nodes should set

參與者

免責聲明

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