本周周报概述了一种采用盲化版 MuSig2 的类 vault（保管库）方案，并介绍了一项让比特币客户端能够就新的 P2P 特性宣布并协商是否支持的提案。此外还包括我们的常规部分：总结与共识变更相关的讨论、新版本和候选版本的公告，以及对热门比特币基础设施软件的重大变更总结。

新闻

  • ● 使用盲化共同签名者构建保管库： Johan T. Halseth 在 Delving Bitcoin 上发布了一个使用盲化共签者的类保管库方案的原型。不同于传统的共签设置，该方案使用 MuSig2 的盲化版本，以确保签名者对其参与签名的资金了解尽可能少。为避免签名者不得不对提交给他们的内容“盲签”，该方案在签名请求中附带零知识证明，证明该交易满足预先设定的策略要求（此处为时间锁）。

    Halseth 提供了一张方案流程图，展示了四笔将被预签名的交易：初始存入交易、恢复交易、出库（unvault）交易以及出库恢复交易。在进行出库（unvault）时，共签者将要求提供零知识证明，以证明其所签的交易已正确设置相对时间锁。这从而确保在发生未授权的出库（unvault）时，用户或瞭望塔仍有时间将资金扫走/转走。

    Halseth 还提供了一个可用于 regtest 和 signet 的原型实现。

  • ● 对等节点特性协商： Anthony Towns 在 Bitcoin-Dev 邮件列表上发布了一项新 BIP 的提案，计划定义一种 P2P 消息，让对等节点能够宣布并协商对新特性的支持。这个想法与 2020 年的一个旧方案类似，并将惠及多种拟议中的 P2P 用例，包括 Towns 关于模板共享的工作。

    历史上，P2P 协议的变更主要依赖上调版本号来表明对新特性的支持，从而确保对等节点只与兼容节点进行协商。然而，这种做法会在不同客户端实现之间引入不必要的协调成本，尤其是对那些并不需要全网普遍采用的特性而言。

    该 BIP 提议将 BIP339 的机制进行泛化：在 pre-verack 阶段引入一种单一、可复用的 P2P 消息，用于宣布并协商未来的 P2P 升级。这样可以降低协调成本，实现无需许可的可扩展性，防止网络分区，并最大化与不同客户端实现的兼容性。

共识变更

在这个月度栏目，总结关于变更比特币共识规则的提案和讨论。

  • ● 2106 年时间戳溢出：迁移到 uint64： Asher Haim 在 Bitcoin-Dev 邮件列表上发文，呼吁比特币开发者尽快采取行动，为区块时间戳从 uint32 迁移到 uint64 做准备。Haim 解释了为何需要尽早行动：可能会在比想象中更早的时间出现期限跨越 2106 年、并引用比特币的长期金融合约。这还不是一个以 BIP 形式提出的具体提案；围绕时间锁以及比特币生态的其他部分，仍有大量细节需要进一步敲定与完善。2024 年 1 月的 BitBlend 提案提供了一种可能的具体解决思路。

  • ● 为 2106 软分叉放宽 BIP54 的时间戳限制： Josh Doman 在 Bitcoin-Dev 邮件列表和 Delving Bitcoin 上发帖，询问是否值得修改共识清理提案，使其对异常的区块时间戳行为更宽容，从而为解决 2106 区块时间戳溢出问题保留软分叉方案的可能性。ZmnSCPxj 早在 2021 年就提出过类似的想法。两个论坛的讨论都聚焦于：在有充分工程理由选择硬分叉的情况下，为了避免硬分叉而做出让步是否值得。Greg Maxwell 写道，以这种方式放宽限制，可能会让 BIP54 旨在修复的时间扭曲攻击重新变得可行；仅这一风险就可能足以成为不应放宽限制的理由。

  • ● 理解并缓解 CTV 的“脚枪”问题： Chris Stewart 在 Delving Bitcoin 上发帖讨论了 OP_CHECKTEMPLATEVERIFY（CTV） 的一个“脚枪”（footgun）问题。具体来说，如果有人创建一个输出，支付到某个无条件要求特定单输入 CTV 哈希的 scriptPubKey，但该输出金额小于该 CTV 哈希所承诺的各输出金额总和，那么生成的这个输出将永久不可花费。他提出，CTV 用户可让其所有 CTV 哈希都承诺至少 2 个输入，以缓解这一风险。如此一来，总能构造出一个额外输入，从而使这类输出仍可被花费。

    Greg Sanders 回复指出了这种方法的一些局限性；1440000bytes 提到，这种问题只会出现在下一笔交易模板被无条件强制执行的情况下。Greg Maxwell 认为，这恰恰说明应避免整类“交易模板限制条款”类别的方案。Brandon Black 指出，在收款地址上使用 CTV 的确是一种风险较高的应用设计；将 CTV 与另一个操作码（如 OP_CHECKCONTRACTVERIFY（BIP443））结合，可能可以实现更安全的应用。

  • ● CTV 激活会议： 开发者 1440000bytes 主持了一场 CTV（BIP119）激活会议。与会者一致认为，CTV 激活客户端应当使用保守参数（即更长的信号期与激活期），并采用 BIP9。截至撰写本文时，邮件列表上的其他开发者尚未对此发表意见。

  • ● 用 OP_CHECKCONSOLIDATION 实现更低成本的归集： billymcbip 提出了一个专门为归集优化的操作码。OP_CHECKCONSOLIDATION（CC）当且仅当它在某个输入上执行、且该输入的 scriptPubKey 与同一笔交易中更早的某个输入的 scriptPubKey 相同，才会求值为 1。大量讨论围绕着这一要求展开：使用相同 scriptPubKey 会鼓励地址复用，从而损害隐私。Brandon Black 提议用 OP_CHECKCONTRACTVERIFY（BIP443）实现类似功能（但在字节效率上不如 CC）。该提案与 Tadge Dryja 早先关于 OP_CHECKINPUTVERIFY 的工作相似，但在字节上显著更高效、泛化程度更低。

  • ● 面向比特币后量子未来的基于哈希的签名： Mikhail Kudinov 和 Jonas Nick 在 Bitcoin-Dev 邮件列表上发帖，介绍他们评估将基于哈希的签名用于比特币的工作。他们的研究发现，相较于当前标准化方案，签名大小存在显著的优化空间；但并未找到可替代 BIP32、BIP327 或 FROST 的可行方案。多位开发者参与讨论，围绕这项工作、其他后量子签名机制以及比特币未来可能的发展路径展开交流。

    讨论中也涉及：比较新的签名验证机制时，更适合用“每字节 CPU 周期”还是“每签名 CPU 周期”作为衡量指标。如果新的签名验证仍受现有权重上限及相关乘数（multipliers）约束，从而限制支付吞吐量，那么按“每字节”比较似乎更贴切；而如果新签名会引入其自身的独立限制，使后量子比特币的支付吞吐量能更接近当前水平，那么按“每签名”比较可能更合适。

版本和候选版本

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

  • ● BTCPay Server 2.3.0 是这个热门自托管支付解决方案的一个新版本，它将“订阅（Subscriptions）”功能（参见周报 #379）加入了用户界面和 API，改进了支付请求，并包含多项其他功能与错误修复。

重大的代码和文档变更

本周的重大变更有：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 #33657 引入了一个新的 REST 端点 /rest/blockpart/<BLOCKHASH>.bin?offset=X&size=Y，它会返回区块的某个字节范围。这让 Electrs 等外部索引器可以只抓取特定交易，而无需下载整个区块。

  • ● Bitcoin Core #32414 在重新索引期间新增了定期将 UTXO 缓存刷写到磁盘的机制，作为现有 IBD 期间刷写机制的补充。此前只会在到达链尖时刷写，因此如果在重新索引过程中崩溃、且设置了较大的 dbcache，可能会丢失大量进度。

  • ● Bitcoin Core #32545 用一种“生成森林（spanning-forest）线性化”算法替换了先前引入的族群线性化算法（参见周报 #314），该新算法旨在更高效地处理更复杂的族群。对历史交易池数据的测试表明，新算法可以在几十微秒内线性化所有观察到的、最多 64 笔交易的族群。这是族群交易池项目的一部分。

  • ● Bitcoin Core #33892 放宽了中继策略：允许机会性的“一父一子（1p1c）”交易包中继，即使父交易的费率低于最低中继费率、且父交易并非 TRUC，只要该交易包的整体费率超过节点当前的最低中继费率，并且子交易没有其他费率低于最低值的祖先交易，就可以中继。此前为简化对交易池修剪的推理，这一能力被限制为仅对 TRUC 交易适用；但在有了族群交易池之后，这已不再是顾虑。

  • ● Core Lightning #8784 为 xpay RPC 命令（参见周报 #330）增加了 payer_note 字段，使付款方在请求发票时可以提供付款说明。fetchinvoice 命令已经有类似的 payer_note 字段，因此该 PR 将其加入到 xpay，并将该值一路传递到后续处理流程中。

  • ● LND #9489 与 #10049 引入了一个实验性的 switchrpc gRPC 子系统，包含 BuildOnion、SendOnion 和 TrackOnion 等 RPC，使外部控制器能够负责寻路与支付生命周期管理，同时仍使用 LND 来转发 HTLC。该服务器端实现的编译被隐藏在非默认的 switchrpc 构建 tag 之后。LND #10049 具体加入了外部尝试（attempt）跟踪所需的存储基础，为未来实现幂等版本打下基础。目前，为避免资金损失，一次只允许一个实体通过 switch 派发尝试才是安全的。

  • ● BIPs #2051 对 BIP3 规范做出了多项修改：撤销了最近加入的反对使用 LLM 的指导（参见周报 #378）、扩展了参考实现的格式、增加了变更日志，并做出其他若干改进与澄清。

  • ● BOLTs #1299 更新了 BOLT3 规范，移除了一个含糊的说明：在支付给对手方的 to_remote 输出中使用基于 per-commitment point 的localpubkey。在 option_static_remotekey 选项下，这不再成立，因为 to_remote 输出预计要使用接收方的静态 payment_basepoint，以便在不依赖 per-commitment point 的情况下实现资金恢复。

  • ● BOLTs #1305 更新了 BOLT11 规范，澄清 n 字段（收款方节点的 33 字节公钥）并非必填。这修正了先前一处将其描述为必填的表述。