本周周报概述了关于向频繁离线的闪电网络节点支付的讨论主题，描述了旨在降低闪电网络支付路径探测成本以提高特定攻击实施成本的提案集，并提供了在 signet 和 testnet 上创建 Taproot 交易的操作指南链接。同时包含常规栏目：近期客户端和服务更新、新版本与候选版本发布，以及主流比特币基础设施软件的显著变更。

新闻

  • ● ​向离线闪电网络节点支付：​ Matt Corallo 在 Lightning-Dev 邮件列表发起了一个讨论，探讨如何让频繁离线的闪电网络节点（例如移动设备上的节点）无需托管方案或长期锁定通道流动性即可接收支付。Corallo 认为一旦闪电网络升级支持 PTLCs，即可通过不可信第三方实现合理解决方案，但他也在寻求其他替代方案建议，以在 PTLC 支持之前部署。

  • ● ​通过降低探测成本提高攻击成本：​ 开发者 ZmnSCPxj 和 Joost Jager 在几周内分别提出了相似的提案，旨在消除支付路径探测需要锁定资金的要求。两项提案均建议将此作为添加预支付路由费（upfront routing fees）的第一步——即使支付失败也会产生费用。预付费是应对通道阻塞攻击的缓解措施之一。

    当前闪电网络节点可通过发送必然失败的支付来探测路径。例如 Alice 生成一个使用未知原像的 HTLC，通过 Bob 和 Charlie 路由至 Zed。由于 Zed 未知原像，即使作为最终接收方也必须拒绝该支付。若 Alice 收到 Zed 节点的拒绝信息，则说明 Bob 和 Charlie 的通道有足够资金向 Zed 支付，从而可立即发送实际支付（失败仅可能因流动性变化）。Alice 使用必然失败的探测支付优势在于可并行探测多条路径并使用最先成功的路径，减少整体支付时间。主要缺点在于每次探测会暂时锁定 Alice 和中继节点（如 Bob 和 Charlie）的资金——并行探测长路径可能锁定支付金额的 100 倍以上。次要缺点是此类探测可能导致不必要的单边通道关闭及链上费用。

    ZmnSCPxj 和 Jager 提议允许发送无需 HTLC、临时锁定比特币或引发通道关闭的特殊探测消息。该消息基本可免费发送（ZmnSCPxj 的提案包含防 DoS 洪泛攻击措施）。

    若免费探测确实能帮助节点找到高可靠路径，两位提案者认为开发者和用户应更愿意接受预付费机制（支付失败时产生小额成本）。这种诚实用户偶尔的小额成本将成为恶意节点大规模阻塞攻击的巨额成本，从而降低攻击风险（并为路由节点运营商在遭受持续攻击时部署额外资金提供补偿）。

    截至发稿时，该提案已引发适度讨论。

  • ● ​测试 Taproot：​ 针对 Bitcoin-Dev 邮件列表的请求，Anthony Towns 提供了在 Bitcoin Core 上为 signet 或 testnet 创建 bech32m 地址的分步指南。该指南可能比 Optech 此前提供的更适合开发者测试 taproot。

服务和客户端软件的更改

本栏目每月精选比特币钱包和服务的有趣更新。

  • ● ​​Zeus 钱包新增闪电网络功能：​ 移动端比特币和闪电网络钱包 Zeus 在 v0.6.0-alpha3 版本中新增对原子化多路径支付（AMP）、闪电网络地址和币选择功能的支持。

  • ● ​​Sparrow 新增 Coinjoin 支持：​ Sparrow 1.5.0 通过集成 Samourai 的 Whirlpool 新增 Coinjoin 功能。

  • ● ​​JoinMarket 修复做市商关键漏洞并支持 RBF：​ JoinMarket 0.9.3 修复了做市商的关键漏洞，建议所有做市商升级。0.9.2 版本默认在 UI 中使用保真债券并支持对非 Coinjoin 交易使用 RBF。

  • ● ​​Coldcard 支持描述符钱包：​ Coldcard 4.1.3 现支持 Bitcoin Core 的 importdescriptors 命令，实现了描述符钱包和基于 PSBT 的工作流。

  • ● ​​Simple Bitcoin Wallet 新增 CPFP、RBF 和 hold invoices：​ Simple Bitcoin Wallet（原 Bitcoin Lightning Wallet）在 2.2.14 版本新增 CPFP 和 RBF 功能，并在 2.2.15 版本支持 hold invoices。

  • ● ​​Electrs 0.9.0 发布：​ Electrs 0.9.0 现改用比特币 P2P 协议替代从磁盘或 JSON RPC 读取区块。用户升级时请参考升级指南。

准备 Taproot #18：琐事

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

  • ● ​​什么是 Taproot？ 维基百科解释：”主根（taproot）是一种大型、中心化且占主导地位的根系，其他根须从其侧面生长。典型的主根较为笔直粗壮、呈锥形且垂直向下生长。某些植物（如胡萝卜）的主根作为储存器官高度发达，已被培育为蔬菜。”

    这与比特币有何关联？

    • ● ​“我一直认为这个名字源于’接入默克尔根（taps into the Merkle root）’，但实际并不清楚 Gregory Maxwell 的命名思路。” ——Pieter Wuille（来源）

    • ● ​“我最初不得不查阅这个词的含义；但将其理解为密钥路径是’主根’，因为这是可食用的部分（用于制作胡萝卜汤），而默克尔化的脚本则是其他次要根须（希望被忽略）。” ——Anthony Towns（来源）

    • “该名称源自对蒲公英主根般粗壮中心树干的视觉化想象——该技术的主要价值在于假设存在一条高概率路径（其他为杂乱次要路径）。此外，’taproot’ 的双关含义也贴切，因为其通过根部的隐藏承诺来验证脚本路径支付。

      […] 可惜，将带有排序内部节点的哈希树称为’myrtle 树’（取自桃金娘科，含茶树等）并未流行，尽管其发音类似’merkle’且有数学排列特性。” ——Gregory Maxwell（来源）

  • ● ​​Schnorr 签名早于 ECDSA：​ 尽管我们将 schnorr 签名 视为比特币原始 ECDSA 签名的升级（因其更易实现密码学技巧），但 schnorr 签名算法其实早于 ECDSA 所基于的 DSA 算法。事实上，DSA 的创建部分是为了规避 Claus Peter Schnorr 的 schnorr 签名专利，但 Schnorr 仍声称“我的专利适用于各类离散对数签名实现，包括 Nyberg-Rueppel 和 DSA”。目前无法院支持此主张，且其专利已于 2011 年过期。

  • ● ​​命名争议：​ 在比特币采用 schnorr 签名的早期，曾有建议避免使用 Schnorr 之名，因其专利阻碍了该密码学技术的普及。Pieter Wuille 解释：”我们曾考虑将 BIP340 命名为’DLS’（离散对数签名），但最终因 Schnorr 之名已被广泛讨论而未采纳。”

  • ● ​​扭曲爱德华曲线的 Schnorr 签名：​ 2011 年发布的 EdDSA 方案将 schnorr 签名应用于椭圆曲线，现已成为多项标准的基础。虽然未用于比特币共识层，但 Optech 追踪的多个比特币代码库中可见其相关引用。

  • ● ​​支付到合约：​ Ilja Gerhardt 和 Timo Hanke 在 2013 年圣何塞比特币大会上提出的协议， 允许支付承诺至合约哈希。持有合约和防攻击随机数的任何人都可验证该承诺，但对他人而言该支付与普通比特币支付无异。

    2014 年侧链论文中的改进版 P2C 额外承诺原始公钥。Taproot 采用相同结构，但其承诺对象为接收方设定的链上花费条件（而非链下合约条款）。

  • ● ​​灵感诞生地：​ 使脚本支付与公钥支付在链上表现相同的 P2C 创意，由 Andrew Poelstra 和 Gregory Maxwell 于 2018 年 1 月 22 日在加利福尼亚州洛斯阿尔托斯的 “A Good Morning” 餐厅构思。Pieter Wuille 回忆：”这个想法在我暂时离开餐桌时诞生… !$%@” [原文如此]

  • ● ​​2.5 年浓缩至 1.5 天：​ 确定 bech32m 的最佳常数消耗了约 2.5 年 CPU 时间，最终借 Gregory Maxwell 的 CPU 集群在 1.5 天内完成计算。

感谢 Anthony Towns、Gregory Maxwell、Jonas Nick、Pieter Wuille 和 Tim Ruffing 为本栏目提供的见解。文中错误由作者负责。

发布与候选发布

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

  • ● BDK 0.12.0 新增 Sqlite 数据存储支持及其他改进。

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

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

  • ● Bitcoin Core #22863 记录了对 P2TR 输出采用与 P2WPKH 输出相同的最小输出金额（”粉尘金额”）294 sat 的决策。尽管花费 P2TR 输出成本更低，但部分开发者反对此时降低粉尘限额。

  • ● Bitcoin Core #23093 新增 newkeypool RPC 方法，可将所有预生成地址标记为已使用并生成新地址集。多数用户无需此功能，但该行为会在用户从非 BIP32 钱包升级至 HD 密钥生成 时在后台使用。

  • ● Bitcoin Core #22539 将本地节点观察到的替换交易纳入手续费估算。此前因替换交易较少而未予考虑，但目前约 20% 的交易发送 BIP125 替换信号，日均发生数千次替换。

  • ● Eclair #1985 新增 max-exposure-satoshis 配置项，允许用户设置当通道因未解决的不经济输出被迫关闭时，愿意捐赠给矿工的最大金额。详情参见上周周报中关于 CVE-2021-41591 的描述。

  • ● Rust-Lightning #1124 扩展了 get_route API，新增可避免重用失败路径的参数。后续改进将利用历史路由成功率提升路径质量。

  • ● BOLTs #894 在规范中添加建议检查项。实现这些检查可防止在路由非经济链上支付时向矿工超额捐赠手续费。详见上周周报关于未实施检查可能引发的问题。