本周的周报总结了关于近期 OP_RETURN 使用情况的讨论，并介绍了一种无需共识变更即可强制执行类似限制条款的花费条件的协议。此外还包括我们的常规栏目：介绍服务和客户端软件的近期更新、宣布新版本和候选版本，以及总结热门比特币基础设施软件的重大变更。

新闻

  • ● 近期 OP_RETURN 输出统计： Anthony Towns 在 Delving 上发帖，总结了 Bitcoin Core v30.0 于 10 月 10 日发布以来的 OP_RETURN 统计数据。该版本对 OP_RETURN 输出的交易池策略限制进行了修改，允许一笔交易包含多个 OP_RETURN 输出，并允许 OP_RETURN 输出中携带最多 100kB 的数据。他查看的区块范围为高度 915800 到 936000，结果如下：

    • 24,362,310 笔带有 OP_RETURN 输出的交易

    • 61 笔带有多个 OP_RETURN 输出的交易

    • 396 笔 OP_RETURN 输出脚本总大小超过 83 字节的交易

    • 这段期间 OP_RETURN 输出脚本数据总量为 473,815,552 字节（其中大型 OP_RETURN 占 0.44%）

    • 34,283 笔交易将 sats 销毁到 OP_RETURN 输出中，总计销毁 1,463,488 sats

    • 949,003 笔交易的 OP_RETURN 数据在 43 到 83 字节之间，23,412,911 笔交易的 OP_RETURN 数据不超过 42 字节

    Towns 还附上了一张图表，展示了这 396 笔大型 OP_RETURN 交易的数据大小分布。其中 50% 的交易，其 OP_RETURN 数据不到 210 字节；另有 10% 的交易，其 OP_RETURN 数据超过 10KB。

    他后来又补充说，Murch 随后在 X 上发布了类似的分析以及一个 OP_RETURN 统计仪表板，而 orangesurf 则发布了一份面向交易池研究的 OP_RETURN 报告。

  • ● Bitcoin PIPEs v2： Misha Komarov 在 Delving Bitcoin 上发帖介绍了 Bitcoin PIPEs，这是一种无需共识变更或乐观挑战机制，即可强制执行花费条件的协议。

    比特币协议基于一种极简的交易验证模型，其核心是验证被花费的 UTXO 是否由有效的数字签名授权。因此，Bitcoin PIPEs 不依赖比特币脚本来表达花费条件，而是对“能否生成有效签名”这一点增加前置条件。换句话说，私钥会以密码学方式被锁定在一个预先设定的条件之后；只有当条件满足时，私钥才会被揭示，从而生成有效签名。比特币协议本身只需验证一个 schnorr 签名，而所有条件逻辑都在链下处理。

    在形式化层面，Bitcoin PIPEs 包含两个主要阶段：

    • 设置：生成一个标准的比特币密钥对 (sk, pk)。然后使用见证加密，将 sk 加密在一条关于花费条件的声明之后。

    • 签名：为这条声明提供见证 w。如果 w 有效，sk 就会被揭示，从而可以生成 schnorr 签名；否则，从计算上恢复 sk 将不可行。

    据 Komarov 介绍，Bitcoin PIPEs 可以复现限制条款的语义。特别是，Bitcoin PIPEs v2 专注于一组受限的花费条件，用来强制执行二元限制条款。这个模型自然涵盖了许多结果只有二元取值的有用条件，例如提供有效的零知识证明、满足退出条件，或存在欺诈证明。归根结底，它只回答一个问题：“条件满足了，还是没有？”

    最后，Komarov 提供了几个实际示例，说明如何用 PIPEs 取代新操作码，以及如何用它改进 BitVM 协议中的乐观验证流程。

服务和客户端软件变更

在这个月度栏目中，我们重点介绍比特币钱包和服务的有趣更新。

  • ● Second 发布基于 hArk 的 Ark 软件： Second 的 Ark 库在 0.1.0-beta.6 版本中更新为使用 hArk（hash-lock Ark）。这一新协议消除了用户在轮次期间必须同步交互的要求，但也带来了它自身的一组权衡。该版本还包含多项其他更新，其中包括破坏性变更。

  • ● Amboss 宣布 RailsX： RailsX 公告 介绍了一个使用闪电网络和 Taproot Assets 来支持互换及其他多种金融服务的平台。

  • ● Nunchuk 添加静默支付支持： Nunchuk 宣布 支持向静默支付地址付款。

  • ● Electrum 添加潜水艇互换功能： Electrum 4.7.0 允许用户使用其闪电网络余额进行链上支付（见潜水艇互换），此外还包含其他功能和修复。

  • ● Sigbash v2 发布： Sigbash v2 现使用 MuSig2、WebAssembly（WASM）和零知识证明，以实现更好的共签服务隐私保护。更多背景可参见我们此前关于 Sigbash 的报道。

新版本和候选版本

热门比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。

  • ● BTCPay Server 2.3.5 是这个自托管支付解决方案的小版本更新，添加了仪表板上的多币种钱包余额小组件、自定义结账文本框和新的汇率提供方，并包含若干 bug 修复。

  • ● LND 0.20.1-beta 是这个热门闪电网络节点实现的维护版本，加入了 gossip 消息处理的 panic 恢复机制，改进了重组保护，加入了用于检测 LSP 的启发式规则，并修复了多个 bug 和竞态条件。

重大代码和文档变更

本周的重大变更有：Bitcoin Core、Core Lightning、Eclair、LDK、LND、libsecp256k1、Hardware Wallet Interface（HWI）、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIPs）、Lightning BOLTs、Lightning BLIPs、Bitcoin Inquisition 和 BINANAs。

  • ● Bitcoin Core #33965 修复了一个 bug：-blockreservedweight 启动配置（见周报 #342）可能会静默覆盖 Mining IPC 客户端设置的 block_reserved_weight 值（见周报 #310）。现在，当 IPC 调用方设置后者时，它就会优先生效。对于从未设置该值的 RPC 调用方，启动配置 -blockreservedweight 则始终生效。此 PR 还对 IPC 调用方强制执行 MINIMUM_BLOCK_RESERVED_WEIGHT，防止他们设置低于该值的数值。

  • ● Eclair #3248 在转发 HTLC 时开始优先使用私有通道而非公共通道（如果两者都可用）。这使更多流动性保留在对网络可见的公共通道中。当两个通道具有相同的可见性时，Eclair 现在优先选择余额较小的通道。

  • ● Eclair #3246 为多个内部事件添加了新字段：TransactionPublished 将单一的 miningFee 字段拆分为 localMiningFee 和 remoteMiningFee，增加了一个计算得出的 feerate，以及一个可选的 LiquidityAds.PurchaseBasicInfo，用来将交易关联到一笔流动性购买。通道生命周期事件现在也包含 commitmentFormat，用于描述通道类型，而 PaymentRelayed 则增加了 relayFee 字段。

  • ● LDK #4335 添加了对使用 BOLT12 要约的幻影节点支付的初步支持（见周报 #188）。在 BOLT11 版本中，发票包含指向一个并不存在的“幻影”节点的路由提示，而每条路径的最后一跳则是一个可以使用无状态发票接收支付的真实节点。在 BOLT12 中，要约只需包含多条终止于各个参与节点的盲化路径。当前实现允许多个节点响应发票请求，但最终生成的发票只能支付给作出响应的节点。

  • ● LDK #4318 从 ChannelHandshakeLimits 结构体中移除了 max_funding_satoshis 字段，有效地消除了 wumbo 之前的默认通道大小限制。LDK 已经默认通过 option_support_large_channels 特性标志宣告支持大通道，这可能会与之前的设置冲突，向对等节点错误地发出支持信号。想要限制风险的用户可以使用手动通道接受流程。

  • ● LND #10542 扩展了图数据库层以支持 gossip v1.75（见周报 #261 和 #326）。LND 现在可以存储和检索简单 taproot 通道的通道公告。gossip v1.75 在网络层面仍处于禁用状态，等待验证和 gossiper 子系统完成。

  • ● BIPs #1670 发布了 BIP360，它规定了 Pay-to-Merkle-Root（P2MR）这一新的输出类型。它的工作方式类似于 P2TR，但移除了密钥路径花费。P2MR 输出能够抵抗密码学相关量子计算机（CRQC）的长期暴露攻击，因为它们直接承诺的是脚本树的默克尔根，也就是一个 SHA256 哈希，而不是公钥。不过，若要防御短期暴露攻击，例如在交易尚未确认时恢复私钥，仍然需要单独的后量子签名提案。参见周报 #344，了解该提案以 P2QRH 为名时的早期报道；以及周报 #385，了解它以 P2TSH 为名时的报道。

  • ● BOLTs #1236 更新了双向注资规范，允许任一节点在通道建立期间发送 tx_init_rbf，从而实际上允许双方都能对注资交易追加手续费。此前，只有通道发起方可以这样做。此变更使双向注资与拼接保持一致，因为在拼接中，任一方本来就可以发起 RBF。该 PR 还增加了一项要求：tx_init_rbf 和 tx_ack_rbf 的发送方都必须重用前一次尝试中的至少一个输入，以确保新交易会双花所有先前的尝试。

  • ● BOLTs #1289 更改了在双向注资和拼接使用的交互式交易协议中，重连时 commitment_signed 的重传方式。此前，commitment_signed 在重连时总是被重传，即使对等方已经收到了它。现在，channel_reestablish 包含一个显式位域，让节点仅在仍需要时才请求 commitment_signed。这避免了不必要的重传，这对未来的简单 taproot 通道尤其重要，因为重传将需要由于 nonce 变更而进行完整的 MuSig2 签名轮次。