2017-02-16 IRC 会议总结

• 本周日志链接
• meetbot 记录的会议纪要

主要议题

• 0.14.0RC1 发布
• 随机性
• 时钟

0.14.0RC1 发布

背景

比特币核心 0.14.0 预计将在 2017 年 3 月左右发布。目标为 0.14 的开放的拉取请求已安排并标记为 0.14 标签。

会议评论

普遍认为，在过去的两周中，发布准备工作有了显着改善，并且可以在今天或未来几天内发布第一个候选发布版本 (RC1)。但是，仍然有一些拉取请求 (PR) 即将完成审查，许多会议参与者希望将其包含在最终的 0.14.0 版本中，因此在此版本的发布过程中肯定至少会有第二个候选发布版本。

Andrew Chow 问道：“如果我们无论如何都需要 [一个] RC2，那么制作 RC1 的意义何在？” 许多人回复了诸如“曝光”、“开始让人们使用它”和“让代码实际得到测试”之类的答案。Gregory Maxwell 扩展了这些回复：“我们通常不想做的是发布一个 RC1，其中包含严重危害测试人员或以我们无法从中学习的神秘方式失败的问题。例如，如果我们有一个已知的崩溃修复程序，我们将保留 rc1，这样我们就不用担心每个用户崩溃报告都可能是一个未知问题。”

关于是否需要为一个尚未完成的候选发布版本添加特殊标签进行了进一步讨论，但没有人强烈要求这样做，并且该想法被放弃了。

暂定的时间表是，“[Wladimir van der Laan] 将在明天早上发布 RC1。如果今晚我们能说服人们合并其他一些内容，那么 RC2 的工作量就会减少”。

提议在审查后合并到 RC1 代码库或 RC2 代码库中的 PR 包括

• #9760 - [钱包] 通过 ryanofsky 删除 importmulti 始终为真的检查（由 Alex Morcos 提出，Jonas Schnelli 和 Gregory Maxwell 附议）

• #9761 - 在 importmulti 重新扫描中使用 2 小时的宽限期，由 ryanofsky 提供（由 Alex Morcos 提出，Jonas Schnelli 和 Gregory Maxwell 附议）

• #9773 - 进行中：如果完整的重新扫描不成功，则从 importmulti 返回错误（在 #9761 之上），由 ryanofsky 提供

• #9619 - 错误修复：RPC/挖矿：GBT 应在 SegWit 激活之前返回 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，而是存储为时间值，这样它可以在需要时以秒/毫秒/任何单位表示 [并且] 它还强制执行不能在错误时钟上使用的时间戳。”

似乎没有人不同意这个目标，讨论集中在实现细节上。

结论

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 分支后，向主分支创建一个拉取请求。

轻松一刻

<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

参与者

免责声明

此总结是在未征求任何讨论参与者意见的情况下编写的，因此任何错误都是总结作者的过错，而不是讨论参与者的过错。