2016-06-09 IRC 会议总结

• 本周日志链接
• meetbot 记录的会议纪要

主要议题

• 编译时/内存使用
• 隔离见证更新
• Compactblock 测试

笔记/简短议题

• 比特币核心的功能冻结已计划在下周进行，所有需要合并的功能都应在此之前合并。Cfields 有 2 个他希望合并的 P2P 重构 PR，这些可以在冻结之后完成，因为它们不是新功能。
• 根据上次会议的评论关于软件生命周期页面，Btcdrak 和 David Harding 一直在努力更新该页面，使其更清晰、更具代表性此处以及进一步此处，这需要审查。

编译时/内存使用

背景

问题6658（构建需要 >1GB 内存）和7471（使用 512 MB RAM 构建没有太多空间）讨论了编译时对 RAM 的需求不断增加。

会议评论

Gmaxwell 指出，我们现在无法在仅有 2GB RAM 的主机上使用默认设置进行编译，而我们的文档中写的是 1.5GB。

TheBlueMatt 准备了一个补丁，将所有 mempool 内容移出，这显然可以将其恢复到 1.5GB。不过，他还没有发出拉取请求。

Wumpus 指出，使用Clang 编译通常在相同的编译设置下使用更少的内存。

编译时间可能与内存使用相关，因为磁盘查找/读取访问可以忽略不计。

添加 ARM 和 AARCH64 的二进制构建将减少关于内存问题的投诉。Cfields 正在处理此问题。用户目前可以使用交叉编译，但是 gmaxwell 指出许多使用类似树莓派系统的人没有其他 Linux 主机。

会议结论

Cfields 计划为 0.13 添加没有 GUI 的 ARM 二进制文件（在会议后在 PR #8188 中完成）

隔离见证更新

背景

开发人员正在开发一个软分叉，以将隔离见证引入比特币主网。隔离见证（segwit）允许交易签名数据存储在用于生成交易标识符的哈希数据之外，消除了所有已知的第三方可塑性形式，允许完整节点编译当前的 UTXO 集而无需下载所有签名，并为欺诈证明奠定了基础，从而允许轻量级（SPV）客户端帮助执行更多共识规则。隔离见证软分叉还允许矿工用 4 字节的隔离见证数据替换 1 字节的区块空间，从而增加使用隔离见证的钱包的交易容量。隔离见证 BIP：BIP141、BIP142、BIP143、BIP144 和BIP145

会议评论

在代码（不包括软分叉）进入 0.13 之前，仍然有一些错误需要修复。Sipa 指出所有问题将在下一批补丁中解决。

Luke-jr 希望最大见证程序长度为 75 字节，而不是现在的 40 字节。他认为没有必要限制（低于 75，因为高于 75 需要更多更改和额外测试），并且较小的限制很可能会阻止未来的软分叉。稍后扩展限制将需要硬分叉。Sipa 认为不需要超过 256 位哈希 + 一些版本控制元数据，将其设置为更多将给人留下这样的印象，或者正如 petertodd 详细阐述的那样：会给人留下比特币比那更糟糕的印象。Gmaxwell 插话并认为他看到的最大危害是，允许更大的大小可能会限制将来将 UTXO 条目的大小限制在一定范围内。但是，以后可以进一步限制。他还指出，将来可以通过使用不同的版本类型信号来扩展此功能，但这需要除了当前承诺之外的另一个承诺。

会议结论

讨论仍在继续，并推迟到会后进行。

Compactblock 测试

背景

BIP152：“紧凑区块中继”是 BlueMatt 提出的一个建议，用于通过对应该在节点的 mempool 中的交易使用短交易 ID 来减少区块中继期间使用的带宽。作为副作用，这也导致减少了区块传输延迟。

会议评论

公共网络上有一些节点运行着 compactblocks，并且一切似乎都运行良好。Instagibbs 制作了一个图表。Gmaxwell 一直在使用修改后的版本运行测试，该版本将哈希大小减少到 16 位，以通过使它们更常见来测试围绕冲突的罕见极端情况。两个大型矿池一直在运行它，其中一个位于中国防火长城之后。

Cfields 想知道是否有人讨论过紧凑区块的服务位。之前提出的论点是，服务位应该仅用于关键必需的服务。由于它很可能足够普遍，因此很快就不需要了。只有矿工真正需要它，但他们无论如何都应该手动管理他们的连接。

会议结论

• 与区块获取逻辑的交互需要更多审查。
• 审查者应停止使用 sipa 的分支，因为 PR #8068 已重新基于共享指针工作。
• 审查 PR #8084（将最近接受的区块和交易添加到 AttemptToEvictConnection）

轻松一刻

wumpus       #link https://github.com/bitcoin/bitcoin/issues/7471
cfields_     wumpus: thanks
wumpus       eeh that's the wrong one
gmaxwell     wumpus: unthanks

Lightsword   maybe we should just have a service bit for flagging fast relay nodes/miners in general for preferential peering rather than making it flag compact blocks specifically
sipa         Lightsword: we should also have an evil bit that abusive nodes should set

参与者

免责声明

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