2017-02-23 IRC 会议总结

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

主要议题

• Git 和 SHA1 冲突
• 比特币核心 0.14.0 版本发布
• Travis CI 问题
• 代码重构

Git 和 SHA1 冲突

背景

在会议开始前几个小时，几名研究人员宣布他们已经产生了第一个案例，即两个不同的文件在使用 SHA1 哈希函数时具有相同的哈希值（这种情况称为哈希冲突）。

比特币核心和许多其他项目使用的 Git 版本控制系统使用 SHA1 哈希值来让人们确保他们拥有完全相同的代码。生成 SHA1 冲突的能力破坏了这种保证。

多年来，许多安全界成员一直在要求 Git 将 SHA1 更改为 SHA256 或其他更安全的哈希函数，但 Git 开发人员强烈反对这种更改（可能是因为它向后不兼容，这意味着所有 Git 用户可能都需要在几乎相同的时间进行升级）。

评论

讨论最初集中在澄清情况的严重程度，然后转向描述比特币核心项目在等待 Git 开发人员发布更安全的程序时可以处理此问题的潜在方法。提出的解决方案包括

• “我想知道创建覆盖层以回溯历史、计算每个树和提交的 sha256，然后在这些内容上包含 GPG 签名有多难？”（Pieter Wuille）

• “我们可以更新我们的开发脚本以对所有已提交文件执行 sha256sum 并对该文件进行签名 [...] 例如，合并脚本可以将 sha256sum * 的哈希值包含在提交消息中”（Matt Corallo）。 Gregory Maxwell 几乎同时提出了类似的建议。

• “我有一个针对 Git 的补丁，可以使用 [sha1collissiondetect] 作为哈希函数，并在检测到潜在的错误哈希时中止()。”（Matt Corallo）

结论

没有达成明确的结论，但开发人员可能会调查上述某些或所有解决方案，同时 Git 开发人员也会努力升级他们的程序。

比特币核心 0.14.0 版本发布

注意，此标题涵盖了会议中的两个相关主题：(1)“帮助 cfields 添加与性能相关的发布说明”和 (2)“RC2 状态”。

背景

在上一周的会议之后，比特币核心 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)，该版本似乎已准备好标记到 Git 中，除了一个小翻译更新和 PR#9829 已准备好合并，但 Travis 持续集成 (Travis CI) 测试失败。

结论

Cory Fields 将在 EC2 上执行初始同步的测试（此操作已完成，比特币核心 0.14.0 在初始同步方面的性能比比特币核心 0.13.2 快 5.7 倍）。在作者 Russell Yanofsky 表明他认为这些测试失败是由于 Travis CI 的间歇性问题后，PR#9829 的测试重新启动了。

会议结束后，RC2 被标记了。

Travis CI 问题

背景

比特币核心开发使用 Travis CI 测试平台对每个拉取请求 (PR) 运行项目的测试。这些测试仅在 PR 中的代码存在问题时才应失败，但有时这些测试会因与 Travis CI 相关的原因而失败。过去，这些问题包括 Travis 的错误以及比特币核心达到 Travis 的资源限制。

评论

在会议前大约一周，测试可执行文件 test_bitcoin 在 Travis CI 测试期间开始间歇性地失败。问题 9825 被打开来诊断问题并寻找解决方案。

会议评论集中在测试代码如何为构建日志创建堆栈跟踪，以及如何更改测试以获取可执行文件、核心转储以及其他构建和测试工件以供开发人员分析。

结论

继续调查故障，隔离问题，并努力修复它。

代码重构

背景

许多经济型完整节点使用比特币核心来执行共识规则。其他程序将从重用比特币核心使用的相同代码中受益，以确保它们符合共识规则，因此一些开发人员一直在努力使比特币核心代码库更加模块化，以便其部分内容可以在其他程序中使用。

尽管使代码库更加模块化的目标得到了项目贡献者的良好支持，但实际上移动代码往往会破坏其他开发人员的待处理更改，并消耗专家可用于审查比特币核心更改的宝贵时间，同时不会提供任何新功能或性能改进。这使得代码移动成为团队讨论的好主题，以便可以提前就更改达成一致，从而最大限度地减少中断。

评论

Jeremy Rubin 开始说：“我有一个 [概念证明] 分支，将大多数纯数据结构移动到一个 datastructures 目录。”他补充说：“非比特币特定 [数据结构]。例如，prevector。”

Gregory Maxwell 回复说：“我不认为我们中的任何人都关心维护像 prevector 这样的东西以供其他用途。创建一个好的库需要大量的努力。”

Wladimir van der Laan 同意说：“我认为比特币数据结构库没有意义。如果我们提供一个库，它应该对比特币用户有用。”

结论

会议期间没有明确结论（会议在此议题上时间用完）。会议结束后，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.

参与者

免责声明

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