本周的 Newsletter 总结了 CoreDev.tech 活动的会议，描述了一项对 BIP125 RBF（Replace-By-Fee）的修订提议，链接了 Optech 有关 Schnorr/Taproot 的高管简报视频，并简短庆祝了 Optech Newsletter 发布的第 50 期。此外，还包括我们常规的 bech32 发送支持部分以及对流行的比特币基础设施项目的值得注意的变更。

行动项

本周无行动项。

新闻

  • ● Bitcoin Core 贡献者会议： 上周，许多贡献者亲自参加了定期举行的 CoreDev.tech 活动，贡献者 Bryan Bishop 提供了实时会议记录：

    • ● 6月5日：在一次代码审查会议中，讨论了发给活跃的 Bitcoin Core 贡献者的调查，并提出了几项简化审查流程的建议。

      参与者讨论了将钱包架构更改为使用输出脚本描述符来生成地址、跟踪付款时间以及查找或推导出用于支付的特定私钥。

    • ● 6月6日：讨论了共识清理软分叉，包括它与 bip-taproot 的交互，是否应该删除部分内容，以及是否应该添加任何内容。(更多背景信息)

      小组讨论了如何使维护者的工作更轻松。除了其他考虑因素外，维护者提到他们非常感谢长期贡献者 Michael Ford 所提供的问题和 PR 管理服务。会议参与者对此的回应是授予 Ford 维护者身份，使他能更有效地工作。

      讨论了潜在的脚本更改。讨论围绕 BIP118 和 bip-anyprevout 的签名哈希展开，涉及输出标记（参见 Newsletter #34) 和监护签名（#47）。同时还审查了更名后的 bip-coshv 操作码（参见 #48），并考虑了 OP_CHECKSIGFROMSTACK 作为一个通用替代方案。

      Taproot 议题包括讨论使用默克尔树而非累加器，以及与快速量子计算机相关的风险。(更多背景信息)

      在关于 Utreexo 累加器的问答环节中，讨论了 UTXO 集的存储要求最小化的这个新兴提案的一些有趣细节。

    • ● 6月7日：演示并讨论了 assumeutxo 提案的代码，包括如何使该提案与其他想法兼容。(更多背景信息)

      贡献者讨论了将硬件钱包支持通过 HWI 直接集成到 Bitcoin Core 中。一个特别关注点是代码的分离——确保特定硬件设备的代码由制造商维护而非 Bitcoin Core。(更多背景信息)

      讨论了版本 2 P2P 传输协议及相关的对签名协议（参见 #27）。讨论中提到了几种可能的增强。(更多背景信息)

      对 signet 这一类似测试网的链的审查中，重点讨论了分发签名的各种方法。(更多背景信息)

      尽管本周才在 Bitcoin-Dev 邮件列表中宣布，盲状态链也在会议上进行了讨论。

  • ● 建议覆盖某些 BIP125 RBF 条件： BIP125 选择性 Replace-By-Fee (RBF) 仅允许以更高费率的替代交易来替换一笔交易，如果替代交易增加了整个内存池中支付的总交易费。这阻止了一种廉价的带宽浪费的拒绝服务（DoS）攻击，但却可能导致对某些 RBF 用例的相对廉价的交易固定 DoS 攻击，例如在时间敏感的协议如闪电网络 (LN) 中。

    之前已经有几位开发者尝试解决这个难题，去年年底 Matt Corallo 提出了一个可能的解决方案，即使用 CPFP 费用提升（CPFP carve out，参见 Newsletter #24），并建议通过调整 RBF 来作为替代解决方案。Rusty Russell 之前与 Corallo 讨论 了这一 RBF 更改，并进一步完善了它，现在他已将其作为对 BIP125 规则集新增的单一规则提议给 Bitcoin-Dev 邮件列表。新规则允许内存池中的任何 BIP125 可替换交易在满足两个条件时进行费用提升：

    1. 当前在内存池中的版本低于前 1,000,000 个最具利润的 vbytes（即下一个区块区域）

    2. 替代版本支付的费用足够高，可以进入下一个区块区域

    这将允许任何交易无需考虑其子交易即可进行费用提升，从而消除交易固定问题。然而，使用此规则的任何人都可能减少内存池中的总费用，并可能利用它过度浪费节点带宽。几位人士回复了该提议，提出了这些风险的相关问题并进行了分析。

  • ● 演讲：下一个软分叉： Bitcoin Optech 贡献者 Steve Lee 在上个月的 Optech 高管简报中进行了关于未来比特币软分叉的演讲。该视频现已上线。在他的演讲中，Lee 描述了软分叉从构想到提案再到实施和激活的各个阶段。利用这一框架，他识别了 Schnorr/Taproot 软分叉（参见 Newsletter #46）、共识清理软分叉（#36）和 noinput 软分叉提案（BIP118 和 bip-anyprevout，参见 #47）的当前状态。尽管在演讲后期，他概述了共识清理软分叉（修复协议中的几个非紧急问题）和 noinput 提案（为合同协议如闪电网络的 Eltoo 层启用新功能），但他的演讲——以及本文对其的总结——主要集中在 bip-schnorr、bip-taproot 和 bip-tapscript 的组合提案上。

    在提供了关于 Schnorr 签名和签名聚合的高层次概述后——这些信息可能已经为本 Newsletter 的读者所熟悉——Lee 的演讲很大一部分围绕着 2-of-3 多重签名安全性展开，这是今天许多企业使用的一项功能。他首先描述了阈值密钥为用户带来的节省，即聚合公钥仅需要原始各方的子集即可创建有效签名，例如由三个单独密钥创建的聚合密钥，其中任意两名参与者可以对 2-of-3 多重签名安全性进行签名。这种方法的优点是链上最大效率和隐私，但缺点是创建公钥和签名时需要互动，并且密钥持有者无法使用区块链数据进行审计以确定实际参与签名的子集。

    为了解决公钥互动性和签名审计问题，Lee 使用了一系列易于理解的插图幻灯片，展示了使用 Taproot 的密钥路径和脚本路径支出组合来实现的一种替代构造。创建了三个 MuSig 风格的 2-of-2 聚合公钥——每个公钥对应于 2-of-3 多重签名中可能的三个签名者组合之一。由于这是 MuSig n-of-n 密钥聚合，它不需要互动。最可能的组合（例如热钱包密钥和第三方安全密钥）可以通过 Taproot 密钥路径支出，使得输出可以使用单个聚合签名进行支出，看起来像任何单一签名支出。两个替代选项（例如每个涉及一个冷备份密钥）被放置在一个 MAST 树中以进行脚本路径支出。这虽然不如密钥路径支出隐私性高或成本低，但提供了冗余性。对于这些选项中的任何一个，任何查看区块链数据的第三方只能看到一个签名，并且没有关于参与方数量的直接信息，但每个三个密钥持有者都知道哪些参与者的公钥被用于创建与支出签名匹配的特定聚合密钥，从而使他们能够进行私密审计。Lee 在总结这一部分演讲时，展示了 Schnorr 和 Taproot 对当前多重签名支出者的明确总体好处及其权衡。

    除了增强当前比特币的使用外，还描述了一些目前不太可行但在 Schnorr 风格签名和 MAST 风格脚本树变得可用后将变得可行的新功能。Lee 在演讲的最后提供了一个粗略的、带有很大不确定性的时间表，介绍了这些变更可能会在何时实现。

  • ● Optech 庆祝 Newsletter #50： 去年六月初，John Newbery 给 Dave Harding 发送了一封关于新成立的 Optech 组织计划的电子邮件，其中包括一句话：“我们还将制作一些书面材料[如]每周或每月的新闻摘要。” 那天有点无聊的 Harding 回信时附上了一份未请求的概念验证 Newsletter. Newbery 和其他早期的 Optech 贡献者对此很满意，于是他们商定了一些细节，Newsletter 的定期每周出版由此开始。

    五十期之后，Newsletter 现在已有超过 2,500 名电子邮件订阅者，此外还有通过 RSS、Twitter 和 Max Hillebrand 的阅读 订阅的未知数量的额外订阅者。我们总共发布了超过 85,000 字——大约 250 页的内容，并且 Newsletter 草稿版迄今已经从一个了不起的审阅团队那里收到了 948 条评论，他们帮助确保技术的准确性和可读性。新 Newsletter 的公告累计获得了超过 1,300 次转发和 3,000 次点赞，此外还有在 Reddit 上的许多点赞。最重要的是，我们直接听到许多读者表示他们认为 Newsletter 特别有用。

    我们感到惊讶、感激和谦卑，一个纯粹专注于比特币的技术 Newsletter 在其第一年出版中获得了如此惊人的反响。我们知道大家对我们未来的期望很高，希望我们能在接下来的五十期中不负众望。正如往常一样，我们感谢我们的创始赞助商、会员公司、所有为 Newsletter 做出贡献的人以及所有为比特币开发做出贡献的人——没有你们，我们将不得不写一些远没有未来货币那么令人兴奋的东西。

Bech32 发送支持

在 bech32 系列 中，第 13 周的内容介绍了让你支付的对象能够获得 segwit 所有好处的方法。

Bech32 地址并不是比特币用户第一次改变地址格式。在 2012 年 4 月，P2SH 地址（以 3 开头）被引入，并最终在大约 25% 的交易输出中得到使用。本周，我们将查看这两种不同地址格式的相对采用速度。由于我们稍后将描述的原因，这不能算作一个完全公平的比较，但它可以为我们提供一个大致的指导，看看我们在 Bech32 采用方面迄今为止的表现如何。

我们首先来看一下从每个提案在主网激活的那一天起，发送到 P2SH 或原生 Segwit（Bech32）地址的每个区块的输出百分比。本节中的所有图表均以 30 天的简单移动平均值计算。我们还将 P2SH 图表中的数据点限制在 Segwit 激活前约两个月，以便几乎没有 P2SH 包裹的 Segwit 输出被误算为传统 P2SH。

P2SH 采用速度与原生 Segwit 的比较。Segwit 线是 P2WPKH 和 P2WSH 的总和

上图中有一个特别不公平的方面是，P2SH 主要对高级脚本（如多重签名）有用。对于使用单签名地址（以 1 开头）的人来说，没有必要也没有好处升级到 P2SH。相比之下，原生 Segwit 地址既有针对单签名用户的（P2WPKH），也有针对高级脚本用户的（P2WSH）。为了使这种比较更加公平，下图在较小的日期范围内将原生 Segwit 的两种用途分开，这样您可以将 Bech32 P2WSH 的使用与其大致相当的 P2SH 进行比较。

P2SH 采用速度与原生 Segwit 的比较。分别展示 P2WPKH 和 P2WSH 的数据

值得注意的是，到目前为止，几乎所有原生 Segwit 地址的使用都集中在单签名的 P2WPKH 上。Segwit 激活前的 P2SH 活动曾达到所有输出的 25% 的峰值，但这些活动并没有迁移到原生 P2WSH 输出。事实上，当我们考虑到所有闪电网络（LN）的存款交易（以及至少一些其他链上 LN 交易）都在使用原生 P2WSH 输出时，似乎几乎没有 2017 年末的 P2SH 活动转移到 P2WSH。

这也指出了使不同地址数据难以比较的另一个方面：使用传统 P2SH 所能实现的所有功能，也都可以使用 P2SH 包裹的 Segwit 地址或原生 P2WSH 地址来实现。P2SH 包裹的 Segwit 地址具有向后兼容性，并且可以显著减少交易费用，而 Bech32 地址与旧钱包不兼容，与 P2SH 包裹的 Segwit 相比，仅能节省一小部分固定的额外费用。这可能使高级脚本用户在短期内没有足够的动力从 P2SH 包裹的 Segwit 地址切换到原生 Segwit 地址。

总体来看，图表似乎表明 P2SH 地址花了大约三年的时间才真正开始普及，而 Bech32 地址在 Segwit 软分叉激活后仅几个月内就已经取得了成功。随着一些钱包已经默认采用 Bech32，更多钱包计划在未来几个月内也将如此，我们预计在 2019 年底前会看到采用率的进一步提高。

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

本周在 Bitcoin Core、LND、C-Lightning、Eclair、libsecp256k1 和比特币改进提案 (BIPs)中的值得注意的变更。

  • ● LND #2802 允许 LND 计算特定路径成功的概率。然后它结合现有的路径总费用和最大 HTLC 超时时间的计算，使用该概率选择最佳路径。增加了几项新的配置选项，允许用户调整概率计算中使用的常量值，例如“当没有其他信息可用时，假定路径中某跳的成功概率”。拉取请求的作者还在上周末的 Breaking Bitcoin 会议上讨论了路由成功概率。

  • ● C-Lightning #2644 改变了 C-Lightning 如何跟踪其向对等节点传递的通道更新。此前，为每个对等节点保留了一个映射，跟踪哪些更新已发送，哪些正在等待发送。现在，整个程序保留一个有序的更新列表，每个对等连接只需跟踪它在该列表中发送到哪个位置。当连接到达列表末尾时，其位置会被标记，以便可以发送随后添加到列表中的任何新条目。当后续更新使之前的更新变得无关紧要时，之前的更新会从全局列表中删除，任何未发送该更新的连接将永远不会看到它。在测试中（可能是作为百万通道项目的一部分），这将整体内存使用量减少了 35%（约 150 MB），并加快了向所有对等节点发送所有 gossip 公告的速度 62%（约 11 秒）。