本期周报总结了比特币添加交易继承标识符的提案，并包含常规章节：关于为 taproot 做准备的进展、新版本与候选版本信息，以及主流比特币基础设施软件的显著变更摘要。

新闻

  • ● ​​交易继承标识符提案：​​ 匿名开发者 John Law 向 Bitcoin-Dev 和 Lightning-Dev 邮件列表提交了一篇帖子，提议通过软分叉添加继承标识符（IID）。该标识符允许引用交易输入的祖先交易 txid 及其输出位置。例如 0123...cdef:0:1 表示当前交易输入正在花费 txid 0123...cdef 第一个输出的第二个子项。这使得多方协议参与者无需预先知晓生成特定输出的交易 txid，即可创建该输出的消费签名。

    该方案与拟议的 SIGHASH_ANYPREVOUT 软分叉实现的浮动交易方案形成对比。eltoo 协议描述的浮动交易允许参与者在满足输出脚本条件的前提下，无需知晓 txid 即可创建签名。

    Law 在一份长达 66 页的论文中描述了 IID 实现的四种协议，包括替代 eltoo 和通道工厂的方案，以及简化瞭望塔设计的思路。Anthony Towns 建议 IID 的功能可通过 anyprevout 模拟实现，但 Law 反驳了该模拟可能性。

    由于部分参与者不愿使用邮件列表，讨论进展受阻。若后续讨论恢复，我们将在未来周报中总结重要更新。

准备 Taproot #16：输出关联

本系列文章每周更新，帮助开发者和服务提供商为即将在区块高度 709,632 激活的 taproot 做准备。系列入口

在 taproot 激活后，用户将开始接收支付至 P2TR 输出的交易。随后，他们将花费这些输出。某些情况下，用户可能向非 P2TR 输出支付，但仍会使用 P2TR 找零输出将剩余资金返还给自己。

示例交易 P2TR -> {P2WPKH、P2TR}

对于观察此类交易的专家或算法而言，可以合理推断 P2TR 输出是用户自身的找零输出，而其他输出则为支付输出。虽然这并非绝对成立，但属于最可能的解释。

有观点认为，由于钱包向 P2TR 过渡期间可能出现的隐私暂时下降，应当忽略 taproot 的诸多隐私优势。多位专家指出这种担忧属于过度反应。我们认同此观点，并补充以下考量：

  • ● ​​其他元数据：​​ 交易可能包含其他揭示找零与支付输出的元数据。最令人担忧的是当前大量存在的地址复用现象，严重损害交易双方的隐私。只要这些问题存在，拒绝为遵循最佳实践的钱包和服务用户实施重大隐私升级便显失明智。

  • ● ​​输出脚本匹配：​​ Bitcoin Core 内置钱包默认在支付输出包含隔离见证类型时使用隔离见证找零输出，否则使用默认找零地址类型。例如支付至 P2PKH 输出时可能使用 P2PKH 找零，支付至 P2WPKH 输出时使用 P2WPKH 找零。如周报 #155所述，taproot 激活后 Bitcoin Core 将在交易包含其他 P2TR 输出时优先使用 P2TR 找零输出，最大程度减少过渡期找零可识别性的增加。

  • ● ​​请求升级：​​ P2TR 为比特币历史首次提供了机会，让所有用户无论安全需求如何均使用相同类型的输出脚本，并频繁使用不可区分的输入，显著提升隐私。若期望提升比特币隐私，可要求收款方和服务提供商支持 taproot（并停止地址复用）。若双方均完成升级，找零输出将更难以识别，同时还能获得 taproot 的其他卓越隐私优势。

发布与候选发布

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

显著代码与文档变更

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

  • ● Bitcoin Core GUI #416 新增「启用 RPC 服务器」复选框，允许用户开关 Bitcoin Core 的 RPC 服务器（需重启生效）。

    启用 RPC 服务器配置选项的截图

  • ● Bitcoin Core #20591 修改钱包时间计算逻辑，在重新扫描历史区块时仅使用区块时间戳。使用 rescanblockchain RPC 手动触发重扫描的用户和应用将不再看到交易被错误标记为扫描时间而非确认时间，消除了常见的混淆来源。

  • ● Bitcoin Core #22722 更新 estimatesmartfee RPC，使其仅返回高于配置值与动态最低交易转发手续费的费率。例如若估算值为 1 sat/vbyte、配置值为 2 sat/vbyte、动态最低值升至 3 sat/vbyte，则返回 3 sat/vbyte。

  • ● Bitcoin Core #17526 新增单次随机抽取（SRD）算法作为第三种币选择策略。钱包现会从分支定界（BnB）、背包算法和 SRD 算法中获取结果，并采用此前描述的浪费启发式选择最优方案。

    基于约 8,000 笔支付的模拟显示，SRD 算法的加入使总手续费降低 6%，无找零交易比例从 5.4% 提升至 9.0%。无找零输出可降低交易重量与手续费、减少 UTXO 池规模、节省后续花费成本，并提升隐私性。

  • ● Bitcoin Core #23061 修复 -persistmempool 配置项，此前无参数时（默认启用）关闭节点不会持久化内存池。现使用该选项即可持久化（默认仍保持启用状态）。

  • ● Bitcoin Core #23065 实现钱包 UTXO 锁的持久化存储。通过 lockunspent RPC 的 persistent 参数可将锁定偏好保存至磁盘，GUI 也会自动持久化用户选择的锁定。该功能可用于防止低价值垃圾输出的消费，或避免损害隐私的输出使用。

  • ● C-Lightning #4806 新增节点费率设置变更后 10 分钟的默认延迟执行机制。这确保新费率在网络传播后再拒绝不符合新费率的支付。

  • ● Eclair #1900 与 Rust-Lightning #1065 实现 BOLTs #894，强制要求承诺交易仅使用隔离见证输出。该限制使得闪电网络程序可采用更低的粉尘限制（在低费率时减少通道强制关闭的矿工费损失）。

  • ● LND #5699 新增可删除支付记录的 deletepayments 命令。默认仅允许删除失败的支付，成功支付需额外标志才可删除。

  • ● LND #5366 初步支持 PostgreSQL 作为数据库后端。相比现有 bbolt 后端，PostgreSQL 支持多服务器复制、实时数据库压缩、处理更大数据集，并提供更细粒度的锁模型以改善 I/O 锁争用。

  • ● Rust Bitcoin #563 新增对 P2TR 输出 bech32m 地址的支持。

  • ● Rust Bitcoin #644 新增对 tapscript 新操作码 OP_CHECKMULTISIGADD 和 OP_SUCCESSx 的支持。

  • ● BDK #376 新增对 sqlite 数据库后端的支持。