IRC meeting summary for 2017-02-16

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

主要議題

• 0.14.0RC1 發布
• 隨機性
• 時鐘

0.14.0RC1 發布

背景

Bitcoin Core 0.14.0 預定於 2017 年 3 月左右發布。針對 0.14 的開放 pull request 已標記 0.14 標籤。

會議評論

普遍認為發布準備度在過去兩週內顯著改善，第一個候選版本（RC1）可以在今天或未來幾天內發布。然而，仍有一些 Pull Request (PR) 即將完成審查，許多會議參與者希望在最終 0.14.0 版本中看到這些內容，因此在這個版本的發布流程中肯定會有至少第二個候選版本。

Andrew Chow 問道：「如果我們無論如何都需要 RC2，那麼發布 RC1 的意義是什麼？」幾個人回答了諸如「曝光」、「開始讓人們使用它」和「讓程式碼實際測試」等答案。Gregory Maxwell 對這些回覆進行了擴展：「我們通常不想做的是發布一個有嚴重問題的 RC1，這會嚴重傷害測試者，或者會以神秘方式失敗，讓我們無法從中學習。例如，如果我們有一個已知的崩潰修復，我們會保留 rc1，這樣我們就不會擔心每個使用者崩潰報告可能是一個未知問題。」

討論繼續進行，關於一個尚未完成的候選版本是否需要特殊標籤，但沒有人強烈推動這樣做，這個想法被放棄了。

暫定時程表是：「Wladimir van der Laan 將在明天早上釋出 RC1。如果今晚我們能說服人們合併其中一些東西，那將為 RC2 留下更少的工作。」

提議在審查後合併到 RC1 程式碼庫或 RC2 程式碼庫的 PR 包括：

• #9760 - [wallet] 由 ryanofsky 移除 importmulti 始終為真的檢查（由 Alex Morcos 提議，Jonas Schnelli 和 Gregory Maxwell 附議）

• #9761 - 由 ryanofsky 在 importmulti 重新掃描中使用 2 小時寬限期處理金鑰時間戳（由 Alex Morcos 提議，Jonas Schnelli 和 Gregory Maxwell 附議）

• #9773 - WIP：如果完整重新掃描不成功，從 importmulti 返回錯誤（在 #9761 之上）由 ryanofsky

• #9619 - 錯誤修復：RPC/挖礦：在隔離見證啟動之前，GBT 應返回 1 MB 大小限制，由 luke-jr（由 Jorge Timón 提議，在會議結束時討論更多）

結論

在未來幾天內發布 RC1，並將任何剩餘的修補程式納入 RC2。

隨機性

背景

Pieter Wuille 提議並透過描述當前狀態開啟了主題：「我們目前有 3 個『等級』的隨機性：fastrandomcontext、getrandbytes、getsecurerandbytes。我希望只有 2 個。」

1. FastRandomContext：目前需要 1.5 奈秒，但不是密碼學安全的偽隨機數生成器（CSPRNG）。

2. GetRandBytes：一個 CSPRNG。

3. GetStrongRandBytes：「用於私鑰。如果一切順利，它與 getrandbytes 一樣安全，但它更偏執，」Wuille 解釋道。

評論

Wuille 提議使用 ChaCha20 加密演算法使 GetRandBytes 非常快速，Linux 4.8 切換到在其 /dev/urandom 中使用它。一旦 GetRandBytes 快速，它也可以用來取代 FastRandomContext。

GetStrongRandBytes 可以繼續用於「像長期金鑰這樣的事情，我們不經常做，基本上沒有成本太高，並且 [它] 必須滿足我們能想像到的基本上每個安全特性，」Greg Maxwell 說。例如，它可以混合來自多個來源的熵（隨機性），即使是相當慢的來源，因為它相對慢是可以的。

結論

問題主要集中在理解 Wuille 的計劃上，沒有人反對 Wuille 嘗試計劃的第一部分，即更新 GetRandBytes 以使用 ChaCha20。

時鐘：不可轉換的時間

這是在「時鐘」主題下討論的兩個不同時間相關主題中的第一個。

背景

Pieter Wuille 解釋了問題：「我想解決的是 int 或 int64 現在可以表示微秒、毫秒或秒，以及系統時間、單調時間或網路調整時間的事實。它們是類似 int 的是可以的，但它們不應該可以從一個轉換為另一個。」

Gregory Maxwell 描述了為什麼這很重要：「我們多次因隱式轉換的一般問題而出現潛在嚴重的錯誤。（或者在 sighash single 的情況下，實際的共識行為缺陷。）所有資料都在編譯中以防止這些錯誤，我們只是沒有正確地公開它。:)」

評論

Cory Fields 提議並開啟了主題：「我有一些本地變更，實作了不同時鐘/時間點/持續時間的概念。目標是讓它們彼此不相容。目標是停止將時間儲存為 int，而是儲存為 time_value—這樣它可以在需要時以秒/毫秒/任何形式表示，它還強制執行不能在錯誤的時鐘上使用的時間戳。」

似乎沒有人不同意這個目標，討論集中在實作細節上。

結論

Cory Fields 和 Pieter Wuille 將在會議之外更深入地討論細節。（如果您感興趣，討論在會議之後立即繼續。）

時鐘：單調時間戳

這是在「時鐘」主題下討論的兩個不同時間相關主題中的第二個。

背景

單調時鐘是時間永不減少的時鐘。基於本地電腦時間（系統時間）的時鐘不是單調的，因為系統時間偶爾會向後調整。

比特幣的共識要求每個區塊必須具有大於區塊鏈上前 11 個區塊的中位時間戳的時間戳，從而提供單調時鐘（注意：有此處未討論的限制）。

評論

與使用不可轉換時間的主題相關，Wladimir van der Laan 建議「最重要的是，我們應該開始在網路程式碼中盡可能使用單調時間戳」。

Gregory Maxwell 說：「我過去曾建議我們考慮建構一個單調的本地時鐘，但 [Wladimir] 似乎不喜歡這個想法。我認為這與型別安全性問題是正交的，但它可能會使程式碼庫中的時間更加合理。」

Wladimir 回答：「嗯，我完全贊成在可能的情況下使用單調時鐘，它們只是不適合所有情況。」

使用單調時鐘的討論就此結束。本摘要的作者懷疑，當關於時間單位型別安全的其他工作取得進展時，將再次討論它。

結論

沒有結論。

小主題

重新排列與測試相關的事項

描述了對測試的次要變更願望清單：

• Jonas Schnelli 提議重新命名一些目錄，以幫助 GitHub 使用者新進專案的人找到最有用的測試。

• Pieter Wuille 建議進行一些額外的重新排列，透過分解出為不再使用的測試工具新增的目錄來提高生產力。

• Gregory Maxwell 建議將一些更耗時的測試作為標準編譯序列的一部分執行。

• Wladimir van der Laan 抱怨 RPC 測試的命名錯誤，因為它們今天測試的不僅僅是 RPC 介面（許多測試使用 RPC 介面來測試系統的其餘部分是否按預期運作）。

Schnelli 自願在 0.14 分割到單獨的 git 分支後建立一個 pull request 到主分支。

趣聞

<morcos> i think it is a mistake to call it experimental
<morcos> we don't want to devalue the meaning of that word

<wumpus> ok...

<morcos> sometimes we may want to have things that are actually experimental and we don't want people to think we just always say that

<wumpus> "this feature is experimental level 4"

<morcos> this is known to the state of CA to be experimental

<sipa> i'd briefly like to talk about randomness

<luke-jr> that's random.

<sipa> we currently have 3 "levels" of randomness

<wumpus> we need a random number of levels of randomness

參與者

免責聲明

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