本周 Newsletter 总结了有关直接向矿工提交交易的讨论，提供了钱包实现应参考的 taproot 测试向量集，并包含我们关于准备 taproot、新版本发布与候选版本、以及热门比特币基础设施项目值得注意的变更的常规板块。

新闻

• ● ​​向矿工直接提交交易：​ Lisa Neigut 在 Bitcoin-Dev 邮件列表中发起讨论，探讨是否废除 P2P 交易中继网络并让用户直接向矿工提交交易。提议的潜在优势包括降低带宽需求、提升隐私性、简化替换手续费（RBF）和子为父付费（CPFP）的规则复杂性，以及改善下一区块手续费率的沟通机制。然而，多位参与者提出异议：

  • ● ​​带宽需求：​ 多个回复指出，自 2016 年起使用的致密区块中继协议，已使得节点在区块中包含未确认交易时无需重复接收该交易，且带宽开销极低。未来升级方案如Erlay将进一步降低未确认交易中继的带宽消耗。

  • ● ​​隐私提升：​ 尽管仅向矿工提交交易可在交易确认前隐藏其公开可见性，但 Pieter Wuille 指出，这也赋予矿工特权化的网络视角。公众透明性似乎更为可取。

  • ● ​​RBF、CPFP 及规则复杂性：​ 节点运营商确实比矿工更关注资源浪费型攻击，但 Gloria Zhao 强调，这更多是程度问题。大规模的同类型攻击仍会影响矿工，因此矿工仍需采取与节点类似的防御措施。

  • ● ​​手续费率沟通：​ Bitcoin Core 当前手续费率估算基于观察未确认交易的确认时长。此方法虽滞后于实时费率信息，但 Pieter Wuille 建议，可通过弱区块广播等已有提案改进。弱区块验证门槛低于有效工作量证明区块，能更及时反映矿工当前处理的交易。

  此外，现有系统的优势也得到强调：

  • ● ​​矿工匿名性：​ ZmnSCPxj 指出，当前网络中超过 5 万个节点均可传播交易，矿工仅需匿名运行一个节点即可获取所需信息。若强制要求矿工维持持久身份（即便使用 Tor 等匿名网络），将更容易被识别并胁迫实施交易审查。

  • ● ​​抗审查性：​ Pieter Wuille 强调，现有系统允许用户自由搭建节点连接矿机开始挖矿。而转向直接提交交易需要新矿工主动公开节点接收交易，这可能面临审查与女巫攻击难题。

  • ● ​​去中心化维持：​ Wuille 指出，直接提交模式下提交交易的成本与各矿工算力无关，但收益与算力正相关。这将导致钱包倾向仅向少数大型矿池提交交易，加剧中心化。

• ● ​ ​Taproot 测试向量集：​ Pieter Wuille 向 Bitcoin-Dev 邮件列表发布其提议加入 BIP341taproot 规范的测试向量。这些向量重点关注“钱包实现，涵盖从密钥/脚本计算默克尔根/调整量/脚本公钥、密钥路径支出的签名消息/签名哈希/签名计算，以及脚本路径支出的控制区块计算”。

  对于希望在激活后尽快支持 taproot 的开发者，这些测试向量尤为有用。

准备 Taproot #20：激活时会发生什么？

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

在本文发布后不到两周时间，taproot 预计将在区块 709,632 激活。我们了解预期会发生的情况，同时也意识到几种可能的故障模式。

最理想且最可能的结果是一切顺利。普通用户不会感知到任何变化，只有那些密切监控节点或尝试创建 taproot 交易的用户会注意到差异。在区块 709,631 时，我们所知几乎所有全节点都将执行相同的共识规则。随后的区块中，运行 Bitcoin Core 0.21.1、22.0 或相关版本的节点将开始执行早期版本未包含的 taproot 规则。

这存在不同版本节点软件接受不同区块的风险。类似情况曾发生在 2015 年 BIP66 软分叉激活期间，导致六区块的链分叉及多次短暂分叉。开发团队已投入大量精力防止此类问题重演。只有在矿工故意挖出违反 taproot 规则的区块，或禁用了 Bitcoin Core 等节点软件内置的安全机制时，才可能出现类似问题。

具体而言，要制造链分叉，矿工需创建或接受未遵守 taproot 规则的花费 segwit v1 输出的交易。若发生这种情况，当比特币节点运营者的经济共识拒绝这些无效区块时，相关矿工将至少损失 6.25 BTC（约合 40 万美元）。

我们无法在未实际创建无效区块的情况下断言节点运营者的行为（节点可完全私有运行），但通过代理指标观测显示，超过 50% 的节点运营者正在运行支持 taproot 的 Bitcoin Core 版本。这足以确保任何 taproot 无效区块将被网络拒绝。

尽管可能性极低，理论上仍存在临时链分叉风险。可通过 ForkMonitor.info 等监控服务或 Bitcoin Core 的 getchaintips RPC 进行监测。若分叉发生，轻客户端可能收到错误确认。虽然理论上可能出现 6 次确认（如 2015 年分叉），但这意味着矿工将损失近 250 万美元（2015 年损失约 5 万美元）。在如此高昂代价下，我们有理由相信矿工会切实执行半年前就发出支持信号的 taproot 规则。

在几乎所有可预见的故障场景中，简单有效的临时应对措施是提高确认要求。若常规需 6 次确认接收支付，可临时提升至 30 次确认并持续数小时，直至问题解决或确认需进一步上调。

对于确信全节点运营者经济共识将执行 taproot 规则的用户和服务，更简单的解决方案是仅从 Bitcoin Core 0.21.1 或更新版本（或兼容替代实现）获取交易确认信息。

Optech 预计 taproot 激活将平稳完成，但仍建议交易所在区块 709,632 前后处理大额交易时升级节点，或准备好在出现异常迹象时临时提高确认要求。

发布与候选发布

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

• ● Bitcoin Core 0.20.2 是 Bitcoin Core 前分支的维护版本，包含次要功能更新与漏洞修复。

• ● C-Lightning 0.10.2rc2 是候选版本，包含对不经济输出漏洞的修复、优化数据库体积及提升 pay 命令效率（详见下文重大变更章节）。

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

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

• ● Bitcoin Core #23306 支持地址管理器为单个 IP 配置多端口。Bitcoin Core 历来固定使用 8333 端口并优先连接该端口地址。此举不仅有助于防止利用比特币节点实施对非比特币服务的 DoS 攻击，也为未来实现更统一的地址处理奠定基础。

• ● C-Lightning #4837 新增 --max-dust-htlc-exposure-msat 配置选项，限制待处理 HTLC 中低于粉尘限额的总额。详见我们早前对 Rust-Lightning 同类选项的报道。

• ● Eclair #1982 引入新的日志文件记录需操作员干预的重要通知。配套说明指出应监控 notifications.log 文件。

• ● LND #5803 允许向同一原子多路径支付（AMP）发票发起多次自发支付，无需支付方重复操作。该功能为 AMP 独有，现有简化多路径支付实现无法支持。

• ● BTCPay Server #2897 新增支持 LNURL-Pay 支付方式，同时支持闪电地址。