本周的 Newsletter 总结了关于将闪电网络（LN）通道基本费用设为零的讨论，并包含我们定期更新的内容，包括来自 Bitcoin Stack Exchange 的热门问答、如何为 Taproot 做准备、新发布和候选发布版本，以及流行比特币基础设施项目的值得注意的更改。

新闻

  • ● 零基本费用 LN 讨论： 在闪电网络协议中，支付方可以自行决定向每个成功路由付款的节点支付多少费用。而路由节点则可以选择拒绝任何未提供足够费用的支付请求。为了使这种责任划分有效，路由节点需要向支付方传达其期望的费用。因此，BOLT7 允许路由节点公布两个与费用相关的参数：fee_base_msat（基本费用）和 fee_proportional_millionths（按比例费用）。

    由 René Pickhardt 和 Stefan Richter 撰写的一篇近期论文提出了一种新的路径查找技术，该技术可以帮助支付方最小化费用，并减少成功发送付款所需的尝试次数（以及其他优势）。然而，在当前网络上部署该技术会遇到两个与 LN 基本费用和多路径支付相关的问题：

    • ● 更多的拆分，更多的费用： 比较单路径支付与相同金额的双路径支付：两者支付的总按比例费用相同（因为总支付金额相同），但双路径支付的总基本费用将是单路径支付的两倍（因为使用了两倍的跳数）。如果使用 x 条等效路径，则基本费用将是 x 倍。这使得多路径支付的成本更高，从而对依赖多路径支付的技术（如该论文提出的方法）产生了不利影响。

    • ● 计算上的困难： 论文的第 2.3 节描述了所提出的路径查找算法在存在基本费用时难以计算路径和支付拆分。从长期来看，可能可以通过算法解决这个问题，但对该算法的实现者而言，最简单的解决方案就是取消基本费用。

    在播客和Twitter上，该论文作者建议，如果节点运营者将其基本费用设为零，即使无需立即更改 LN 协议，也可以解决这个问题。他们进一步建议，尽管其研究成果尚未在生产环境中部署，但运营者可以立即开始这样做。这引发了 LN 开发者在 Twitter 上的多次讨论，Anthony Towns 将讨论迁移到 Lightning-Dev 邮件列表，并发表了一篇帖子。

    Towns 支持用户将基本费用设为零，认为这不仅有助于多路径拆分，还能让节点运营者更容易优化唯一剩下的费用参数，即按比例费用。

    Matt Corallo 回复表示担忧，认为用于路由支付的 HTLC 会给节点带来若干成本，而这些成本与支付金额无关。基本费用允许节点确保这些成本得到补偿。然而，Towns 反驳称，无论支付是否成功，这些成本基本相同，而 LN 节点仅在支付成功时才能获得报酬。如果节点在某些情况下愿意承担这些成本而不获得补偿，为什么不能在所有情况下都接受呢？不过，这同样适用于按比例费用，因此讨论进一步涉及到预付费，这种方式可以让节点即使在支付失败的情况下也能获得补偿。

    Towns 还提出，即使没有基本费用，节点仍然可以确保自己获得最低费用，例如简单地拒绝路由低于某个金额的支付。例如，一个当前基本费用为 1 sat 的节点可以通过设定 0.1% 的按比例费用和 1,000 sat 的最低支付金额来确保至少获得 1 sat。虽然这会抑制微支付，但 LN 节点已经能够在不使用 HTLC 的情况下处理小额支付，从而消除一些固定成本，并可能使纯按比例费用更合理，但这一点仍在讨论之中。

    在后续讨论中，Olaoluwa Osuntokun 强调了一个早前提出的观点，即目前并没有迫切需要节点运营者调整参数，以支持一个尚未准备好在生产环境中使用的新路径查找算法。他和 Corallo 希望进一步研究和开发，看看该算法（或基于不同原理的类似算法）是否能在基本费用非零的情况下同样良好地运行。

    截至撰写本文时，该讨论尚未达成明确结论。

Bitcoin Stack Exchange 精选问答

Bitcoin Stack Exchange 是 Optech 贡献者寻找问题答案的首选平台之一——或者当我们有空时，会帮助好奇或困惑的用户。在本月的特色内容中，我们重点介绍自上次更新以来发布的一些高票问题和答案。

准备 Taproot #10：PTLCs

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

在上周的专栏中，我们探讨了签名适配器，以及 Taproot 与 Schnorr 签名的激活将如何使适配器的使用更加私密和高效。签名适配器可以在比特币上以多种方式应用，其中最直接受益的用例之一是点时间锁定合约（Point Time Locked Contracts，简称 PTLCs），它可以替代多年来使用的哈希时间锁定合约（HTLCs）。这将带来多个优势，但也伴随着一些挑战。为了理解两者，我们首先从一个简化的 HTLC 示例开始，该示例适用于链下 LN 支付、链上 CoinSwap，或像 Lightning Loop 这样结合链上和链下的混合系统——正是这种灵活性，使得 HTLC 被广泛使用。

Alice 想通过 Bob 向 Carol 支付，但 Alice 和 Carol 都不想信任 Bob。Carol 生成一个随机的前镜像（preimage），并使用 SHA256 算法对其进行哈希。然后，Carol 将哈希值提供给 Alice，并保留前镜像的秘密。Alice 发起支付给 Bob，Bob 可以使用自己的公钥签名加上前镜像来领取资金；或者，在 10 个区块后，Alice 可以使用自己的公钥签名将交易退还给自己。以下是用 Minsc 语言描述的该 HTLC 逻辑：

(pk($bob) && sha256($preimage)) || (pk($alice) && older(10))

随后，Bob 可以使用几乎相同的脚本向 Carol 发起支付（可能扣除一些费用），但角色相应调整，并且退款超时更短：

(pk($carol) && sha256($preimage)) || (pk($bob) && older(5))

现在，Carol 可以在 5 个区块内使用前镜像领取来自 Bob 的付款，这会将前镜像暴露给 Bob，使得 Bob 也能在 5 个区块内使用它向 Alice 领取付款。

HTLC 的隐私问题

如果上述脚本在链上发布，由于相同的哈希和前镜像被重复使用，观察者可以立即看出 A 通过 B 向 C 付款。这对于同链和跨链的 CoinSwap 可能是个重大问题。不那么明显的是，这对 LN 等链下路由协议也是个问题。如果一个路径较长的支付中，有人控制多个跳数，他们可以通过检测相同的哈希和前镜像的重复使用来识别哪些节点是路由节点，从而推测出其余节点很可能是支付方或接收方。这是 可链接性问题（linkability problem）的一个组成部分，而这可能是 LN 目前最大的隐私弱点。

HTLC 可链接性问题示意图

虽然多路径支付（MPP）在一定程度上缓解了 LN 付款金额的可链接性问题，但它可能会加剧哈希可链接性问题，因为它给了监听节点更多机会来关联哈希值。

HTLC 的另一个问题是，任何需要链上执行的脚本都会与普通的支付脚本明显不同。这使得监测者更容易识别使用模式，并可能有效推测特定用户的信息。

PTLC 解决方案

在前面的 Minsc 脚本中，我们使用了一个函数，只有在传入一个预先选择的特定值（前镜像）时，该函数才会返回 true。而签名适配器（signature adaptors） 也有类似的特性——它们只有在传入一个特定值（标量）时，才能转换成有效签名。如果暂时忽略多重签名，我们可以将 HTLC 脚本转换为以下 PTLC 形式：

(pk($bob) && pk($alice_adaptor)) || (pk($alice) && older(10))

(pk($carol) && pk($bob_adaptor)) || (pk($bob) && older(5))

简单来说，Carol 给 Alice 一个椭圆曲线（EC）点，它对应一个隐藏的标量。Alice 使用该点和她选择的公钥创建一个签名适配器并交给 Bob；Bob 再使用相同的点和自己选择的公钥创建另一个适配器交给 Carol。Carol 通过转换 Bob 的适配器为有效签名来揭示标量，从而领取 Bob 的资金。随后，Bob 从 Carol 的有效签名中恢复该标量，并使用它转换 Alice 的适配器为有效签名，以领取 Alice 的资金。

这解决了链上监测的可链接性问题，因为区块链上展示的只是不同公钥对应的有效签名。第三方无法知道是否使用了适配器签名，更无法得知适配器的标量值。

然而，上述流程并不能防止参与路由的监听节点关联支付。如果所有支付都基于相同的标量，它们的可链接性就与使用哈希锁和前镜像一样高。为了解决这个问题，每个路由节点可以选择自己的标量，并在支付通过该节点时移除相应的点。我们修改示例如下：

和之前一样，Carol 给 Alice 一个点，但这次 Alice 还向 Bob 请求一个点。Alice 构造的适配器包含 Carol 的点和 Bob 的点的聚合。Bob 知道自己的点，因此可以从 Alice 传来的适配器中移除它。这样，Bob 得到的结果（他不知道的是，这实际上只是 Alice 从 Carol 那里获得的点），用于创建他给 Carol 的适配器。Carol 知道最终的标量，所以可以转换 Bob 的适配器为有效签名。Bob 从 Carol 的签名中恢复 Carol 的标量，并结合自己的标量转换 Alice 的适配器为有效签名。

在 Alice→Bob 和 Bob→Carol 这两个跳数中，使用了不同的 EC 点和标量，消除了可链接性。扩展到更长的路径后，我们可以看到隐私性的改进：

PTLC 取消可链接性示意图

正如上周提到的，Schnorr 签名使得将适配器签名与多重签名结合变得简单。对于一般的 PTLC，这使得链上的脚本可以进一步简化为：

pk($bob_with_alice_adaptor) || (pk($alice) && older(10))

pk($carol_with_bob_adaptor) || (pk($bob)   && older(5) )

在 Taproot 方案下，左分支可以成为密钥路径（keypath），右分支可以成为 Tapleaf。如果支付成功路由，Bob 和 Carol 可以在链上结算，而无需对手方进一步配合，从而使此类路由支付与单签支付、普通多重签名支付和合作解决的合约难以区分，同时还能最大化节省区块空间。如果需要执行退款条件，这种方式仍然相当高效，并具有良好的隐私性——pk(x) && older(n) 代码与降级多签、强制持币等多种可能的脚本难以区分。

在下周的专栏中，我们将邀请一位我们最喜爱的 LN 开发者撰写客座文章，讨论 LN 采用密钥路径支付、多重签名、PTLCs 以及 Taproot 启用的其他特性的必要变更。

发布与候选发布

流行的比特币基础设施项目的新发布和候选发布版本。请考虑升级到新版本或帮助测试候选版本。

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

本周在 Bitcoin Core、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、硬件钱包接口 (HWI)、Rust Bitcoin、BTCPay Server、比特币改进提案 (BIPs)和闪电网络规范 (BOLTs)中的一些值得注意的变化。

  • ● Bitcoin Core #22541 添加了一个新的 restorewallet RPC 命令，可用于加载钱包备份。restorewallet 补充了现有的 backupwallet 命令，后者用于导出当前加载的钱包的副本。请注意，backupwallet 和 restorewallet 是旧版 dumpwallet 和 importwallet RPC 的替代方案，后者使用单独的文件。此工作伴随对 Bitcoin Core #22523 的文档进行了全面更新，涵盖了备份和恢复钱包的相关内容。

  • ● LND #5442 允许向 PSBT 添加输入，而无需添加任何新的输出，这对于创建 CPFP 手续费提升非常有用。

  • ● Rust-Lightning #1011 增加了对尚未合并的 BOLTs #847 的支持，该提案允许两个通道对等方协商共同关闭交易应支付的费用。在当前协议中，仅发送一个费用，另一方必须接受或拒绝该费用。

  • ● BOLTs #887 更新了 BOLT11，要求支付方在进行支付时必须指定支付密钥，无论接收方是否启用了 payment_secret 功能位。接收方应验证支付密钥，以防止在简化的多路径支付中出现探测攻击。这个验证已在我们涵盖的所有四个闪电网络实现中得以实现。