2018-04-26 IRC 会议总结

• 查看本周的日志：BotBot.me 或 MeetBot
• 会议记录由 MeetBot 生成

本次周会讨论的话题包括：是否应该对“高度优先级审查”的 Pull Request（PR）进行更多审查，项目成员希望审查人员在下周重点审查哪些 PR，如何处理 bumpfee RPC 升级中对某个特定参数的处理，以及是否应该移除比特币核心默认禁用的“安全模式”。

高度优先级审查

背景： 每次会议，比特币核心开发者都会讨论会议参与者认为在下周最需要审查的 Pull Request（PR）。其中一些 PR 与贡献者特别希望在下一版本中看到的代码有关；另一些 PR 则会阻碍后续工作，或者需要进行大量的维护（重新整理）才能保持待处理状态。任何能够胜任的审查人员都鼓励访问项目 当前高优先级 PR 列表。

讨论 (日志): 在讨论具体问题之前，Matt Corallo 提出了一个担忧：“我们并没有真正对‘高优先级’列表进行任何审查，所以[我不确定]每星期提出它的作用。” 其他贡献者也同意，过去几周列表中的项目并没有得到太多审查，但许多评论似乎都支持保留这个列表。话题没有明确解决，但似乎该列表至少还会再使用一个星期。

本次会议再次简要提到了前两次周会总结中提到的某些 GitHub 页面无法加载（“独角兽”）的问题。

会议期间讨论的具体 PR 包括：

1. 将 validationinterface 拆分为并行验证/mempool 接口 (#12979)， 此 PR 之前已添加到列表中。此 PR 将与验证进入 mempool 的交易相关的逻辑拆分为单独的验证和 mempool 接口，使获取有关 mempool 的某些信息变得更加容易，并为改进比特币核心费用估算器奠定基础。

   Pieter Wuille 指出，他“开始审查 #12979，但难以理解[它]”。PR 作者 Corallo 说，“这只是一个纯重构。它[所做]的只是移动了一些东西。” Corallo 还提到，它之所以位于高优先级列表中，是因为它“阻碍了大约 10 项其他事情。”

2. 引入 getblockstats RPC 以[提供可用于]绘制图表的数据 (#10757)， 此 PR 之前由 Jorge Timón 提名。此 PR 添加了一个新的 RPC，它返回有关指定区块的各种详细信息和统计数据。

   Anthony Towns 指出，此 PR 在上周收到了部分审查，但仍有一些小问题待解决。

“totalFee” 作为 bumpfee 参数的必要性

背景： 比特币核心提供了一个 bumpfee RPC，允许增加（“提升”）用户任何发出 BIP125 替换-通过-费用（RBF）交易可替换性信号的未确认交易所支付的交易费用。默认情况下，此 RPC 会自行计算增加的金额，但它也允许用户选择性地使用 totalFee 参数指定新的费用。

讨论 (日志): Gregory Sanders 请求了这个话题，并问道：“[totalFee 参数] 是否有必要？[…] 我希望在不久的将来升级 RBF/CPFP [子交易支付父交易]，但为了支持[这个参数]，[它]会使逻辑变得复杂。”

Anthony Towns 建议，可以使用此参数（或替换参数）作为用户愿意支付的费用上限，如果自动确定的增加值超过上限，则 RPC 会报错。

Sanders 进一步描述了他希望放弃此参数的动机：“我重新设计了[bumpfee]，使其只使用 CreateTransaction，以便它可以选择更多硬币，从而改变大小。” 换句话说，在替换交易中添加更多输入（硬币）会使替换交易比原始交易更大，需要支付额外的费用来支付增加的大小——但用户在使用特定 totalFee 参数调用 bumpfee 时并不会知道这一点。

Luke Dashjr、Suhas Daftuar 和 Pieter Wuille 都似乎同意，当改变交易大小的时候，totalFee 似乎没有意义。

结论： 没有明确的结论。Sanders 通过建议他可以将升级后的 bumpfee 设计为默认允许额外输入，但可以选择性地支持使用 totalFee 参数时的旧行为，而不会添加额外输入，并且当当前输入不足以支付所需费用增加时，RPC 会失败。这将是“向后兼容的，不会产生额外的杂物”。

移除 safemode

背景： 比特币核心软件的早期版本（当时称为“比特币”）引入了“安全模式”，该模式在网络中断期间会禁用某些 RPC，以防止用户损失资金。触发安全模式的条件已经随着时间的推移而改变，安全模式中禁用的 RPC 列表很少添加新 RPC，最终比特币核心 0.16 默认禁用了安全模式。

讨论 (日志): Wladimir van der Laan 请求了这个话题，参考了 Andrew Chow 提交的 PR #10563，Van der Laan 重新整理了该 PR，将其改为 PR #13090，并问道：“安全模式自 0.16 以来一直被禁用；我们应该在 0.17 中完全移除它吗？”

几位贡献者表示，他们不知道有人在使用它，也不认为它目前有用。Pieter Wuille 说：“禁用 RPC 并不是比特币生态系统应对紧急情况的方式——很多基础设施甚至都不会注意到。”

Van der Laan 指出，比特币核心将继续提供一个 -alertnotify 启动参数，该参数可用于在安全模式将要激活时运行任意脚本。Luke Dashjr 建议，可以使用 -alertnotify 与一个拟议中的新 RPC walletunload 一起使用，在紧急情况下禁用钱包；这与当前的安全模式设计类似（甚至可能更好）。

结论： 尽管有几位参与者希望比特币核心能够更好地检测破坏性网络状况，并能够自动采取措施帮助用户避免损失资金，但所有参与者似乎都赞成移除当前不受支持的安全模式系统。会议结束后，#13090 被合并到开发分支中，以移除安全模式。

请注意，在关于移除安全模式的讨论中，将 -alertnotify 与拟议中的新 RPC walletunload 结合使用的建议被误解为是要求讨论目前正在进行的 walletunload 工作。这就是为什么“walletunload” 会出现在 MeetBot 会议总结中，即使它没有被直接讨论。

小主题

另一个简短讨论的话题是关于自 Cory Fields 在 1 月份向邮件列表发送关于该主题的 邮件 以来，为比特币核心二进制文件签署证书的更新。在邮件中，Fields 说 Gregory Maxwell 正在努力“建立一个新的阈值签名方案，这将使我们能够在没有任何单点故障的情况下处理代码签名。” 由于 Maxwell 没有参加会议，因此没有提供任何更新。

幽默

<wumpus>  #topic walletunload (Lukejr)
<LukeJr>  wumpus: I wasn't suggesting it as a topic
<wumpus>  LukeJr: oh...
  <sipa>  #unload walletunload
<wumpus>  #untopic

参与者

免责声明

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