2018-06-21 IRC 会议纪要

• 查看本周日志，请访问 BotBot.me 或 MeetBot
• MeetBot 编写的会议记录

本次每周会议讨论的主题包括：项目成员希望审查人员在下周重点关注哪些拉取请求、何时披露与签名警报系统相关的比特币核心 0.12.0 及更早版本已知的 DoS 漏洞以及发起 DoS 攻击的机制（中本聪的警报签名密钥）、比特币开发者邮件列表托管方式的更改、默认情况下如何选择输入包含在新的交易中、处理多钱包模式下新钱包的加载、改进私钥备份和恢复以及继续努力创建机器可读的配置文件。

审查阻塞 [审查的高优先级]

背景：每次会议，比特币核心开发者都会讨论会议参与者认为在下周最需要审查的拉取请求 (PR)。其中一些 PR 与贡献者特别希望在下一个版本中看到的代码相关；另一些 PR 则会阻止进一步的工作，或者需要进行大量的维护（重新设定基准）才能保持挂起状态。任何有能力的审查人员都鼓励访问项目的 当前高优先级 PR 列表。

讨论 (日志): Pieter Wuille 列出了当前列表中的三个 PR (#13062、#12196 和 #13425)，并询问是否有人想提名其他 PR。João Barbosa 建议 #13100，它添加了一个打开钱包的菜单项，但它还没有完全准备好，因此 Wuille 将等到它准备好后再添加。

警报密钥 [公开披露]

背景：2010 年，有人创建了一个协议有效的区块，产生了超过 1840 亿个比特币。中本聪鼓励用户停止挖矿，并很快发布了比特币的更新版本，在追溯性软分叉中纠正了该行为，但他随后在比特币软件中添加了一种机制，允许他签署“警报”消息，可以直接通知节点操作员问题，甚至默认情况下关闭可能导致金钱损失的一些节点功能。在中本聪 在 BitcoinTalk.org 论坛上的最后帖子中，他写道：

“安全模式”警报是在 0.3.9 溢出错误后采取的临时措施。我们可以说我们希望用户只需使用“-disablesafemode”运行，但为了外观起见，最好不要使用它。它从未打算作为长期功能。“安全模式”仍然可以通过看到更长（更大的总工作量证明）的无效区块链来触发。

随着时间的推移，随后的比特币核心开发者逐渐弃用、禁用并删除了警报功能，在 0.12.1 版本中将其默认关闭，在 0.13.0 版本中完全将其移除，在 0.14.0 版本中将最终警报硬编码，并在（2016 年 11 月）宣布即将公开披露中本聪创建的警报签名密钥。在发现与 0.12.1 以下版本的比特币核心中的警报机制相关的拒绝服务 (DoS) 漏洞后，披露被无限期推迟，如 2017 年 3 月 9 日的每周会议中所讨论，当时大约影响了 2600 个节点。

讨论 (日志): Bryan Bishop 提出并介绍了该主题：“我正在考虑发布私有 [警报签名] 密钥。[它] 发布出来并消除这种责任会很好。我特别想听听那些有充分理由不透露密钥的人的意见。在宣布 [计划公开披露] 之后的一年多时间里，我认为没有提出太多问题。”

Gregory Maxwell 说：“所有受支持的 [比特币核心] 版本都已完全删除 [签名警报系统]，因此现在发布听起来非常好——除非 0.12 之前的节点仍然很流行，我不认为它们很流行。”

Luke Dashjr 引用了他的 节点扫描系统来说，3% 的节点运行的是 0.12 版本，“0.61% 的‘其他’版本，其中包括 0.12 之前的版本”。Pieter Wuille 使用 Bitnodes 扫描系统发现了类似的统计数据，该系统使用不同的扫描方法。

关于旧版比特币核心中的签名警报消息相关的漏洞，Maxwell 说：“我怀疑我们是否知道所有漏洞。我知道至少两个，但我停止了寻找。” Andrew Chow 说他知道三个。

DoS 漏洞不仅影响比特币，还影响复制了比特币核心代码并目前正在使用旧版本的山寨币。当漏洞披露时，任何拥有山寨币警报签名密钥的人都可以执行这些 DoS 攻击。在讨论此事时，Chow 说：“但是]如果山寨币对其警报密钥有更好的控制，那么发布比特币密钥和相关漏洞应该不成问题。”

结论：没有明确的结论。Bishop 似乎可能会继续努力负责任地披露警报密钥（可能还有与其相关的漏洞）。没有人反对这一点，尽管 Matt Corallo 确实表示他认为“发布警报密钥的效用有限”。

Bitcoin-dev 邮件列表

背景：比特币开发者 (Bitcoin development) 邮件列表在过去几年一直托管在 lists.linuxfoundation.org 上。

讨论 (日志): Bryan Bishop 提出并介绍了该主题：“Linux 基金会正在迁移出电子邮件协议，并且将不再托管比特币开发者邮件列表。有一个迁移计划，但仍在调查中。”

对列表当前的交付问题进行了一些简短的讨论，表达了希望旧帖子的现有 URL 保持有效的愿望，以及其他迁移问题。

结论：Bishop 将向邮件列表发送一封电子邮件，希望在迁移到新的主机域之前，一旦他获得更多详细信息，就会发送。

硬币选择

背景：一些开发者一直在努力改进比特币核心的硬币选择——它如何选择要花费的哪些比特币（输入）——以同时提高隐私、减小交易规模和降低费用。当前的选择协议以分支定界 (BnB) 算法开始，该算法试图在可用的输入和发送的金额之间找到匹配项。如果这不起作用，则需要回退算法。单随机抽取 (SRD) 算法随机向部分交易添加额外的输入，直到输入的总和等于或大于要花费的金额（包括费用）。

本周的讨论是 上周关于同一主题的讨论的延续。

讨论 (日志): Andrew Chow 提出并介绍了该主题：“我做了一系列关于 [单随机抽取] 回退内容的模拟 (链接)。我看到了这种策略的两个问题：找零可能非常小，并且钱包中 UTXO 的平均数量相当高。问题是我们是否可以接受这些权衡，或者是否需要找到更好的算法。”

Gregory Maxwell 说：“[如果我记得没错]，[单随机抽取] 本身没有什么根本的东西能使其更适合使 [分支定界] 工作得更好，而更像是 [Mark Erhardt] 在那里尝试的第一个替代方案。”

Chow 补充说：“嗯，在 [Erhardt] 的模拟中，[单随机抽取] 的表现相当不错，而且非常简单。尽管我想我们现在可能看到了不同的结果。”

讨论了各种其他策略及其权衡，但对于时间有限的纯文本会议的一小部分来说，主题开始变得复杂。

结论：Chow 建议：“也许这种硬币选择讨论最好在现场用白板进行”，结束了会议讨论，尽管 Maxwell 指出：“这排除了无法参加的人”。大概讨论将在 PR #13307 以及其他地方继续进行。

多钱包会话持久性

背景：比特币核心的开发分支（“主”分支）包含允许用户在多钱包模式下动态加载和卸载单个钱包的代码。例如，您可以拥有一个“个人”钱包和一个“业务”钱包，每个钱包都可以分别打开或关闭。

讨论 (日志): Jonas Schnelli 提出并介绍了该主题：“我想在比特币核心重新启动后需要重新加载已加载的钱包并不是理想的——尤其是在修剪模式下。”也就是说，用户创建或加载钱包，然后在不更改配置文件的情况下重新启动比特币核心，下次加载该钱包时将不得不重新扫描区块链的最新部分。更糟糕的是，如果重新扫描所需的一些区块已被修剪，则用户将无法使用该钱包。

一些会议参与者建议这就是正在开发的可写比特币配置文件 (rwconf) 的用途。有关背景信息，请参阅 PR #11082 以及 2018 年 5 月 24 日和 2018 年 6 月 7 日的每周会议记录。

结论：“好的，我想 rw/config 可以解决这个问题，所以/topic，”Schnelli 说。

Bech32x

背景：一些比特币核心贡献者一直在努力为备份和恢复比特币私钥、HD 钱包种子、HD 钱包扩展私钥和 HD 钱包扩展公钥创建新的序列化格式。主要目标是用一种不仅可以检测错误，还可以自动为用户纠正其中一些错误的新标准替换当前流行的 base58check 和 BIP39 标准。此提议格式的当前想法重新使用了为创建 bech32 本机隔离见证地址格式而执行的一些工作，因此工作在“bech32x”（但这以后可能会更改）的名称下进行。

讨论 (日志): Jonas Schnelli 提出并介绍了该主题：“Bech32x 目前具有距离为 27 的 BCH，可更正 7 个字符，这要感谢 [Pieter Wuille]。现在的想法是设置三个更正‘级别’。[…]对于 512 位密钥材料来说，七个字符的更正率并不比 5% 多多少 [因此至少在那种情况下需要更多]。”

Wuille 提供了三种用户可以选择使用的代码。Gregory Maxwell 说：“我认为不适合将其普遍设置为用户可选择。用户通常无法做出有用的决定——但在我看来，使格式支持多种代码似乎还可以，尽管这可能会降低编写花哨解码器的几率，因为它会增加工作量。”

Wuille 说：“我们可以确保他们使用相同的字段和扩展，这样大部分恢复代码就可以共享。”Wuille 和 Maxwell 继续讨论为该目的选择最佳 BCH 代码的细节。

结论：会议结束的时间发生在讨论期间，Maxwell 说：“稍后再继续。”

RWConf [可写入的比特币配置文件]

这个话题是在会议期间提出的，但没有足够的时间讨论。尽管如此，一些参与者还是在会议结束后留下来立即讨论了它。

背景：正如 2018 年 5 月 24 日会议中所讨论的，几位贡献者正在努力创建一个机器可读的配置文件，该文件将在 Bitcoin Core 的守护进程和 GUI 之间共享，以便当用户在一个程序中更改设置时，它将在另一个程序中以相同的方式设置。在 2018 年 6 月 7 日会议中提出了创建新配置文件的一个特殊问题，但最熟悉该主题的人员没有出席；他在会议后的这次讨论中出席了。

讨论 (日志 rwconf): Luke Dashjr 要求了这个话题，并在会议后通过询问 AJ Towns 是否反对 Dashjr 回退 Towns 更改 Bitcoin Core 启动时处理命令行和配置文件参数方式的一个提交来介绍它。这将解决 Dashjr 在创建可写配置文件时遇到的问题。

Pieter Wuille 建议了一种额外的机制，Towns 指出了 Dashjr 的提议中与网络配置相关的一个潜在问题。然而，Towns 说：“无论如何，我不反对更改映射内容，[它]只是我想到的获得相对合理行为的最简单方法。”

结论：没有明确的结论。大概 Dashjr 将继续致力于创建机器可读的配置文件。

轻松一刻

<gmaxwell>  I doubt we know all the vulnerabilities.
            I know of at least two but I stopped looking.
<achow101>  gmaxwell: I believe I know of three
<gmaxwell>  Also depends on how you count. :)
<achow101>  that too
    <sipa>  i tend to count using the ring of integers

参与者

免责声明

这份总结是在没有征求任何讨论参与者意见的情况下编写的，因此任何错误都是总结作者的责任，而不是讨论参与者的责任。特别是，从讨论中摘录的引语对其大小写、标点符号和拼写进行了修改，以生成一致的句子。作者添加了括号中的单词和片段，以及背景叙述和说明，并且可能意外地改变了一些句子的含义。如果您认为任何引语脱离了上下文，请 提交问题，我们将更正错误。