本周的周报总结了关于在 DLC 规范中实施破坏性变更的提案，探讨了仅使用 BIP32 种子恢复已关闭闪电网络通道的可能性，并描述了生成无状态闪电网络发票的构想。此外还包括我们的常规栏目：Bitcoin Stack Exchange 精选问答、为 taproot 激活做准备的思路，以及热门比特币基础设施软件的重要变更摘要。

新闻

  • ● ​关于 DLC 规范破坏性变更的讨论：​​ Nadav Kohen 在 DLC-dev 邮件列表中发布了关于更新 DLC 规范的提案，其中包含多个可能破坏现有应用兼容性的变更。他提出了两种方案：按需更新规范并让应用声明其实现的版本；或将多个破坏性变更集中处理以最小化中断次数。邀请正在开发 DLC 软件的技术人员提供反馈。

  • ● ​仅用种子恢复闪电网络关闭交易的挑战：​​ Electrum Wallet 开发者 ghost43 在 Lightning-Dev 邮件列表中发表关于仅通过扫描区块链恢复钱包通道关闭交易所面临的挑战。具体问题涉及在使用仅基于 BIP32 风格分层确定性密钥生成恢复钱包时，如何处理新的锚定输出协议。ghost43 分析了多种可能的方案，并推荐目前 Eclair 使用的方案作为当前最佳实践。如果实现方愿意对通道开通协议稍作修改，还可进一步改进该方案。

  • ● ​无状态闪电网络发票生成：​​ Joost Jager 在 Lightning-Dev 邮件列表中提出针对未认证用户生成闪电网络发票可能遭受拒绝服务攻击的问题。攻击者可能请求无限量发票，导致生成服务需要存储这些发票直至过期。Jager 建议对于不需要存储大量数据的小额发票，服务可在生成后立即丢弃，仅向用户提供发票参数。用户支付时提交这些参数，服务端即可重建发票、接收支付并完成订单。

    尽管有回复认为该方案必要性存疑——攻击者可通过其他方式发起请求洪泛，且任何解决方案都应同时解决发票请求洪泛问题——但也有观点认为该构想具有实用价值。该方案似乎无需协议变更，只需通过软件修改（或插件）实现发票生成与重建管理。

Bitcoin Stack Exchange 精选问答

Bitcoin Stack Exchange 是 Optech 贡献者寻找问题解答的首选场所——或在闲暇时帮助好奇或困惑的用户。本栏目精选自上次更新以来得票最高的问题与答案。

准备 Taproot #15：仍需 Signmessage 协议

关于开发者和服务提供商如何为即将在区块高度 709,632 激活的 taproot 做准备的系列周更文章。

自四年前隔离见证（segwit）激活以来，尚未形成被广泛接受的为 Bech32 或 Bech32m 地址创建签名消息的方式。可以说，我们现在可以认为广泛的消息签名支持对用户或开发者而言并不十分重要，否则会有更多工作投入其中。但相较于过去使用传统地址时用户可便捷交换签名消息的情况，比特币钱包软件的功能似乎有所倒退。

我们在两年前关于 Bech32 消费支持 系列文章中提到的通用 Signmessage 方案进展甚微，即便其协议文档 BIP322 偶有更新（参见 Newsletter #118 和 #130），也未被 Bitcoin Core 采用。尽管如此，我们尚未发现更优替代方案，因此任何希望在 P2TR 钱包中添加 Signmessage 功能的开发者仍应将 BIP322 作为首选。

若得以实现，通用 Signmessage 协议将支持为以下类型的 P2TR 输出签名：纯单签、使用多签或任何 Tapscript 脚本。该协议还将向后兼容所有传统及 Bech32 地址，并向前兼容目前规划的近期变更类型（部分内容将在后续为 Taproot 激活做准备专栏中预告）。能够访问完整 UTXO 集的应用（例如通过全节点）还可利用 BIP322 生成和验证储备证明，以证明签名者在特定时间点控制特定数量的比特币。

实现通用签名消息功能的创建相对简单。BIP322 采用称为虚拟交易的技术：首笔虚拟交易通过尝试花费不存在的先前交易（txid 全为零）构造为无效交易，该交易支付至用户需签名的地址（脚本）并包含对目标消息的哈希承诺；第二笔交易花费首笔交易的输出——若该花费的签名及其他数据构成有效交易，则视为消息已签名（尽管第二笔虚拟交易仍无法上链，因其源自无效的前序交易）。

对多数钱包而言，验证通用签名消息更为复杂。要完全验证任意 BIP322 消息需实现比特币几乎所有的共识规则。多数钱包不具备此能力，因此 BIP322 允许其在无法完整验证脚本时返回”不确定”状态。实践中，尤其是 Taproot 鼓励密钥路径花费的背景下，这种情况可能较少。任何仅实现几种常用脚本类型的钱包将能验证超过 99% UTXO 的签名消息。

通用 Signmessage 支持将是比特币的一项有益补充。尽管过去数年其受关注度不足，我们仍鼓励阅读本文的钱包开发者考虑为您的程序添加实验性支持。这是为用户恢复已缺失数年的功能的便捷途径。若您是参与 BIP322 或相关储备证明实现的开发者，或认为此类功能有价值的服务提供商，欢迎联系 info@bitcoinops.org 以协调合作。

发布与候选发布

热门比特币基础设施项目的新版本与候选版本。建议升级至新版本或协助测试候选版本。

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

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

  • ● Bitcoin Core #12677 在钱包的 listunspent RPC 方法返回的交易输出信息中新增 ancestorcount、ancestorsize 和 ancestorfees 字段。若创建该输出的交易未确认，这些字段将显示该交易及其内存池中所有未确认祖先交易的总数量、总大小和总手续费。矿工根据祖先手续费率选择交易打包，因此了解祖先交易数据有助于用户估算确认时间或通过 CPFP 和 RBF 提升手续费。

  • ● Eclair #1942 支持在路径寻优算法中配置基于通道容量的路由评估策略。该配置可作为实验性参数集应用，可能提升路由成功率。[编辑：本条目经读者 Thomas Huet 指正后修订。]

  • ● LND #5101 新增中间件拦截器功能，可在每个 RPC 请求到达服务器前进行拦截和修改。这使得开发者能在 LND 外部实现跟踪或影响各类用户与自动化操作的逻辑。出于安全考虑，只有使用明确授权拦截的认证令牌（macaroon）的 RPC 才能被拦截。