2017-05-11 IRC 会议纪要

笔记 / 简短主题

Sipa 和 Gmaxwell 一直在研究一项提案，该提案以每输入和输出几微秒的成本，始终维护 UTXO 承诺哈希。这将有助于使 gettxoutsetinfo 瞬间完成，或从其他人的 UTXO 集同步，或作为以后软分叉的基础。有三种实现方法，每种方法在性能和安全方面都有不同的权衡。会议几天后，邮件列表帖子对不同的方法和选项进行了说明。

从 Bitcoin Core v0.8 开始，我们对链状态数据库及其缓存使用了每个交易模型。这意味着数据库实际上是从交易 ID 到该交易未花费输出列表的映射。PR #10195 将其更改为从输出点（(交易 ID、索引) 对）到该输出点的单个未花费输出的映射。

最初每个交易聚合输出的原因是为了节省空间：这样，我们可以避免在多个输出中重复交易 ID 和交易元数据。但是，LevelDB 在内部使用一种编码，该编码会省略键中重复的前缀字节，因此重复交易 ID 并不重要。

使用每个交易输出模型有很多优势

缺点

测试结果非常有希望，如此图表所示。Sipa 指出，在测试中，链状态从 2.2GB 变为 2.7GB。

Gmaxwell 认为应该尽快合并它以在主分支中进行更多测试，但它需要更多测试/审查。BlueMatt 审查了一半，cfields 完成了审查，但没有足够的信心确认它。

仍然需要进行一些代码清理，并为升级过程提供更好的用户界面，因为在启动时，从旧数据库到新数据库有一个一次性升级，这需要几分钟时间。

币选择是确定如何花费钱包中硬币的算法。应该使用哪些硬币来资助交易。这是在不创建非标准交易（通过超过一定大小或创建零散输出）之间取得平衡，尝试找到低费用配置，尽可能地为用户提供隐私，并缩小整体 UTXO 集大小。

多年来已经进行了许多改进，但仍然存在问题，这些问题偶尔会出现。Instagibbs 正在努力更改费用目标算法，以考虑所考虑输入的“有效值”，而不是简单地尝试达到绝对费用，看看它是否失败，然后在循环结束时尝试使用估计的总费用。

在没有清理零散输出的策略的情况下，Gmaxwell 对这些更改感到有些不安，他担心存在潜在的意外 UTXO 计数激增。

随着谈话更多地转向费用目标和币选择的总体方法，Morcos 提出了“费用智能”的想法，其中在费用较低时可以包含更多输入。

Wumpus 喜欢在低费率期间清理负值 UTXO 的想法，但补充说，如果这些 UTXO 最初没有创建会更好。Morcos 提到了他的 PR #9343，该 PR 试图做到这一点。

Bitcoin Core 的设计目标是永远不要创建小于 0.01BTC 的找零输出，除非钱包在交易中几乎被耗尽，但这个目标根本没有实现。

向前迈出的一个好步骤也将是从 wallet.cpp 中分解和模块化币选择。

Instagibbs 希望添加 PR #10333，该 PR 修复了用户报告的一些费用问题，但比币选择大修不那么极端。

对多钱包有一些审查意见，但是 PR 正在等待 PR #9494，该 PR 已于上周添加到高优先级审查中。

Jonasschnelli 希望添加 PR #10240（HD 钱包自动恢复功能），该功能应包含在 0.15 中。

此摘要是在未征求讨论中任何参与者意见的情况下编制的，因此任何错误都是摘要作者的过错，而不是讨论参与者的过错。