本周的 Newsletter 描述了一组用于输出脚本描述符的比特币改进提案（BIPs），总结了一个关于为闪电网络协议扩展和应用互操作性创建标准文档集的提案，并讨论了对预先信任的零确认通道开启进行标准化支持。还包括我们常规的部分，介绍了如何为 taproot 做准备、发布与候选发布，以及对常用比特币基础设施项目的值得注意的更改。

新闻

  • ● 关于输出脚本描述符的比特币改进提案（BIPs）： Andrew Chow 发布 到 Bitcoin-Dev 邮件列表，提出了一组提案 BIPs，用于对输出脚本描述符进行标准化。一个核心 BIP 提供了描述符所用到的一般语义和主要元素。另有六个 BIP 描述了扩展函数，例如 pkh()、wpkh() 和 tr()，它们使用传入参数填充脚本模板。多个 BIP 的方式允许开发者自行选择想要实现的描述符功能，例如较新的钱包可能永远不会实现传统的 pkh() 描述符。

    描述符最初是在 Bitcoin Core 中实现的，过去一年里被更多项目采用。随着钱包开始探索 taproot 所带来的灵活性，以及类似 miniscript 这样的工具简化使用灵活脚本的能力，它们有望在未来被大幅使用。

  • ● BLIPs： Ryan Gentry 发起了一个针对闪电网络开发者邮件列表的提案，提出建立一系列 Bitcoin Lightning Improvement Proposals（BLIPs）的想法，用于描述闪电网络扩展及应用的文档，这些文档可通过互操作性标准带来收益。René Pickhardt 链接到了他在 2018 年提出的一个几乎相同的提案。

    在讨论中，该想法似乎得到了广泛支持，但也有担忧提出：这并不能真正解决将这些标准合并进基础 BOLTs 文档的障碍——这个障碍是资深开发者由于时间不足无法审核众多社区提案。如果未经充分审查就合并 BLIPs，则可能包含漏洞，或者难以获得多个利益相关方的广泛支持，导致各项目采用相互竞争的标准而出现分裂。然而，非主流协议已经在被创建，大多数讨论参与者都认为，如果能提供一个众所周知的存档来发布有关这些协议的文档，主要是有益的。

  • ● 零确认通道开启： Rusty Russell 在闪电网络开发者邮件列表中发起了一项讨论，探讨对零确认通道（也被称作 turbo channels）的标准化处理。它们指的是新的单向资助通道，在这里通道出资方会将部分或全部初始资金给到接收方。除非通道开启交易获得足够的确认，否则这些资金并不安全，因此接收方使用标准的闪电网络协议将其中一部分资金花给出资方并无风险。

    例如，Alice 在 Bob 的托管交易所账户中有数个 BTC。Alice 请求 Bob 开一个新通道并支付给她 1.0 BTC。因为 Bob 自己不会双花他刚刚开启的通道，所以他可以允许 Alice 在通道开启交易尚未得到任何确认之前，就通过他的节点向第三方 Carol 支付 0.1 BTC。

    零确认通道插图

    一些闪电网络实现已经以非标准方式支持了这种想法，而所有讨论参与者似乎都倾向于对其进行标准化。截至撰写时，仍在讨论使用的具体细节。

准备 Taproot #3：taproot 描述符

每周一篇的系列文章，讲述开发者和服务提供商如何为将在区块高度 709,632 激活的 taproot 做好准备。

输出脚本描述符 为钱包提供了一种通用方式，用来存储生成地址所需的信息、有效扫描付款给这些地址的输出，以及之后从这些地址花费。此外，描述符相对紧凑且包含一个基础校验和，这使其在备份地址信息、在不同钱包之间复制或在合作提供多签的多个钱包之间共享时都非常方便。

尽管当前只有少数项目在使用描述符，但它们和相关的 miniscript 项目有潜力显著提升不同钱包和工具之间的互操作性。随着越来越多的用户利用 taproot 带来的好处，通过多签来加强安全性，以及通过备份花费条件来提高恢复能力，这一点将变得愈加重要。

在此之前，需要先对描述符进行更新以适配 taproot。最近合并的 Bitcoin Core #22051 拉取请求正是针对这一需求。该语法设计允许使用单一描述符模板，同时提供使用 P2TR 密钥路径花费和脚本路径花费所需的全部信息。对于简单的单签名，以下描述符就足够了：

tr(<key>)

相同的语法也适用于多签和阈值签名。例如，Alice、Bob 和 Carol 使用 MuSig 聚合它们的密钥，然后支付给 tr(<combined_key>)。

出人意料的是，“tr(<key>) 中的 key” 并不会直接是地址中所编码的那个密钥。tr() 描述符遵循了 BIP341 中的安全性建议，使用一个承诺于不可花费脚本树的内部密钥，这就消除了对简单密钥聚合方案（像 MuSig 和 MuSig2 这类更先进的方案不受影响）的一个攻击。

对于脚本路径花费，新增了一种可指定二叉树内容的语法。例如，{ {B,C} , {D,E} } 描述了这样一棵树：

Internal key
    / \
   /   \
  / \ / \
  B C D E

可以将这棵树作为可选的第二个参数传入之前使用的描述符模板。例如，如果 Alice 希望能够通过密钥路径花费，但也允许 Bob、Carol、Dan 和 Edmond 以能够为她生成审计轨迹的脚本路径花费（但不对第三方链上监控暴露），她可以使用如下描述符：

tr( <a_key> , { {pk(<b_key>),pk(<c_key>)} , {pk(<d_key>),pk(<e_key>)} )

上述功能足以让描述符用于 taproot，但拉取请求 #22051 中提到仍有一些可能被添加的功能，用于让描述符更好地完整描述预期的策略：

  • ● *无效化密钥路径： 某些用户可能希望禁止通过密钥路径花费，从而强制使用脚本路径花费。现在可以在 tr() 第一个参数中使用不可花费的密钥来实现，但能够在描述符本身中记录这一偏好并让它计算出一个保护隐私的不可花费密钥路径将更好。

  • ● *Tapscript 多签： 对于传统和 v0 segwit，multi() 和 sortedmulti() 描述符支持 OP_CHECKMULTISIG 操作码。为了在 taproot 中实现批量验证，基于脚本的多签在 tapscript 中的处理方式有所不同，因此 tr() 描述符目前需要通过 raw() 脚本来指定任何必需的多签操作码。对 tapscript 版本的 multi() 和 sortedmulti() 进行更新将非常有用。

  • ● *基于 MuSig 的多签： 在本文前面，我们描述了 Alice、Bob 和 Carol 手动聚合它们的密钥，以使用一个 tr() 描述符。理想情况下，应当能有一个函数允许像 tr(musig(<a_key>, <b_key>, <c_key>)) 这样指定，这样他们就能保留全部初始密钥信息并用它来填充它们协同签名所用 PSBT 中的各字段。

  • ● *时间锁、哈希锁和点锁： 这些在闪电网络、DLCs、coinswaps 以及许多其他协议中使用的强大结构，目前只能通过 raw() 函数来描述。可将它们直接加入描述符是可行的，但也可能会在描述符的姊妹项目 miniscript 中添加对它们的支持。miniscript 整合到 Bitcoin Core 仍在进行中，但我们预期它的创新将和 PSBT、描述符等工具一样，推广到其他钱包中。

钱包并不需要实现描述符就能开始使用 taproot，但那些实现了描述符的，将为自己使用更高级的 taproot 功能奠定更好的基础。

发布与候选发布

面向主流比特币基础设施项目的新发布与候选发布版本。请考虑升级到新版本或帮助测试候选发布版本。

  • ● LND 0.13.1-beta.rc1 是一个维护版本，为 0.13.0-beta 中引入的功能带来了一些小改进和错误修复。

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

本周在 Bitcoin Core、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、比特币改进提案（BIPs）和闪电网络规范（BOLTs）中的一些值得注意的更改：

  • ● Bitcoin Core #19651 允许钱包密钥管理器更新已有的描述符。这让钱包用户可使用 importdescriptors 钱包 RPC 编辑标签、扩展描述符范围、重新激活失效描述符以及进行其他更新。

  • ● C-Lightning #4610 新增了一个 --experimental-accept-extra-tlv-types 命令行选项，使用户可指定一些偶数类型的 TLV 列表，以供 lightningd 交由插件处理。此前，lightningd 会将所有未知的偶数类型 TLV 消息视为无效。此更改允许插件定义并处理 lightningd 未知的自定义 TLV 类型。

  • ● Eclair #1854 新增了对来自其他节点（如已近期实现警告消息类型的 C-Lightning）发送的警告消息进行解码和记录日志的支持。

  • ● BIPs #1137 新增了 BIP86，该提案建议使用一种针对单密钥 P2TR 输出的密钥派生方案。该 BIP 已在上周的 newsletter 中做了简要介绍。

  • ● BIPs #1134 更新了 BIP155，用于指示在任何软件能够理解版本 2 addr 消息时，都应当发送 sendaddr2 P2P 功能谈判消息，即便在程序并不一定希望接收 addr 消息的情况下也是如此。