2017-03-02 IRC 会议总结

• 链接到本周日志
• 会议记录由 meetbot 生成

主要话题

• 0.14.0 版本发布
• 优先审查和合并请求
• 0.15 的重大功能
• Segwit 激活后 GetBlockTemplate 的行为
• CreateNewBlock 是否调用 TestBlockValidity 以及 CreateNewBlock 缓存
• (空)

0.14.0 版本发布

背景

在上一周的会议之后，比特币核心 0.14.0 的第二个和第三个候选版本 (RC2 和 RC3) 被发布了。

0.14.0 中许多主要的升级是性能改进。

评论

简要讨论了已发布一周的 RC2 和最近发布的 RC3 的状态。没有开发者知道任何问题，一个人报告说看到了一些来自 RC 测试者的正面评论。

结论

两位会议参与者建议如果 RC3 没有发现任何问题，则在 3 月 7 日星期二发布比特币核心 0.14.0 的最终版本。

优先审查和合并请求

背景

当对代码库的多个不同的建议更改以不同的方式编辑相同的代码行时，就会产生一个冲突，该冲突无法通过自动版本控制软件解决。相反，开发人员需要手动查看每个冲突的更改并确定要保留哪个更改，或者是否需要将更改合并在一起。

解决这些冲突非常耗时，大多数开发人员发现它非常烦人，特别是因为这种情况通常可以在第一个开发人员的建议更改在任何后续开发人员开始工作之前合并到代码库中时避免。

此外，由于代码在解决冲突时经常会发生变化，因此更改的代码通常需要由比特币核心的有限的经验丰富的代码审阅人员重新审阅。

由于这些原因，开发团队试图优先审查和合并可能会导致许多冲突更改的拉取请求 (PR)。

评论

Alex Morcos 开启了主题，“我想简要讨论一下合并 #9602 的时间。因为，假设我们要做，最好把它解决掉，这样就不会变成一个重新整理/审查的噩梦。我还有很多建立在它之上的费用估计更改。”

Matt Corallo 回复说，“很快就会完成审查，但到目前为止 [对我来说看起来不错]。[我] 同意应该尽快合并。”

Suhas Daftuar 补充说，“我也在做一些挖掘调整，我宁愿在 9602 的基础上进行构建。”

Corallo 提出了另一个优先审查请求，“我想 Luke 的不使用 pwalletMin 的事情也很难重新整理。那就是 #8775。”

结论

“尽快审查和合并 #8775 和 #9602，它们很容易变成重新整理/合并的噩梦，”Wladimir van der Laan 说。

0.15.0 的重大功能

注意: 这是在前面的重新整理主题中讨论的。

背景

Gregory Maxwell 开始了讨论，“这可能很有用，不是在这次会议上，而是让大家思考他们希望 0.15 的重大功能是什么，并确保我们早点在这方面取得进展，这样它们才能真正存在。:) 我感觉有些事情我个人在 0.14 中想要，但直到太迟才没有给予足够的关注。”

Wladimir van der Laan 做了一个调查，看看是否有人有“大型即将到来的软分叉项目 [这将] 垄断所有人”，但 Maxwell 回复说，“所有这些都因为 segwit 被搁置了！”，因此 Wladimir 建议“这意味着 0.15 可以专注于软件功能而不是网络/共识功能。”

讨论

Alex Morcos 问，“我们有没有任何建议的 [软分叉] 不是建立在 segwit 之上的？让我们利用 BIP 9！”Pieter Wuille 回复说：“提高最低难度，可选的 UTXO 承诺，……”。

• 提高最低难度 有望成为从与共识兼容的完整节点（如比特币核心）中删除区块链检查点的最后一步。检查点是在 比特币 0.3.2 中添加的，以“锁定到目前为止的区块链”，这减少了某些攻击的有效性，但也提供了一种机制，可以覆盖比特币的基本规则之一：网络的账本是最有工作量证明 (PoW) 的有效区块链。

  提高最低难度将使攻击成本更高（因为它们需要包含比现在相同的攻击更多的 PoW），而不会阻碍比特币使用 PoW 来选择有效链之间。

  有关更多背景信息，请参阅 讨论 （在 2016 年 10 月 27 日的会议中）以及 使用链工作量的 IBD （在比特币核心 0.13.2 中发布）和 假设有效的区块 （在比特币核心 0.14.0 中发布）。

• 可选的未花费交易输出 (UTXO) 承诺可以帮助提高轻量级钱包的安全性。这是一个已经由多个贡献者（大部分独立工作但共享想法）进行了几年零星研究的主题。本摘要的作者不知道有任何具体提案，即使是在技术界中获得了广泛的初步认可。

Morcos 还建议，“我脑海中的一个主要功能，但有点复杂，因此可能需要一些讨论才能确定我们是否想要它（以及何时），那就是自动费用上调。”Maxwell 建议使用一个不同的名称，“我建议用“预先计算的费用上调”替换“自动费用上调””。

• 预先计算的费用上调 由 Maxwell 在会议中简要描述，“当您签名时，预先签名所有上调，锁定时间……这样它们就不会干扰钱包加密……甚至可以交由其他人处理，如果您离线的话。”

  例如，Alice 会告诉比特币核心她在接下来的 10 个区块内要向 Bob 付款，并指出她愿意支付的最高费用。

  比特币核心将使用其现有的费用估计功能，以及在比特币核心 0.14.0 中引入的可选费用上调功能，来创建一个向 Bob 的初始版本的交易，该交易支付在 10 个区块内确认的交易的最低预期费用。同时，比特币核心还会创建可能另外 9 个版本的交易，第一个版本使用 nLockTime 来确保它不能在两个区块之前添加；第二个版本锁定在三个区块之前；等等……

  这些后续交易中的每一个都将比原始交易支付更高的费用（最高可达 Alice 指示的最大费用），以增加矿工挖掘该交易的激励。

  因为所有版本的交易都在 Alice 发送初始交易时签名，所以她只需要解锁一次钱包。此外，因为所有后续版本的交易都将使用 nLockTime，所以 Alice 可以将这些交易的副本无信任地分发给其他人，以便他们在 Alice 离线的情况下稍后进行广播。

  简而言之，该软件将自动提供 Alice 的最高费用，如果它必须这样做，但如果它能够避免，它将支付更低的费用——确保 Alice 获得尽可能接近的最佳价格，而无需任何额外的努力。

结论

没有明确的结论。可以推测开发人员将在未来的一周专注于发布 0.14.0，然后将花更多时间讨论 0.15 的目标。

Segwit 激活后 GetBlockTemplate 的行为

注意: 这是在前面的重新整理主题中也讨论过的。

背景

Segwit 被设计为在 segwit 激活后让矿工选择。

1. 矿工可以像现在一样生成旧式的区块，但这些区块不能包含任何 segwit 交易（因此矿工可能会收到更少的交易费用）。

2. 矿工可以生成 segwit 样式的区块并挖掘 segwit 交易，获取任何可用的额外费用。要做到这一点，单人矿工和矿池运营商需要将其软件更新到支持 segwit 的版本。

单人矿工和矿池的软件从比特币核心的 GetBlockTemplate (GBT) 远程过程调用 (RPC) 中获取未确认交易和其他挖掘信息列表。

目前，比特币核心默认情况下只允许矿工使用 BIP9 版本位来表示对 segwit 的支持，前提是他们已经使用 GBT 对 segwit 兼容的挖掘软件进行了升级（或伪造）。但是，比特币核心默认情况下还会在 segwit 激活后，停止为任何未升级到 segwit 兼容软件的矿工提供 GBT 结果；下面引用的会议评论解释了为什么做出这个选择。

评论

Gregory Maxwell 开始了讨论，“[我认为] 我们应该重新考虑一些关于 segwit 如何运作的事情：我们不会在 segwit 激活后挖掘，除非设置了标志，而且我们不会在没有设置标志的情况下设置版本位。”

Suhas Daftuar 解释说，“我们这样做是为了让 segwit 无法在没有矿工真正挖掘 segwit 交易的情况下激活。我的担忧（在我们到达现在的阶段之前）是 segwit 可能会在 0 个矿工挖掘的情况下激活，然后内存池可能会被无法确认的交易攻击。”

Maxwell 的回复是，“是的，但我认为这是一个错误。那么，如果他们没有呢？那么，在他们升级之前，segwit 交易的容量就会减少，他们会损失费用。”

Alex Morcos 同意并补充说，“只要我们知道 SOME 矿工正在挖掘它们，这似乎是我们现在的阶段。”Daftuar 也同意现在放松安全条件，Matt Corallo 似乎也同意。

结论

没有明确的结论，但会议参与者似乎普遍同意更改比特币核心，以便在 segwit 激活后，继续为未使用 segwit 标志调用 GBT 的矿工挖掘有效的旧式区块。

CreateNewBlock 是否调用 TestBlockValidity 以及 CreateNewBlock 缓存

背景

比特币核心中的主要功能，用于为矿工组装新区块，称为 CreateNewBlock (CNB)。作为在将创建的区块提供给矿工之前最后一步，会调用 TestBlockValidity (TBV) 功能，以确保创建的区块将是有效的——如果矿工找到所需的证明工作量，就会被其他节点接受。

比特币矿工 James Hilliard (Lightsword) 已经打开了一个拉取请求 (PR)，该请求从 CNB 中删除了 TBV (#9858)，以及一个将 TBV 设为可选的替代 PR (#9859)，解释道：“在这里获得无效模板不应该发生，除非 bitcoind 中存在 bug，[所以] 这个 TestBlockValidity 调用只是一个内部健全性检查”。

有关 TBV 的更多背景信息，请参阅上面链接的问题中的讨论。

评论

Pieter Wuille 建议了主题，Gregory Maxwell 开始了讨论：“我们需要将 TBV 从关键路径中移除。但我并不完全同意 Lightsword 的观点——我认为拥有一个测试我们正在分发以进行挖掘的区块的过程很重要。它不需要在关键路径中。”

Alex Morcos 做了更详细的解释，“把它留在关键路径中的缺点是，在空区块上额外花费 150 毫秒的挖掘时间。”

Pieter Wuille 列举了几个选项：“一个简单的 [解决方案]（直接删除测试）；或者一个复杂的 [解决方案]（后台验证、缓存，……)”

关于后台验证和缓存的技术讨论随之而来，参与者都支持这两种方法，但还没有明确的设计，因此可能需要进一步讨论。

Morcos 建议说：“老实说，我认为更重要的方向是首先用更好的框架替换 GBT [GetBlockTemplate]。” Wuille 和 Maxwell 回复说，改变 TBV 的使用方法和替换 GBT 看起来是两个独立（正交）的主题；Morcos 同意，但补充说：“也许我的意思是，我们应该设计一个更好的东西，这样它就能告诉我们想要从 CNB/TBV 中得到什么。并记录下设计，这样我们才不会忘记...即使我们现在不做。”

没有人反对实验性设计，但似乎也没有人对此感到热情。

讨论转向了在收到新区块到验证该区块之间这段短暂时间内进行无验证挖矿的可能性。Morcos 描述了这种方法的工作原理：“从网络获取一个新区块 -> 假设有效 -> 将所有 [其] 事务在 mempool 中标记为可能已使用 -> 从剩余的 mempool 中获取 CNB -> 尚未验证新的区块头或 TBV 新模板，如果我们找到了一个区块，就这样吧。”

Maxwell 指出：“在这种情况下，你会扩展一个无效的区块，这不好（让矿工即使在相对短暂的时间内也扩展无效区块，[因为] 这会极大地放大轻客户端的风险 - 尤其是在 [挖矿] 设备可能停留在旧工作上长达数十秒的情况下）。"

Matt Corallo的想法和 Morcos 类似：“我更喜欢不依赖于验证速度 - 在获取区块模板所需的 100 毫秒内挖掘空区块，并在验证期间转发区块。”

Maxwell 提到了他写的一个 BIP 草案，用于减少无验证挖矿对轻客户端安全性的危害。Corallo 同意：“我认为当我们开始返回空区块时应该实施它:) 我也乐意在轻客户端中实施它。”

讨论此时回到了技术细节，重点关注挖矿软件如何处理比特币核心返回的空区块以及挖矿池软件返回的空区块。

结论

没有明确的结论。所有到场的开发人员似乎都致力于改善这种情况，但没有人直接支持 #9858 或 #9859 中的解决方案。在会议结束后约 10 分钟，这些 PR 的作者在 IRC 上变得可用，并开始与开发人员讨论可能进行的一些短期优化，而更重要的（但更长期的工作）则在进行中。

话题: (空)

在先前关于在需要结果时生成空区块模板的讨论中，Pieter Wuille 提醒大家他们只有 5 分钟时间来讨论其他主题，导致 Gregory Maxwell 匆忙提出了“空消息”这个主题。关于这个主题的全部讨论在下面的“喜剧解救”部分中进行了转载。

幽默

<sipa> we're running out of time
       any other topics?

<gmaxwell> quick, empty messages

<sipa>

<luke-jr>

<wumpus>

<gmaxwell>

<luke-jr> inb4 trolls use this as proof we obey gmaxwell

<gwillen>

<BlueMatt> lulwut

<wumpus> #topic

<sipa> it's "lolwut", BlueMatt.

<BlueMatt> lulzwutz

<wumpus> cleared the topic, too, now we can cleanly exit the meeting

<gmaxwell> We should appoint a subcommittee to investigate the spelling of lolwut/lulwut.

<wumpus> #endmeeting

参与者

免责声明

这个摘要是在没有讨论参与者任何人的输入的情况下编写的，因此任何错误都是摘要作者的过错，而不是讨论参与者的过错。