HTLC已死 闪电网络可能幸存 LN on Drivechain是LN出路之一

来源：LayerTwo Labs

核心开发者Antoine Riard退出闪电网络，声称闪电网络代码中故意存在后门，使攻击者能够完全控制网络，称其存在巨大安全风险须比特币底层改动来fix。

比特币扩容方案闪电网络近日被爆出”巨大的安全问题”，开发者 Antoine Riard 宣布退出。

24 小时内 闪电网络“损失情况”

闪电网络被曝巨大安全漏洞

据 Cointelegraph 报道:Bitcoin core developer steps back from Lightning Network over ‘hard dilemma’^[1]，比特币安全研究人员和比特币开发者 Antoine Riard 因安全问题和比特币生态系统面临的根本挑战而退出闪电网络的开发，他认为比特币社区面临着「艰难困境」，因为一类新的替代循环攻击将闪电网络置于「危险的境地」。

替代循环攻击是一种新型攻击，攻击者可以利用各个内存池之间的不一致来窃取支付通道参与者的资金，他指出解决新型攻击可能需要对底层比特币网络进行更改，「这些类型的变化需要整个社区的最大透明度和认同，因为我们正在改变全节点处理要求或去中心化比特币生态系统的安全架构」。

一份 Antoine Riard 的邮件截图^[2]也被曝光，截图显示，Riard 在邮件中称比特币闪电网络存在巨大的安全风险，他声称代码中故意存在后门，使攻击者能够完全控制网络，这促使他宣布退出该项目。

Riard 的邮件内容如下：

在写完关于连续恶意替换诚实 HTLC-Timeout的经济学的邮件回复后，我确实又编写了一个测试来验证核心内存池上的行为，而它如我预料的那样发生了。

https://github.com/ariard/bitcoin/commit/30f5d5b270e4ff195e8dcb9ef6b7ddcc5f6

负责任的披露流程遵循了影响操作系统的硬件问题（如 Linux 内核所述），同时适应了比特币生态系统：https://docs.kernel.org/6.1/process/embargoed-hardware-issues.html

从现在起，我将停止参与闪电网络的开发及其实现，包括协调协议级别安全问题的处理（我通知了一些高级闪电开发人员）。

关闭了在存储库上影响我很长时间的问题：https://github.com/lightning/bolts/pul1/772

我认为这种新的替换循环攻击将闪电网络置于非常危险的位置，其中只有在基础层才能进行可持续的修复，例如添加所有可见交易的内存密集型历史记录或某些共识升级。

面对简单的攻击，部署的缓解措施是有价值的，尽管我不认为它们能够阻止高级攻击者，正如第一封完整披露邮件中所述。这些类型的变化需要最大程度的透明度和整个社区的支持，因为我们正在改变全节点处理要求或去中心化比特币生态系统的完整性安全架构。

另一方面，要充分解释为什么为了闪电网络和良好的设计而需要进行此类更改，我们可能需要对约 5355 个公共 BTC 生态系统进行完整的实际和关键攻击。艰难的困境。在比特币协议部署方面可能有一个教训，我们可能必须在第一次尝试时就把它们做好。在飞行中修复它们的第二次机会很少。

我将在 10 月 30 日那周之前对公共邮件列表上的这些问题保持沉默，我已经发布了足够的材料，并且有其他专家可用。我将重新更多地关注Bitcoin Core。”

开发者详解攻击方式

另一位开发者 @mononautical^[3] 详细解释了这个攻击的原理，并表示这种攻击要发起不容易，但要解决他也非常的困难。 正确的修复可能需要更根本的改变，重新设计 HTLC 协议，或者更改中继策略以传播替换的事务，或者让矿工保留最近替换的交易的缓存，又或者在新操作码中进行软分叉。

@mononautical 对攻击的解释原文（https://twitter.com/mononautical/status/1715736832950825224）：

闪电替代循环攻击如何运作？邮件列表上有很多关于这个新发现的漏洞的讨论，但实际机制有点难以理解。所以这里有一个图解入门…

假设Bob正在将一笔闪电付款从Alice路由到Carlo。在飞行过程中，付款受到 HTLC 输出的保护，HTLC 输出是他与每个同行预先签署的通道承诺中的。

HTLC（哈希/时间锁定合约）是发送者到接收者的有条件付款。接收方可以通过向哈希 H 揭示原像来立即使用它，或者在超时后由发送方回收。

通过使用相同的哈希锁保护每一跳上的 HTLC，可以自动路由支付。Carol 无法在不泄露原像的情况下领取传出的 HTLC，然后 Bob 可以使用原像兑换来自 Alice 的传入 HTLC。至少理论上是这样的……

为了确保 Bob 在出现问题时有时间做出反应，传出 HTLC 上的时间锁首先在某个区块高度 T 到期。然后传入 HTLC 上的时间锁在稍后的某个高度 T+Δ 到期，之后Alice就可以收回她的钱了。

好的，攻击如下：记住 Bob 在两个通道中都有待处理的 HTLC。一份发给 Carol 的传出 HTLC，在区块 T 到期，一份来自 Alice 的传入 HTLC，在区块 T+Δ 到期。

在 T 区块，Carol 仍未透露用于结算付款的原像，因此 Bob 被迫在链上超时。他广播承诺 tx 来关闭他与 Carol 的频道，一旦确认，就会发送一个“HTLC-Timeout”tx，花费 HTLC 来收回他的资金。

Bob 不知道的是，Alice 和 Carlo 正在串谋偷他的钱。他们通过以低费用广播两笔交易的链来准备攻击，这显然与闪电通道无关，我们将其称为“循环父项”和“循环子项”。

一旦攻击者看到 Bob 的 HTLC-Timeout 交易命中内存池，他们就会广播一个“HTLC-preimage”交易，该交易既花费 HTLC 输出（使用 Carol 的哈希原像），又花费来自循环父节点的输出。

由于此 HTLC-preimage 交易支付更高的费用并花费相同的输入，因此它取代了内存池中的循环子项和 Bob 的 HTLC-Timeout 交易。

如果 Bob 看到这一点，他可以获取原像并使用它立即兑换来自 Alice 的传入 HTLC。因此，攻击者广播一个新交易来替换循环父代。HTLC 原像依赖于其输入之一，因此也被从内存池中逐出。

在此周期结束时，Bob 与 Carol 的通道中的 HTLC 最终未使用，并且内存池中没有 HTLC-Timeout 和 HTLC-preimage 交易的痕迹。

攻击者每次重播 Bob 的 HTLC-Timeout 交易时都会重复这个循环。如果他们阻止它被开采出另一个 Δ 块，Alice 可以使另一个通道上的 HTLC-Timeout，并让 Bob 损失全部支付金额。

这次攻击并不容易。实现这一目标需要：

• 与受害者打开两个渠道。

• 通过他们进行付款。

• 成功替换循环受害者的 HTLC-Timeout Δ 块。

• 受害者没有发现 HTLC 原像交易。

但这也很难完全解决。更积极地增加时间锁增量或重新广播 HTLC-Timeout会使攻击更加困难且成本更高，但仍然不是不可能。

Bob 可以主动监控他的本地内存池，以便在 HTLC-Timeout 被替换之前发现它。但聪明的攻击者可以有选择地广播替换内容，以便矿工收到它们，而 Bob 却没有收到。

也许Bob可以通过使用连接到网络其他部分的瞭望塔来监视循环的 HTLC-Timeout 并向他转发任何相关的原像，从而提高他的机会。

正确的修复可能需要更根本的改变。我们可以重新设计 HTLC 协议，以防止向 HTLC 原像添加额外的输入（因此它们无法被替换）。或者更改中继策略以传播替换的事务（因此原像始终到达 Bob）。

或者让矿工保留最近替换的交易的缓存，这些交易稍后可能能够重新进入内存池（这样Bob就不需要重新广播他的 HTLC-Timeout）。这可以内置到比特币核心中，或作为外部服务运行。

或者在新操作码中进行软分叉，其作用与 check-locktime-verify 相反（因此我们可以在时间锁到期后立即使 HTLC-preimage 花费路径无效）。

此攻击仅适用于直接对等点，并导致该通道关闭。如果您不路由付款，您的节点就是安全的。否则，您可以通过降低与您真正不信任的同行的频道的最大飞行 HTLC 值来限制最坏的情况。

社区动态

慢雾创始人余弦也发推表示了同样的观点： 闪电网络的替换循环攻击有些类似 MEV 里的三明治攻击，前后夹击套出被夹目标的资金。这一攻击不容易利用，需要满足：在受害者身上打开两个通道；通过这两个通道中的其中一个路由付款；成功替换循环受害者的 HTLC-Timeout blocks；受害者不会发现 HTLC 预映像交易。这个风险在被修复之前，使用闪电网络的项目方在对接上下游建立通道前可以警惕下，最好和有信誉的建立，降低被夹风险，具体还需要测试和验证。

在事件被曝光之后，一些针对闪电网络的批评也再次被提起。

@Justtherip：https://twitter.com/justtherip/status/1715727312295989249

所以我们又来到这个地步了。他们需要矿工投票来加速网络并进行更便宜的交易。所以你认为矿工会投票减少钱吗？不，他们不会。在最后一个比特币被开采之前，比特币将变得缓慢且昂贵。我们都将早已逝去。

@DavidShares：https://twitter.com/DavidShares/status/1716103036399935762

有一些已证实的问题仍未解决，例如路径路由问题。解决这个问题的唯一方法是使用托管人，LN 正在这样做，将中心化和银行机构重新引入比特币，而比特币的全部目的就是摆脱它们。

Paul 怎么看？"HTLC 已死、闪电网络可能幸存、LN on Drivechain 是闪电网络出路之一"

**Layer 2 Labs 创始人Paul Sztorc^[4] 提出了他设想的解决方案^[5]**：

这需要:

• 软分叉操作码

• HTLC 进一步增长，至少 5 个字节，可能更多；从而使他们对 L1 费用更加敏感

通过侧链，可以设计一个新的特殊 txn，它可以节省所有这些字节，而基于Drivechain 的闪电网络（LN on DC）会更好。”

参考资料

[1]据 Cointelegraph 报道:Bitcoin core developer steps back from Lightning Network over ‘hard dilemma’: https://cointelegraph.com/news/bitcoin-core-developer-antoine-riard-steps-back-lightning-network-dilemma

[2]Antoine Riard 的邮件截图: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004154.html

[3]@mononautical: https://twitter.com/mononautical

[4]Paul Sztorc: https://twitter.com/Truthcoin

[5]他设想的解决方案: https://twitter.com/Truthcoin/status/1716110498867859760