本周 Newsletter 介绍了一个基于网络端的 PSBT 解码与修改工具,并链接了一篇关于基于 eltoo 的闪电网络支付通道的博客文章及概念验证实现。同时包含关于准备 Taproot 的常规信息、新软件候选版本公告以及主流比特币基础设施项目的重要变更摘要。

新闻

  • ● BIP174.org: Alekos Filini 在比特币开发邮件列表发帖介绍了其与 Daniela Brozzoni 共同创建的网站,该网站可将部分签名的比特币交易(PSBT)解码为人类可读的字段列表。字段内容可被编辑并重新编码为序列化的 PSBT,帮助开发者快速测试其 BIP174 实现。Christopher Allen 建议该工具应支持生成二维码(标准码或用于处理超过 3 KB PSBT 的替代方案,参见 Newsletter #96)。

  • ● Eltoo 示例通道: Richard Myers 此前已基于 AJ Towns SIGHASH_ANYPREVOUT实现(参见 Newsletter #63)在比特币核心集成测试中完成 eltoo 通道的示例版本。其在比特币开发邮件列表提及的详细博客文章描述了 eltoo 通道可能使用的交易结构,结合集成测试代码,允许任何感兴趣者开始实验 eltoo 协议。文中还描述了多个改进方向供进一步研究。

准备 Taproot #11：使用 Taproot 的闪电网络

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

ZmnSCPxj，闪电网络协议开发者

本文将探讨 Taproot 为闪电网络带来的两大隐私特性:

  • 闪电网络上的 PTLCs
  • P2TR 通道

闪电网络上的 PTLCs

PTLC 可实现多项功能，其中对闪电网络而言，最大优势在于无需路径随机化即可实现支付解关联。1在单路径或多路径支付中，每个节点均可获得用于调整转发 PTLC 的特定参数，实现支付解关联，此举可消除各转发节点通过唯一哈希值关联具体支付的可能性。

需明确，PTLC 并非隐私万能解。若监控节点观察到特定时间锁和金额的支付转发后，短期内发现另一节点转发具有更短时间锁及稍小金额的支付，这些事件极可能为同一支付路径的组成部分(即便无法通过哈希值唯一标识进行关联)。然而，变更带来以下优势:

  • 分析难度提升：监控节点依据的关联概率降低，其信息价值相应减少。
  • 多路径支付的解关联增强：不同路径间的时间锁与金额关联性大幅减弱，且若闪电网络持续发展，海量支付将削弱时序关联的有效性。
  • 成本未增加：相较于 HTLC，PTLC 无需额外开销(甚至可能因多签效率优化稍有节约)。

理论而言，无需关闭现有通道即可通过链下交易将预-Taproot 通道升级至支持 PTLC。现有通道可通过将非 Taproot 资金输出转移至含 PTLC 的 Taproot 输出实现兼容。因此，用户无需承担额外成本，仅需节点及其通道对端升级软件即可支持 PTLC。

但 PTLC 的实际使用需支付路径中所有节点均支持该协议。这意味着需足够多节点完成升级后方可广泛采用。这些节点未必需支持同一 PTLC 协议(允许存在多个协议)，但均须至少支持一种。协议多样化将增加维护负担，开发者期望尽量减少协议数量(理想状态为单一协议)。

P2TR 通道

提升基础层与闪电网络层解关联的方案之一是未公开通道——此类通道不在闪电网络的 gossip 协议中广播。

但当前预-Taproot 的比特币网络中，所有 2-2 多签脚本均需明示编写。闪电网络作为 2-2 多签的最大用户，其通道的关闭交易极易被区块浏览器识别为闪电网络的链上活动，进而被追溯资金流向。任何新生成的 P2WSH 输出极可能为另一未公开通道。因此，未公开通道一旦关闭，仍存在链上识别的可能(伴随误判率)。

Taproot 借助 schnorr 签名使 n-of-n 多签交易与 1-of-1 单签交易在链上表现无异。经技术优化后，k-of-n 多签交易亦可实现等价匿名性。因此，我们可采用 Taproot 地址(即 P2TR 通道)作为闪电通道的链上基础，提升未公开通道的链上隐私。2

此(微小)隐私提升同样惠及公开通道。公开通道仅在存续期广播，监控者无法获取历史通道信息。若需追踪所有公开通道，需自行存储全部数据，无法依赖”归档”节点。

此外，Taproot 密钥路径交易比现有闪电网络 P2WSH 交易体积减少 38.5 vbytes(40%)。但需注意，现有 pre-taproot 通道无法升级至 P2TR 通道，因现有通道采用 P2WSH 2-2 模式，必须关闭后重新开启 P2TR 通道。

理论上，资金输出形式仅关乎通道双方节点。其他节点无需关心通道保证金的技术细节。但公开通道需通过 gossip 网络广播。节点收到通道信息后，将查询其信任的比特币全节点验证资金 UTXO 的存在性及地址正确性。地址验证机制可抵御垃圾通道的传播——需真实资金支撑才能发布通道信息。因此实践中，P2TR 通道仍需一定程度的远程兼容性，否则发送方将因无法验证存在性而忽略此类通道。

时间预估

在去中心化开源项目中，最佳时间预测法为参考历史类似功能的开发周期。近期重大特性中，与闪电网络 PTLC 复杂度相当的是 dual funding 协议。Lisa Neigut 在 BOLTs #524 中提出初始方案后，历时两年半完成首个主网 dual funding 通道。鉴于 PTLC 需全网路径节点兼容(包括接收方)，预估在具体协议提案后需三年零九个月实现广泛采用。

P2TR 通道虽仅需两节点支持，但其收益较低，故开发优先级受限。多数开发者将优先实现 PTLC 支持，预计 P2TR 通道的开发将在 SIGHASH_ANYPREVOUT 或 Decker-Russell-Osuntokun(Eltoo)方案落地后展开。

发布与候选发布

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

  • ● Bitcoin Core 22.0rc3 是此全节点实现及其关联钱包等软件的下一主要版本候选。该版本主要变更包括支持 I2P 连接、移除对 Tor v2 的支持,以及增强硬件钱包兼容性。

  • ● Bitcoin Core 0.21.2rc2 是比特币核心维护版本的候选发布。包含多个错误修复与小改进。

重要代码与文档变更

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

  • ● Bitcoin Core GUI #384 新增在”封禁节点表”中复制 IP/子网掩码的右键菜单选项。该功能让 GUI 用户更方便地分享封禁列表中的地址。

    GUI 复制 IP/子网掩码的右键菜单选项截图

  • ● C-Lightning #4674 新增 datastore、deldatastore 和 listdatastore 命令,供插件在数据库中存储和管理数据。同时更新了各命令语义的手册页。

  • ● LND #5410 允许节点建立与非 Tor 服务的直连,桥接仅限 Tor 和仅限明文网络的网络段。

  • ● LND #5621 在 ping 消息的ignored字段中包含最高工作量区块头信息。对端节点可利用此数据进行额外验证,确保其区块链视图处于最新状态且未遭受日蚀攻击。未来工作可将此数据源用于用户提醒或自动恢复机制。

脚注

  1. 付款方可选择复杂路径(路径随机化)弱化 HTLC 关联分析，然存在弊端:

    • 复杂路径不仅成本更高且可靠性下降(需要支付更多转发节点费用,同时依赖更多节点成功完成转发)。
    • 路径延伸导致支付信息被暴露于更多节点,大幅增加遭遇监控节点的可能性。 因此路径随机化非完美隐私解决方案。

    ↩

  2. 在考虑未公开通道时，记住需要“二人共舞”，如果一个未公开通道被关闭，那么其中一个参与者（例如，一个闪电网络服务提供商）将剩余的资金用于一个公开通道，区块链浏览器可以推测这些资金的来源有一定概率是曾经关闭的未公开通道。 ↩