本周的 Newsletter 简要描述了 Bitcoin-Dev 邮件列表中的两次讨论,一次是关于 Bitcoin vaults 的,另一次是关于减少 taproot 中使用的公钥大小的。此外,还包括我们常规的 bech32 发送支持部分和流行比特币基础设施项目的值得注意的变更。

行动项

  • Optech schnorr/taproot 研讨会 Optech 将于 9 月 24 日在旧金山和 9 月 27 日在纽约举办关于 schnorr 签名和 taproot 的研讨会。工程师们将学习这些技术及其如何应用于自己的产品和服务,构建 schnorr 和 taproot 钱包实现,并有机会参与对这些比特币协议提案的反馈过程。

    成员公司应发送邮件给我们为您的工程师预留席位。

新闻

  • 无需契约的 Bitcoin vaults:帖子中,Bryan Bishop 向 Bitcoin-Dev 邮件列表描述了如何使用预签名交易支付到使用 OP_CHECKSEQUENCEVERIFY (CSV) 的脚本,使用户能够检测并阻止窃贼通过获取用户私钥而试图窃取资金的行为,这种能力此前被称为提供 Bitcoin vaults。Bishop 在详细描述了基础协议和几个可能的变体后,发布了第二个帖子,描述了一种仍然可以从 vaults 中窃取资金的情况,尽管他也提出了一种部分缓解方案,可以将损失限制在被保护资金的一部分,并请求对比特币共识规则进行最小必要改动的提案,以完全缓解此风险。

  • 对 schnorr 公钥的提议更改: Pieter Wuille 在 Bitcoin-Dev 邮件列表上发起了一个讨论,请求对将 bip-schnorrbip-taproot 公钥从之前提议的 33 字节压缩公钥切换为 32 字节公钥的提案进行反馈。压缩公钥包含一个位,用于指示验证者 Y 坐标是偶数还是奇数。结合某种算法,验证者可以从包含在压缩公钥中的 32 字节 X 坐标推导出完整公钥的两个可能的 Y 坐标,其中一个是奇数,另一个是偶数,因此该位可以帮助验证者选择正确的坐标,避免在验证时尝试两种组合(这会降低验证速度,并消除批量签名验证的任何优势)。已经提出了几种 数学 方案,这些方案可以为那些 Y 坐标可以无需额外位推导的密钥生成签名(当前该位是前缀字节中唯一包含的数据)。这可以为每次支付到 taproot 输出节省 1 个 vbyte(如果大多数用户迁移到 taproot,每个区块可能节省数千个 vbyte),并为每个在脚本路径支出中包含的公钥节省 0.25 个 vbyte。有关 32 字节公钥的先前讨论,请参见 Newsletter #48

Bech32 发送支持

这是一个关于允许您支付对象访问 segwit 所有好处的系列中的第 22 周内容。

我们经常提到使用 segwit 输入可以节省手续费,但从未提到您不必利用这些节省。如果您愿意,您可以支付与未使用 segwit 时相同的费用,从而在其他条件相同的情况下让您的交易更快得到确认。对于某些用户,例如试图在交易所间进行套利的交易员来说,省钱可能没有以相同费用更快确认交易来得重要。

为了研究这一想法,让我们首先生成一个使用 Bitcoin Core 手续费估算工具的图表,展示创建典型单签名、单输入、双输出交易时的潜在手续费节省:

按预估手续费以美元计费,Y=手续费,X=确认目标

我们看到,通常来说,支付的费用越少,交易的确认时间就越长——但 segwit 用户可以常常为相同的等待时间支付更少的手续费。现在让我们简单地重新排列这些数据的坐标轴:

按预估手续费以美元计费,Y=确认目标,X=手续费

对于相同的手续费,预计 segwit 用户有时会比传统用户等待更短的确认时间,其中原生 segwit 用户获得的优势最大。在这些估算中,为相同总手续费支付的不同交易类型的确认速度差异可能超过 6 个区块(平均大约一个小时)。

对于那些每笔交易愿意支付的手续费有固定上限的用户和组织来说,使用 segwit 可以显著减少其交易在高活动期间的确认时间。尽管这一优势仅惠及使用 bech32 和其他 segwit 地址支付的人,但这是另一个预计用户和组织将在不久的将来越来越多地要求您的软件和服务支付 bech32 地址的理由。

值得注意的代码和文档变更

本周在 Bitcoin CoreLNDC-LightningEclairlibsecp256k1比特币改进提案(BIPs)闪电网络规范中的值得注意的变更。

  • C-Lightning #2858 限制每个方向的最大待处理 HTLC 数量为 30(从 LN 规范允许的最大 483 降低),并通过 --max-concurrent-htlcs 选项使该值可配置。待处理 HTLC 数量越少,单边关闭交易的字节大小和费用成本就越小,因为结算每个 HTLC 会产生一个单独的输出,该输出只能由相对较大的输入来支出。