2017-03-16 IRC 会议摘要

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

主要议题

• 钱包如何处理长时间的未确认交易链
• 账户系统移除状态
• 修改 make check 测试

钱包如何处理长时间的未确认交易链

背景

比特币核心允许其钱包用户创建未确认交易链。例如，交易 C 支出交易 B 的找零，交易 B 本身支出交易 A 的找零。

如果您以这种方式创建超过 20 笔未确认交易的链，比特币核心 0.14.0 将（默认情况下）拒绝您在该链上创建的任何新交易。这是因为比特币核心中的其他逻辑不允许将超过 20 笔交易的链加入其内存池，以防止其他人滥用您的节点资源。

在会议期间，至少有两个人针对这个问题开了问题，想知道为什么他们无法创建交易。

或者，比特币核心过去允许用户创建超过 20 笔未确认交易的链，但只是没有中继超过 20 笔的交易或将它们添加到内存池中，直到它们的祖先交易得到确认。这意味着，当您创建第 21 笔交易时，您的钱包会扣除您支出的金额（您的输入），但不会立即将任何找零输出记入您的账户。

例如，如果您使用 10 BTC 的输入支付 0.1 BTC 的输出，您会期望您的余额减少 0.1 BTC，但它反而会减少 10 BTC，直到至少前 20 笔交易中的一笔得到确认。

作为折衷方案，比特币核心 0.14.0 提供了一个命令行选项，允许用户选择他们想要的行为：默认的 20 笔链式交易限制，或者无限链式交易，但余额更新会延迟。

这个问题已经引起了开发人员之间的广泛讨论，在会议中谈到这个问题的开发人员都没有对当前的行为感到满意，但到目前为止还没有人提出能够提供良好的用户体验的解决方案，而无需对代码进行重大修改以处理这种相当罕见的情况。

此外，整个情况因为网络上针对常规钱包交易的交易可塑性持续存在而变得更加复杂。如果祖先交易被篡改，其任何后代交易都将无法在同一个区块链上有效。在这种情况下不会丢失资金，但钱包需要一种方法来了解这些后代交易现在无效，并相应地更新钱包余额。

评论

在试图描述这个问题时，Alex Morcos 说：“很难在 PR 上讨论这个问题”。从聊天过程中产生的困惑来看，似乎在 IRC 上讨论这个问题也很难。

Gregory Maxwell 建议：“这表明我们目前的定义是错误的。它不应该与内存池紧密耦合（例如，软件如何才能被没有内存池的人使用？——这是一个受支持的配置！）。"

Pieter Wuille 回复：“如果你不依赖于内存池，我认为让钱包双重计数并不难”，Wladimir van der Laan 补充说：“所以如果它发送一个交易，而有人篡改了它，并且它会收到被篡改的版本，它会将这个版本双重计数”。

Wuille 还补充说：“不支出未确认找零的钱包没有这个问题”。

讨论暂时偏离到费用加成，然后回到主题，Maxwell 指出：“如果没有可塑性，我认为这些找零处理问题中基本上都不会存在，因为你永远不会遇到可能双重计数你自己的资金的情况。”

结论

经过一个多小时关于这个问题的讨论，Morcos 建议：“好吧，我们偏离主题了。现在——也许可以进入下一个话题，我们在一周后再次审视这个问题，思考一下这两种途径”，所有与会者都热烈地赞同。

账户系统移除状态

背景

到 2010 年底，已经有几个网站提供网页钱包和交易所，这些钱包和交易所基本上只是在比特币软件之上构建的一层薄薄的包装（当时它还没有被称为比特币核心）。在那段时间里，比特币 引入了 一个账户系统，允许单个比特币实例跟踪多个账户的余额。

后来的网页钱包和交易所实现了他们自己的会计后端，而比特币核心的账户系统从那时起基本上不再使用——但它使许多 RPC 调用变得复杂，并且除了运行多用户网页钱包之外，它并没有什么特别的用处。（即将发布的功能，多钱包，将为想要将不同的比特币集合分隔开的用户提供真正的钱包分隔。）

因此，在过去的几个版本中，与账户系统相关的功能都被标记为已弃用，并且要么被移除，要么被转换回账户起源的标签系统。

讨论

Wladimir van der Laan 总结了现状：“这里可以很简短地说明：自上次讨论以来没有进展，因为在考虑弃用账户之前，我们需要先有一个标签 API。”

Matt Corallo 说：“我认为这绝对应该在 0.15 版本中实现”，Wladimir 同意，但他补充说：“我同意，不过对我来说，多钱包的优先级更高。”

随后讨论转向关于多钱包的主题，主要是哪些拉取请求对开发人员在本周进行审查是有用的，包括 PR#9294 和 PR#8694。

结论

审查上面的拉取请求以在多钱包方面取得进展，并致力于为账户系统移除开发标签 API。

修改 make check 测试

背景

比特币核心提供了一个名为 check 的 makefile 目标，它运行项目的单元测试。随着时间的推移，该项目编写了越来越多的通过 RPC 接口执行的集成测试，这些测试由 Travis 持续集成 (CI) 服务器自动运行，该服务器测试每个比特币核心拉取请求，并且可以通过执行 qa/pull-tester/rpc-tests.py 手动运行。

讨论

Jonas Schnelli 问道：“将 RPC 添加到 make check 的好处是什么？”

Wladimir van der Laan 回复：“理想情况下，‘make check’ 应该进行相当快速的检查，一些 RPC 测试被归类为快速检查，但整个套件可能花费的时间过长。”

讨论继续围绕确保 make check 运行得足够快，包括提高在多个 CPU 内核上运行它的能力。

结论

John Newberry 得出结论：“好吧，看起来至少在 make check 中进行一些 RPC 测试并没有什么本质上的反对意见。我会开一个 PR，我们可以在那里继续讨论。”

幽默缓解

<wumpus> gmaxwell: yup. don't know if you saw the clang fsafe-stack
         issue that messes up deterministic signing

<gmaxwell> wumpus: I didn't.

<wumpus> gmaxwell: let me dig it up
         gmaxwell: https://github.com/bitcoin-core/secp256k1/issues/445

<gmaxwell> wumpus: holy fuck!

（上面内容的背景：比特币核心和 libsecp256k1 的测试发现了一个编译器中引入的错误，该错误可能导致严重的问题。）

<gmaxwell> without malleablity basically none of these change handling issues
           would exist, I think.
           as you'd never have a case where you might double count your
           own funds.

<wumpus> unfortunately we're stuck with malleability

<morcos> not if we use flextrans
         (sorry)

<gmaxwell> hah

<jonasschnelli> heh

<wumpus> flextrans, lol

<BlueMatt> trolol

参与者

免责声明

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