IRC meeting summary for 2017-02-23

• 本週日誌連結
• 會議紀錄（meetbot 版本）

主要議題

• Git 和 SHA1 碰撞
• Bitcoin Core 0.14.0 發布
• Travis CI 問題
• 程式碼重組

Git 和 SHA1 碰撞

背景

在會議開始前幾個小時，幾位研究人員宣布他們首次產生了兩個不同檔案在使用 SHA1 雜湊函數時具有相同雜湊的案例（這種情況稱為雜湊碰撞）。

Bitcoin Core 和許多其他專案使用的 Git 版本控制系統使用 SHA1 雜湊來允許人們確保他們都擁有完全相同的程式碼。產生 SHA1 碰撞的能力破壞了這種保證。

多年來，安全社群的許多成員一直要求 Git 從 SHA1 更改為 SHA256 或另一個更安全的雜湊函數，但 Git 開發者強烈抵制這種變更（可能是因為它不向後相容，這意味著所有 Git 使用者可能需要在大致相同的時間升級）。

評論

討論最初集中在澄清情況的嚴重性，然後轉向描述 Bitcoin Core 專案在等待 Git 開發者發布更安全的程式時可以處理問題的潛在方法。提出的解決方案包括：

• 「我想知道建立一個回溯歷史的覆蓋層有多困難，為每個樹和提交計算 sha256，然後包含對這些的 gpg 簽名？」（Pieter Wuille）

• 「我們可以更新我們的開發腳本，對所有提交的檔案執行 sha256sum 並對其進行簽名 […] 例如，合併腳本可以在提交訊息中包含 sha256sum * 的雜湊」（Matt Corallo）。Gregory Maxwell 在大約同一時間提出了非常類似的建議。

• 「我有一個 git 的修補程式，使用 [sha1collissiondetect] 作為雜湊函數，如果它檢測到可能不良的雜湊就 abort()。」（Matt Corallo）

結論

沒有達成明確的結論，但推測開發者將調查上述提出的部分或所有解決方案，同時 Git 開發者也在努力升級他們的程式。

Bitcoin Core 0.14.0 發布

注意，這個標題涵蓋了會議中的兩個相關主題，(1)「幫助 cfields 新增效能相關的發布說明」和 (2)「RC2 狀態」。

背景

Bitcoin Core 0.14.0 的第一個候選版本（RC1）在上週會議後發布。沒有發現重大問題，但仍有一些小修復和功能需要合併。

0.14.0 中的許多主要升級都是效能改進。

會議評論

Wladimir van der Laan 要求在場的人建議量化效能改進的方法，以便 Cory Fields 可以執行任何建議的測量並將結果新增到 PR#9787 的發布說明中。

Gregory Maxwell 建議：「使用上一個版本同步需要 N 小時，使用新版本同步需要 Y 小時。」

Fields 同意：「好的，我會新增一個模糊的 0.13 與 0.14 同步時間。不過 0.13 需要時間，我還沒有耐心完成一次。」

Jeremy Rubin 建議使用 Amazon EC2 作為測試環境，但 Wladimir van der Laan 警告：「EC 不是一個好的比較環境：I/O 非常慢」。Fields 回答說：「我使用 EC 進行同步基準測試，因為我認為它代表了一個非常典型的使用案例。」

討論轉向第二個候選版本（RC2），除了次要翻譯更新和 PR#9829 之外，似乎已準備好在 Git 中標記，後者已準備好合併但 Travis 持續整合（Travis CI）測試失敗。

結論

Cory Fields 將在 EC2 上執行初始同步測試（此後已完成，Bitcoin Core 0.14.0 在初始同步時的效能比 Bitcoin Core 0.13.2 快 5.7 倍）。PR#9829 的測試在其作者 Russell Yanofsky 表示他認為測試失敗是由於間歇性的 Travis CI 問題後重新啟動。

會議結束後，RC2 被標記。

Travis CI 問題

背景

Bitcoin Core 開發使用 Travis CI 測試平台對每個 Pull Request (PR) 執行專案的測試。測試僅在 PR 中的程式碼有問題時才會失敗，但有時測試會因與 Travis CI 相關的原因而失敗。過去這些問題包括 Travis 上的錯誤以及 Bitcoin Core 達到 Travis 的資源限制。

評論

在會議前約一週，測試執行檔 test_bitcoin 在 Travis CI 測試期間開始間歇性失敗。開啟了 Issue 9825 來診斷問題並研究解決方案。

會議評論集中在測試程式碼如何為建置日誌建立堆疊追蹤，以及如何變更測試以從 Travis 獲取可執行檔、核心傾印和其他建置和測試工件以供開發者分析。

結論

繼續調查失敗，隔離問題並努力修復它。

程式碼重組

背景

許多經濟全節點使用 Bitcoin Core 來強制執行共識規則。其他程式將受益於重用 Bitcoin Core 用於確保它們符合共識規則的相同程式碼，因此幾位開發者一直在努力使 Bitcoin Core 程式碼庫更加模組化，以便其部分可以在其他程式中使用。

儘管使程式碼庫更加模組化的目標得到了專案貢獻者的充分支援，但實際移動程式碼往往會破壞其他開發者的待處理變更，並消耗專家審查 Bitcoin Core 變更的有限時間—同時不提供新功能或效能改進。這使得程式碼移動成為團隊討論的好主題，以便可以提前商定變更，以盡量減少干擾。

評論

Jeremy Rubin 開始：「我有一個[概念驗證]分支，它將大部分純資料結構移動到資料結構目錄。」他補充說：「非比特幣特定的[資料結構]。例如，prevector。」

Gregory Maxwell 回答：「我認為我們都不關心為其他用途維護像 prevector 這樣的東西。製作一個好的函式庫需要大量的工作。」

Wladimir van der Laan 同意：「我不認為 bitcoin-datastructures 函式庫有意義。如果我們提供函式庫，它應該是對比特幣使用者有用的東西。」

結論

會議期間沒有明確的結論（會議在這個主題上沒時間了）。會議結束後討論繼續進行，Maxwell 和 Wladimir van der Laan 擴展了他們的觀點。

趣聞

<jonasschnelli> or syncs are roughly XYZ% faster...
<jonasschnelli> use the ~ and nobody will blame you afterwards. :)

<jeremyrubin> use two ~~ to be extra approximate

<wumpus> it's marketing not science :p hehe

<gmaxwell> but ~~ will just give you the same number you put in!

<jeremyrubin> The is-approximately operator is non-involutive ;)

<gmaxwell> Well people just have no general idea of the impact. Marketing would be saying that it's 2x faster rather than 3x faster because 2x is more plausible. :P

<gmaxwell> sipa: e.g. someday libstdc++ could get something that generalizes prevector, if it did, we'd drop prevector and use that.

<sipa> c++23

<gmaxwell> sipa: C++23 will just integrate libconsensus of course. template cryprocurrency.

參與者

免責聲明

本摘要由未參與討論的人員編譯，因此任何錯誤都是摘要作者的責任，而非討論參與者的責任。