本周的 Newsletter 包括了我们常规的几部分内容，描述了如何为 Taproot 做准备，总结了最新的发布与候选发布，并列出了受欢迎的比特币基础设施项目中的值得注意的变更。

新闻

本周没有重大新闻。

准备 Taproot #7：多签

每周连载的系列，介绍开发者和服务提供者如何为即将激活的 Taproot 做准备，激活将在区块高度 709,632 时发生。

在撰写本文之前的 1,000 个区块中，11% 的交易输入包含了多签操作码。如果许多创建这些交易的用户和服务将多签操作码切换为无脚本的多签，Taproot 的两个最大和最直接的好处将会显现。

第一个主要好处是交易大小的减少。基于脚本的多签随着更多密钥和签名的需求而增大，但多签则保持为一个恒定的小尺寸。最小的有效多签策略（1-对-2）所需的空间比一个可以涉及成千上万签署者的多签策略还要大。尺寸的减少直接导致了多签用户的手续费减少，同时也间接减少了所有用户的手续费，因为相同数量的已确认交易需求可以通过更小的区块空间得到满足。

展示多签与多签操作码节省的图表

第二个主要好处是隐私的提高。每次使用多签的交易都会在区块链上有明显的记录，观察者可以通过这些记录推测出个别用户的钱包历史和当前余额。例如，在区块 692,039 中，我们不仅可以区分多签交易和单签名交易，还可以区分不同的签名集合大小和多签的阈值。

展示当前区块中见证不可替代性的插图

相比之下，第三方仅查看区块链数据时，无法知道支出者是否使用了多签。当多签用于密钥路径支出时，它与单签名支出无法区分。如果上述区块中的所有单签名和多签都切换为 P2TR 密钥路径支出，只有少数特殊的支出会因其脚本而被区分出来（即便是这些支出，也可能在最好的情况下使用密钥路径支出）。

展示理想情况下可替代的见证如何呈现的插图

使用多签

我们知道有三种专为比特币设计的基于 Schnorr 的多签方案，它们都是 MuSig 系列的一部分：

  • MuSig（也称为 MuSig1），实现起来相对简单，但在签名过程中需要三轮通信。

  • MuSig2，同样实现起来较为简单。它消除了一个通信轮次，并将另一个通信轮次与密钥交换结合。这样可以使用与当前基于脚本的多签类似的签名过程。这确实需要存储额外数据，并且非常小心，确保你的签名软件或硬件不会被误导重复进行某部分签名会话。我们将在下周的 为 Taproot 做准备 栏目中更详细地探讨这种权衡。

  • MuSig-DN（确定性随机数），实现起来复杂得多。参与者之间的通信无法与密钥交换结合，但它的优势在于不会受到重复会话攻击的影响。

所有签名者必须就使用哪种协议达成一致，因此可能会出现网络效应，许多实现选择使用相同的协议。MuSig 提案的作者 建议 由于其相对简单性和高效性，MuSig2 将成为大多数实现的选择。

目前有一个开放的并正在积极开发的 PR，用于向 libsecp256k1-zkp 项目添加 MuSig2 支持。我们预计大多数软件的基本多签工作流将如下所示：

  1. 每个参与者的钱包生成一个 BIP32 xpub，并通过输出脚本描述符或其他方式与所有其他参与者共享（这与当前多签使用的方式相同）。

  2. 任何一个钱包都可以通过将其在某个 BIP32 深度上的公钥与所有其他钱包在同一深度的公钥相结合，生成一个聚合公钥。这个聚合公钥可以用于接收 P2TR 支付。

  3. 当其中一个钱包想要支出资金时，它使用基于 PSBT 的工作流，类似于当前使用基于脚本的多签的流程，但现在需要签署者之间进行两轮通信。在第一轮中，提议者创建未签名交易并包含一对随机生成的随机数。必须确保随机数的生成不是完全确定性的，以避免为不同的签名使用相同的随机数。提议者将包含随机数的 PSBT 发送给其他钱包。

  4. 其他钱包接收 PSBT 并更新其中的随机数，然后将更新后的 PSBT 发送给其他钱包，或发送给为钱包提供信任的协调员。

  5. 当所有钱包都获得所有随机数对后，它们将它们合并为一个单一的随机数。协调员也可以为它们执行此操作。然后，所有钱包更新它们的 PSBT 版本并添加各自的部分签名，将 PSBT 发送给其他钱包或协调员。最后，所有部分签名将合并生成最终签名，并将交易广播。

阈值签名

仅凭 MuSig 系列的多签方案，你只能实现 n 对 n 的签名——每个贡献密钥的参与者必须也贡献一个部分签名以形成最终签名。这在一些当前使用的基于脚本的多签用例中运行良好，例如支出 2-对-2 的闪电网络资金输出，但它与其他流行的策略有所不同，例如许多交易所使用的 2-对-3 多签脚本。

目前，几位开发者正在研究阈值签名方案，它将为 k-对-n 场景带来与多签相同的效率和隐私好处，但在这些方案可用之前，有一个简单的技巧可以使用。

在许多阈值情况下，事先知道哪些参与者最有可能签名。例如，在一个 2-对-3 的场景中，可能已经知道通常 Alice 和 Bob 会共同签名，而 Carol 只有在其他两人都无法签名时才会签名。对于这种情况，主密钥可以使用多签进行 Taproot 密钥路径支出（例如 Alice 和 Bob 之间），而额外的结果（如 Alice 和 Carol，或 Bob 和 Carol）可以使用 OP_CHECKSIG 操作码在 tapscripts 的树状结构中单独分支。

在正常情况下，以上方案与单签名或多签交易具有相同的效率和隐私。在异常情况下，支出仍然按预期工作，并且比在链上发布多签参数更高效和隐私。

尽管希望最小化费用并实现最大隐私的用户最终可能会切换到纯阈值签名方案，但上述方案可能仍会继续使用，因为它为审计员（如果他们知道所有参与者的公钥）提供了关于哪些相应的私钥被用来签名的链上证明。

编辑：关于 MuSig2 的部分文字已更新，以澄清在预共享随机数时需要格外小心，因此预计大多数使用 MuSig2 的常规钱包将在需要时生成新的随机数。我们感谢 #secp256k1 IRC 频道成员分享他们的担忧。

发布与候选发布

受欢迎的比特币基础设施项目的新发布与候选发布。请考虑升级到新版本或协助测试候选发布。

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

本周在 Bitcoin Core、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、硬件钱包接口 (HWI)、Rust Bitcoin、BTCPay Server、比特币改进提案（BIPs）和闪电网络规范（BOLTs）中的值得注意的变更。

  • ● Bitcoin Core #22006 增加了 文档，说明了用户空间、静态定义追踪（USDT）及其前三个追踪点 - 这些功能的构建支持和宏在 Bitcoin Core #19866 中进行了添加。启用 eBPF 追踪的用户可以通过提供的示例脚本或编写自己的追踪脚本，轻松连接到追踪点，从而更好地观察节点在连接新块、接收入站 P2P 消息和发送出站 P2P 消息时的表现。文档中还包括了使用示例和新追踪点添加的指南。

  • ● Eclair #1893 允许分别配置未宣布通道、已宣布通道以及蹦床支付中继的最低手续费。本次 PR 还为未宣布通道设置了 0.01% 的默认中继手续费，相较于已宣布通道的 0.02%。

  • ● Rust-Lightning #967 增加了通过 send_spontaneous_payment 函数调用来进行 keysend 风格的自发支付的支持。此变更使得我们所覆盖的所有四种 LN 实现都支持 keysend。

    作者还提交了相应的文档（尚未合并），这份文档讲解了作为 BLIP（比特币闪电网络改进提案）的一部分，如何文档化 keysend 支付功能和最佳实践，BLIP 是一种用于记录不属于 LN BOLTs 规范的一部分的功能和最佳实践的提案方式。