本周的 Newsletter 描述了近期服务和客户端软件的更改，讨论了为何钱包应暂缓生成 Taproot 地址，列出了新软件发布与候选版本，并总结了热门比特币基础设施软件的显著变更。

新闻

本周无重要新闻。

服务和客户端软件的更改

本栏目每月重点介绍比特币钱包和服务的趣味更新。

• ● 闪电网络驱动的新闻网站 Stacker News 上线： 开源新闻网站 Stacker News 发布，支持 LNURL 身份验证以及通过闪电网络微支付进行投票和评论。

• ● Suredbits 宣布 DLC 钱包 alpha 版本发布： Suredbits 的 bitcoin-s 软件包含 GUI，支持通过预言机在比特币区块链上执行离散日志合约（DLCs）。公告最后提到，他们还计划使用 schnorr 签名和 PTLCs 来实现兼容闪电网络的 DLC。

• ● Sparrow 1.4.3 支持 P2TR： Sparrow 的 1.4.3 版本 在 signet 和 regtest 上支持单签 P2TR 钱包。该版本还支持向 P2TR 的 bech32m 地址发送。

• ● Coldcard 固件新增 Seed XOR 功能： Coldcard 的 4.1.0 固件 支持 Seed XOR，这是一种分割/组合 BIP39 种子（助记词）的方法，每个部分均可作为独立钱包使用。组合后的 XOR 结果也可作为钱包使用，从而实现蜜罐资金和合理否认等特性。

• ● BlueWallet 集成 Lightning Dev Kit： BlueWallet 宣布转向新的闪电网络实现，现使用 Lightning Dev Kit (LDK)。

准备 Taproot #5：我们为什么要等待？

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

本系列之前的文章鼓励钱包和服务开发者立即开始实施 Taproot 升级，以便在 Taproot 激活时准备就绪。但我们也警告不要在区块 709,632 前生成任何 P2TR 地址，否则可能导致服务或用户资金损失。

不建议提前生成地址的原因是，在区块 709,632 之前，任何发送至 P2TR 式输出的资金均可被任何人花费。这些资金将完全无安全保障。但从该区块开始，数千个全节点将开始强制执行 BIP341 和 BIP342（以及关联的 BIP340）的规则。

如果区块链重组能被完全排除，那么在看到最后一个 Taproot 前区块（区块 709,631）后立即生成 P2TR 地址是安全的。但存在对区块链重组的担忧——不仅是意外重组，还包括蓄意制造以窃取早期 P2TR 支付的资金。

设想大量用户希望成为首批接收 P2TR 支付的人。他们在看到区块 709,631 后立即天真地向自己发送资金。¹ 这些资金在区块 709,632 中是安全的，但可能被创建替代 709,631 区块的矿工窃取。如果发送至 P2TR 输出的资金价值足够大，尝试挖两个区块而非一个可能变得更为有利可图（详见手续费狙击主题）。

因此，在重组风险有效消除前，我们不建议软件或服务生成 P2TR 地址。我们认为等待激活后 144 个区块（约一天）是较为保守的安全边际，可在最小化风险的同时避免显著延迟用户享受 Taproot 优势。

简言之：

• 709,631: 最后一个允许任何人花费 P2TR 式输出资金的区块
• ● 709,632: 首个要求 P2TR 输出必须满足 BIP341 和 BIP342 规则才能被花费的区块
• ● 709,776: 钱包可开始为用户提供 P2TR 输出的 Bech32m 接收地址的合理区块

以上均不影响本系列首篇文章的建议——应尽快支持向 Bech32m 地址付款。若有人在您认为安全前请求向 P2TR 地址付款，风险由其自行承担。

发布与候选发布

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

• ● LND 0.13.1-beta 是维护版本，包含对 0.13.0-beta 引入功能的微小改进和错误修复。

• ● Rust-Lightning 0.0.99 是包含若干 API 和配置变更的版本。详见其发布说明。

• ● Eclair 0.6.1 是包含性能改进、新功能和错误修复的新版本。除发布说明外，可参阅下文显著变更栏目中关于 Eclair #1871 和 #1846 的描述。

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

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

• ● Bitcoin Core #22112 将 I2P 地址的默认端口从 8333（IPv4 和 IPv6 的默认端口）改为 0，并禁止连接端口非 0 的 I2P 地址。SAM v3.1 规范（Bitcoin Core 支持的版本）未包含端口概念。若未来 Bitcoin Core 支持包含端口概念的 SAM v3.2，此限制可能解除。

• ● C-Lightning #4611 更新插件提供的 keysend RPC，新增 routehints 参数用于为未公开通道的路由支付提供信息。

• ● C-Lightning #4646 为移除旧有行为做两项准备：首先默认节点支持 2019 年添加的 TLV 编码（参见 Newsletter #55），仅明确声明不支持 TLV 编码的节点会被区别对待；其次强制要求支付密钥（参见 Newsletter #75 的先前讨论及 Newsletter #126 中 LND 开始要求该功能的描述）。

• ● C-Lightning #4614 更新 listchannels RPC，新增可选 destination 参数用于仅返回通向指定节点的通道。

• ● Eclair #1871 修改其 SQLite 设置，将每秒可处理的 HTLC 数量提升 5 倍，并增强抗数据丢失能力。PR 中引用了 Joost Jager 对比不同节点软件 HTLC 吞吐量的博客文章。

• ● Eclair #1846 新增对预先关闭脚本（节点在协商新通道时指定的地址，远程节点同意该地址为后续通道互关的唯一可用地址）的可选支持。另见 Newsletter #76 中关于 LND 实现此功能的描述。

• ● Rust-Lightning #975 将基础支付转发费设为可配置，默认值为 1 聪（截至 2021 年 7 月的市场费率）。闪电网络路由节点可收取两种费用：固定基础费或路由金额的百分比，多数节点两者兼用。此前 Rust-Lightning 将基础费设为预估的链上结算 HTLC 所需费用，远高于 1 聪。

• ● BTCPay Server #2462 优化了通过 BTCPay 追踪外部钱包支付的功能，例如当实例运营者希望使用个人钱包进行退款时。

脚注

1. 若用户希望在首个 Taproot 区块接收 P2TR 支付，应生成一个不与他人共享的地址，并创建 nLockTime 设为 709,631 的交易。该交易可在收到区块 709,631 后立即广播。nLockTime 将确保交易无法在 Taproot 规则生效的 709,632 前被包含。若未充分理解新脚本类型和自定义锁定时间，此类操作可能存在风险，请谨慎处理。 ↩