2018-05-10 IRC 会议总结

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

本次每周会议讨论的主题包括：会议参与者最希望看到审查的拉取请求、如果页面持续无法可靠加载则可能离开 GitHub、如何修复性能回归、未来在内存中存储交易脚本数据的设计以及是否创建额外的审查队列。

高优先级审查

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

讨论 (日志)：具体讨论的 PR 包括：

• [钱包] loadwallet RPC - 运行时加载钱包 (#10740)。这是 PR 集的一部分，如果被接受，将允许比特币核心在比特币核心 0.15.0 中添加的多钱包模式的上下文中，在运行时创建、加载和卸载钱包。在会议上，Joao Barbosa 建议此 PR“可以合并”并且 Wladimir van der Laan 说它“应该非常接近可以合并”。

• BIP 158：轻客户端的紧凑区块过滤器 (#12254)。此 PR 允许比特币核心为区块中包含的一些信息生成紧凑索引。然后，这些索引可以与轻量级客户端共享，以允许它们确定区块是否包含与客户端钱包相关的信息，此时客户端可以请求下载整个区块（可能来自不同的节点）。

在讨论特定 PR 时，第 N 次提到了 GitHub 页面无法加载（显示独角兽主题错误）的问题。Matt Corallo 说：“如果这个独角兽问题持续存在，我们将不得不离开 GitHub。大多数情况下，如果刷新足够次数或注销，它可以工作，但这两种方法都不是解决方案，因为刷新次数大约为 10，而且我们不能使用一半贡献者无法加载 PR 的平台。”

Wladimir van der Laan 回复说：“同意。GitHub 这样就毫无用处了。”其他参与者分享了他们偶尔解决此问题的方法。

结论：鼓励审查者访问项目的 当前高优先级 PR 列表。没有讨论离开 GitHub 的具体计划；看起来会议参与者希望 GitHub 能修复其系统。

在 CTransaction 中缓存见证哈希

背景：当比特币核心需要在内存中存储交易时，它会使用 CTransaction 数据类型。这包含足够的信息来构建交易的见证交易标识符（wtxid 或见证哈希）。可以扩展 CTransaction 数据类型以包含见证哈希的预计算（缓存）副本。

讨论 (日志)：Marco Falke 要求讨论该主题，引用了 PR #13011，并介绍了主题：“见证哈希用于所有松散交易，因此缓存它将加快验证速度（例如 [AcceptToMemoryPool] 和紧凑区块中继）。此外，对于没有见证的交易，见证哈希等于“普通哈希”[txid]，因此重新扫描/重新索引存在开销，但目前开销很小（因为没有太多带有见证的交易）。在我看来，缓存见证哈希的收益远大于重新扫描/重新索引期间的任何开销。当然，我们可以在未来的 PR 中重新设计重新扫描。”

Pieter Wuille 提供了反驳意见：“缺点是它使交易在内存中变得更大，并将一些特定于验证的逻辑硬编码到交易数据结构中（例如，这也影响从磁盘提供区块等）。“

Matt Corallo 支持该提案，“好处是我们纠正了一个重大的性能回归。”

Wuille 建议将用于交易的数据类型分开，以便在不需要时无需生成和存储见证哈希。Wladimir van der Laan 似乎同意，他说“让我们不要为了赶进度而让代码变得一团糟”。

还讨论了是否将提议的更改回传到比特币核心的下一个次要版本。Corallo 支持回传，但 Van der Laan、Cory Fields 和 Alex Morcos 反对（尽管可能不是强烈反对）。

结论：没有明确结论。PR #13011 在讨论期间被添加到 当前高优先级 PR 列表 中。

一次大型内存分配

背景：在比特币核心用 C++ 编程语言编写的代码中，用于内存分配的主要函数称为 malloc()。目前，如 PR #13062 中所述，为交易中的脚本分配内存的方式优化了 scriptPubKeys 的缓存，但在其他情况下性能不佳。该 PR 致力于将脚本在内存中的存储与程序中访问它们的方式分离，以便可以优化存储和访问（表示）。

讨论 (日志)：Cory Fields 要求讨论该主题并介绍了它：“我和 Pieter Wuille 简要讨论过：[……]每个区块一个脚本数据的内存分配。这让我想知道是否值得更改 P2P（网络协议消息）格式以使其更适合分配（下次我们更改某些内容时，而不是仅仅为了这个）。“

Jonas Schnelli 提供了一个示例，说明它是什么样子，正如 Fields 所确认的那样，“像 inv 大小这样的内容在实际 inv 数据之前。”

随后的讨论重点不是 Fields 的原始观点，而是 PR #13062 用于在内存中存储脚本的方法（称为 span）的优缺点。至少“除非有证明的使用”它，Matt Corallo 反对 span。

Fields 和 Wuille 赞成 span。Fields 说：“如果我们想解开我们的子系统，在我看来这绝对是必要的。”Wuille 同意，说：“没错：它将表示与处理分离。”

Corallo 反驳道：“为什么？如果它只是在 CScript 上操作，它就应该只在 CScript 上操作。”经过更多讨论后，Corallo 说他理解了潜在的优势，但仍然希望在进行更改之前看到它被用于可合并的 PR 中，“是的，我明白了，我喜欢这个选项……当我们有用户时。”

结论：没有明确结论。Wuille 和 Fields 可能需要付出更多努力来证明其方法的优势，然后才能接受与其相关的 PR。

审查协调

背景：比特币核心项目目前有 250 多个未完成的 PR，几乎所有这些 PR 都需要审查（或额外审查），然后才能考虑合并。多年来，贡献者一直表示希望该项目有更多人花更多时间审查 PR。

讨论：Jim Posen 要求并介绍了该主题，“除了高优先级 PR 列表之外，我认为还有另一个列表的空间，其中包含已获得概念确认的事项，供人们审查，以便每个人都在审查不同的内容，并且有一些实际的协调。”

Pieter Wuille 建议使用相对较新的网站 BitcoinACKS.com，Posen 同意“很棒”。Wuille 支持 Posen 的想法，“更好地概述哪些是概念确认（以及类似地，鼓励人们快速进行概念确认/否定确认）将是一件好事。”

Wladimir van der Laan 反对这个想法，他说：“现在每个人都可以有一个阻止他们的 PR 放在（当前高优先级列表）上，这应该促进合作。”Matt Corallo 同意，“百万个小问题 PR 审查方法对我们项目没有任何帮助，但审查高优先级列表上的内容确实有帮助（至少对我来说）。“

结论：没有明确结论。Corallo 个人总结道：“我认为我们本周的进展不会比过去 10 次讨论这个问题时更大。”

轻松一刻

<morcos> i'm back
<wumpus> welcome back!
  <sipa> hi back, i'm pieter
<morcos> oh man...

 <cfields> well another option is std::allocator magic,
           without having to switch to Span
  <wumpus> noooo
  <wumpus> no magic
 <cfields> wumpus: i can't argue with that, it looks like voodoo
    <sipa> damn cool voodoo.
    <sipa> but voodoo.
  <wumpus> c++ is already too much voodoo
    <sipa> let's switch to BASIC

    <sipa> bitcoinacks.com ? :)
<BlueMatt> apparently it doesnt distinguish between nacks and acks
    <sipa> ha.
  <wumpus> lol that's an interesting bug
    <sipa> "nack" "nack" "nack" "merged!"

参与者

免责声明

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