2017-03-23 IRC 会议摘要

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

主要议题

• Segwit 地址提案
• 钱包中的 DER 私钥
• 反对二进制发布的声明
• 被阻止和需要审查的 PR

Segwit 地址提案

背景

Pieter Wuille 和 Gregory Maxwell 最近提出了一种用于原生隔离见证 (segwit) scriptPubKey 的地址格式。

对话

Gregory Maxwell 启动了对话，“我们可能在从太多人那里获得 1:1 评论方面犯了一个策略错误，导致列表上的评论很少。即使只是‘我之前审查过，LGTM [看起来不错]’，列表上的评论也很好。”

Peter Todd 建议，“顺着这个思路，我认为将其中一些 1:1 评论公开可能对有兴趣了解这些流程如何运作的新开发者有所帮助。”

在讨论针对 QR 码编码进行优化的过程中，Jonas Schnelli 提到，“为 QR 码设计额外的二进制地址标准可能不值得。也许它们只是临时的？3-4 年后就消失了？”

Maxwell 回复说，“我认为这可能不值得，但行业反馈会很好。”

Wuille 补充道，“[QR 码] 的字母数字模式非常有效；与二进制相比，额外增加了 10%。它使用每个字符 5.5 位，因此 5 位数据的 5.5 位相当不错。”

然后 Schnelli 问道，“Bech32 编码也可以用于私钥（== 32 位种子）吗？”

Wuille 回复说，“好问题！我们一直在考虑为私钥设计更强大的校验和，可能是 12 个校验和字符（这是使用 64 位算术所能达到的最大值）。对于地址，您真正关心的只是 [错误] 检测，但对于私钥，您需要 [错误] 校正。使用 12 个字符的校验和，校正 3 个错误非常简单，但也许我们可以找到一个可以校正 4 个错误的校验和。”

Maxwell 补充道，“找到一个可以校正 4 个错误的 12 位代码可能需要比我们这里仅有的 100 个内核更多的计算能力，尽管 [Wuille] 已经做了很多工作，将这项搜索从完全棘手变成了可行。:) 我认为这项工作优先级要低得多，我们可以做其他事情（例如 utxo 数据库重构和交易压缩）”

在讨论接近尾声时，Maxwell 简要地谈到了 bech32 编码在防止资金发送到错误地址方面的有效性，“如果用户的错误率低于每个输入地址 3.53 个错误，则此代码的保护效果比 32 位哈希 (如 base58 校验所用) 更好。并且由于大小写区分，用户使用此格式犯错的可能性要低得多。如果用户不太可能犯错，则此方案的有效保护趋于无穷大。例如，每个字符 0.1% 的错误几率，并且错误字符串未被检测到的概率为 1:2⁶⁰ [0.0000000000000000867%]。”

结论

会议中一些尚未审查（或完成审查）该提案的人将对其进行审查，并且鼓励所有已经审查过该提案的人在邮件列表中分享他们的评估。

鼓励任何阅读这些会议记录的钱包作者或其他比特币开发者审查该提案，让他们知道他们是否暂时支持它，或者让他们知道他们对此有任何问题。

钱包中的 DER 私钥

背景

Gregory Maxwell 描述了当前的情况：“DER 私钥格式包含公钥，以及所有 ECC 组参数和其他开销，所有这些都打包在数百字节的 ASN1 解析地狱中。” 并且这是对比特币钱包中的每个私钥执行的，即使所有比特币私钥都使用相同的参数，并且比特币核心已经知道这些参数。

从 Bitcoin Core 0.13.0 开始，Bitcoin Core 的默认设置创建的所有新钱包都使用BIP32分层确定性 (HD) 钱包。仍然支持使用单独随机生成的密钥的旧式钱包，以及使用importprivkey RPC 导入密钥的钱包。

讨论

没有人反对更改钱包格式以存储密钥或 HD 种子而不使用 DER。大多数讨论都集中在如何管理此更改和其他类似的钱包更改，特别是确保它们易于测试，但钱包格式每个版本最多只更改一次。

结论

没有明确的结论。在谈话接近尾声时，讨论集中在使用特殊标志来表示待处理的功能；例如，Maxwell 写道，“我不在乎我们是否保留对某个用户通过运行 bitcoind 并使用--force-wallet-screw-me-over-now-now-now创建的钱包的兼容性”。

此类标志允许单独的功能进行测试和合并，但不会默认激活，直到特定版本打算的所有功能都已合并。

反对二进制发布的声明

背景

在会议开始前几天，比特币核心项目的某个分支为他们声称的安全原因发布了仅二进制版本。

讨论

Gregory Maxwell 询问开发人员是否愿意签署一份关于比特币核心承诺绝不发布没有源代码的二进制文件的声明。声明开头是：

比特币项目永远不会要求用户运行二进制文件而不提供源代码。如果它真的这样做，您可以安全地假设项目的实际贡献者被锁在某个地下室里。在这种情况下，请发送帮助。

Bryan Bishop 建议人们不仅要发送帮助，还要发送食物。

还有其他一些完善声明的建议，但没有人反对该声明。

结论

没有明确的结论。Maxwell 可能将继续完善声明并收集签名。

被阻止和需要审查的 PR

背景

Matt Corallo 建议，“每周呼吁‘您在什么 [拉取请求 (PR)] 上遇到障碍并希望进行审查’，尽管我之前这样做时效果参差不齐。”

讨论

• Corallo 要求#9725：CValidationInterface 清理

• Wladimir van der Laan 和 Jonas Schnelli 要求#9294：为找零输出使用内部 HD 链（hd 分割）

• Gregory Maxwell 要求#9959：挖矿：防止在大型内存池中 CreateNewBlock 速度变慢

还讨论了使用 GitHub 项目看板或标签来跟踪审查请求。

结论

鼓励审查者专注于上述 PR。会议中没有就使用项目看板或标签来进行审查请求做出决定。

轻松一刻

<wumpus> proposed topics?

<btcdrak> holiday at the beach?

<petertodd> btcdrak: that's what the financial crypto conference is for

<kanzure> rationale section was good, although i think it would be worthwhile to
          describe the 'exhaustive search'

<gmaxwell> kanzure: we left out a lot of technical minutia about the construction
           which is interesting but not really relevant to the spec.

<sipa> earlier version explained finite field arithmetic and generator polynomials :)

参与者

免责声明

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