闪电网络的垃圾信息攻击

闪电网络垃圾信息攻击

闪电网络的主要目标之一是为付款人和收款人提供良好的隐私，这要归功于源路由和洋葱加密的结合（Sphinx）。

不幸的是，恶意行为者可能会滥用此属性来垃圾信息攻击网络：中间路由节点无法轻易判断它们正在中继的付款是真实的付款还是垃圾信息攻击尝试。

一个邪恶的路由节点可以使用此属性来确保其竞争对手的通道无法路由付款：这可能会迫使付款人通过邪恶节点的通道进行路由，从而为他赚取费用，并可能使他的竞争对手在经济上难以维持。如果一个更邪恶的实体可以访问网络的部分容量，则可能会使整个公共闪电网络无法使用。

目录

• 攻击描述
• 当今可用的缓解策略
• 威胁模型
• 提议
  • 可证明的问责
  • 本地信誉跟踪
  • 朴素的预付款
  • 反向预付款
  • 双向预付款
  • 与持有时间相关的双向预付款
  • 信任网络 HTLC 持有费用

攻击描述

攻击者利用 HTLC 超时机制来锁定网络中的流动性。此攻击不会直接花费路由节点的钱，但会浪费资金分配，并可能阻止合法的付款通过。

攻击者控制两个节点：A1 和 A2（我们将此攻击称为 controlled spam）。攻击者找到 A1 和 A2 之间的长路由，通过这些路由发送 HTLC，并在接收方保持沉默（模拟卡住的 HTLC）：

A1 ---htlc1---> 某个节点 ---> ... ---> 某个节点 ---> A2
A1 ---htlc2---> 某个节点 ---> ... ---> 某个节点 ---> A2
...
A1 ---htlcN---> 某个节点 ---> ... ---> 某个节点 ---> A2

中间节点注意到 HTLC 似乎卡在下游的某个地方，但是：

• 他们唯一的选择是等待 HTLC 超时，否则他们有资金损失的风险
• 他们无法知道付款的最终目的地，也无法知道付款的来源
• 他们无法责怪他们的直接对等方，他们可能是也可能不是攻击者
• 他们无法知道这些 HTLC 是否相关

当 HTLC 接近超时时，攻击者从 A2 使其失败，并重复相同的过程。攻击者唯一的成本是他需要锁定 HTLC 金额，但是当他从 A2 使 HTLC 失败时，他会立即收回资金。

由于付款路由最多可以有 20 跳，因此攻击者似乎可以锁定他分配给攻击的资金的 20 倍。但实际上情况更糟：一个通道可以拥有的待处理 HTLC 数量有限制（默认情况下为 483 个 HTLC）。通过用微小的 HTLC（略高于 dust limit）完全填满一个通道，攻击者能够以非常小的成本锁定整个通道。

请注意，攻击者可以在两端使用相同的节点（A1 = A2）。

另请注意，攻击者不一定需要长时间持有 HTLC；他可以释放它们并立即重复相同的过程，或者保持稳定的 HTLC 流以泛洪网络；我们将这种攻击称为 short-lived controlled spam。

值得考虑此攻击的另一种变体。攻击者不是发送到他控制的节点（A2），而是将 HTLC 发送到他不控制的随机节点。这些最终节点会立即使 HTLC 失败（因为它与它们数据库中的任何发票都不匹配），但是由于转发延迟，HTLC 会在通道承诺中锁定一段时间。攻击者可以使用这种 HTLC 不断涌入网络，以中断合法的付款。我们将这种攻击称为 uncontrolled spam。

当今可用的缓解策略

如今，不可能完全阻止此类攻击，但是我们可以通过正确配置通道来使攻击者的工作更加困难：

• 攻击者至少需要锁定 htlc_minimum_msat * max_accepted_htlcs 自己的资金才能完全填满一个通道，因此你应该为 htlc_minimum_msat 使用合理的值（1 sat 对于具有大容量的通道不是一个合理的值；尽管对于较小的通道来说可能还可以）
• 打开冗余的未公布通道到你最赚钱的对等方
• 实施中继策略以避免填满通道：始终保持 X% 的 HTLC 插槽可用，专用于高价值 HTLC

长时间存在的受控垃圾邮件也可以通过中继策略来缓解，该策略拒绝未来太远的 CLTV 锁定时间或需要较低的 cltv_expiry_delta。后一种缓解措施可能会降低中继节点安全性。

威胁模型

我们希望防御具有以下能力的攻击者：

• 他们能够快速打开到网络中任何节点的通道
• 他们具有网络公共拓扑的最新知识
• 他们正在运行 LN 节点实现的修改（恶意）版本
• 他们能够快速创建许多看似不相关的节点
• 他们可能已经有长期存在的通道（良好的信誉）
• 他们可能会实时探测通道余额以调整其垃圾邮件
• 他们可能会发送与诚实的长期 HTLC 无法区分的长期持有的 HTLC

我们必须绝对保留闪电网络的重要属性：

• 付款人和收款人的匿名性
• 无需信任的付款
• 作为路由节点的最低（合理）进入门槛
• 合法付款的最低开销/成本
• 向网络声明公共路径的最低开销
• 成功中继付款的激励

我们必须避免为攻击者创造机会：

• 惩罚诚实节点与其自身诚实对等方的关系
• 使路由节点损失不可忽略的资金
• 从诚实的发送者那里窃取资金（即使是很小的金额）
• 更容易地发现他们在付款路径中的位置
• 引入第三方通道关闭向量（例如，Alice 关闭 Bob 和 Caroll 之间的通道）

提议

多年来，已经提出了许多想法，探索了不同的权衡。我们在此总结它们的优缺点，以帮助未来的研究进展。

可证明的问责

最古老的提案讨论了在不快速失败/成功 HTLC 的不良行为对等方的情况下提供通道关闭证明。例如，如果 Alice 通过 Bob 向 Caroll 发送 HTLC，如果 Caroll 在短时间内没有响应，Bob 应该关闭他与她的通道，并将关闭交易作为证据呈现给 Alice，以清除自己因路由失败的责任。

该方案引入了一系列不同的问题：需要了解跨链接的通道类型、隐私破坏、通道脆弱性等。

本地信誉跟踪

此提案讨论了节点的信誉系统。一个节点将实时记录由于来自或发送到其相邻对等方的中继 HTLC 而获得的路由费用。每次路由失败后，都会降低 faultive 对等方的信誉，直到达到触发通道关闭的某个阈值。

该方案不能防止信誉污染。从节点角度来看，你的直接对等方或上游对等方的失败无法区分。

朴素的预付款

最明显的建议是要求节点在想要中继 HTLC 时无条件地向下一个节点支付固定的少量金额。 让我们探讨一下为什么这个提案不起作用：

• 攻击者将在第一跳支付该费用，但在最后一跳会收到该费用：这不会花费他任何费用
• 此费用适用于每次付款尝试：当一个合法的用户不走运并尝试多个路由但没有成功时（可能是由于下游的流动性问题等有效原因），他将不得不多次支付该费用

反向预付款

此提案建立在前一个提案的基础上，但颠倒了流程。 节点为接收 HTLC 而不是发送 HTLC 支付费用。

A -----> B -----> C -----> D

B 向 A 支付接收 HTLC 的费用。
然后 C 向 B 支付接收转发的 HTLC 的费用。
然后 D 向 C 支付接收转发的 HTLC 的费用。

必须有一个宽限期，在此期间不支付任何费用； 否则，uncontrolled spam 攻击允许攻击者强迫路由中的所有节点支付费用，而他自己则不支付任何费用。

每个跳的费用不能相同，否则当攻击者位于付款路由的两端时，这是免费的。

该费用必须随着 HTLC 向下游移动而增加：这确保了持有 HTLC 时间较长的节点比快速失败的节点受到更多的惩罚，并且如果一个节点由于下游卡住而不得不长时间持有 HTLC，他们将收到比他们必须支付的更多的费用。

每个跳的宽限期也不能相同，否则攻击者可以强迫 Bob 成为唯一支付费用的人。 与我们拥有 cltv_expiry_delta 类似，节点必须具有 hold_grace_period_delta 并且 hold_grace_period 必须比下游更大。

缺点：

• 攻击者仍然可以在 hold_grace_period 期间锁定 HTLC 并连续重复攻击

未解决的问题：

• 该费用是否需要基于 HTLC 的持有时间？
• 当通道关闭且 HTLC 超时必须在链上赎回时会发生什么？
• 我们是否可以在不向中间节点暴露路由长度的情况下实现此目的？

双向预付款

此提案建立在前两个提案的基础上，并将它们结合在一起。 节点支付一个正向和一个后向的预付款，但如果 HTLC 快速结算，则后向的预付款将被退还。

A -----> B -----> C -----> D

我们在 channel_update 中添加一个 hold_grace_period_delta 字段（以秒为单位）。

我们在 update_add_htlc 的 tlv 扩展中添加三个新字段：

• spam_fees (msat)
• hold_grace_period (秒)
• hold_fees (msat)

我们在 onion per-hop payload 中添加两个新字段：

• outgoing_hold_grace_period
• outgoing_spam_fees

当节点收到 update_add_htlc 时，它们会验证：

• hold_fees 不是不合理的大
• hold_grace_period 不是不合理的短或长
• hold_grace_period - outgoing_hold_grace_period >= hold_grace_period_delta
• spam_fees - outgoing_spam_fees > 0 并且不是不合理的小

否则，它们会立即使 HTLC 失败，而不是中继它。

对于该示例，我们假设所有节点都使用 hold_grace_period_delta = 10。

我们添加一个正向预付款（spam_fees），该费用在提供 HTLC 时无条件支付。

我们添加一个后向预付款 hold_fees，该费用在接收 HTLC 时支付，但如果在 hold_grace_period 结束前结算 HTLC，则会退还（请参阅关于此的脚注）。

正向预付款在每个跳严格递减，而后向预付款在每个跳递增（非严格）。

+---+                          +---+                          +---+                          +---+
| A |                          | B |                          | C |                          | D |
+---+                          +---+                          +---+                          +---+
  |                              |                              |                              |
  | 不可退还的费用：15 msat        |                              |                              |
  |----------------------------->|                              |                              |
  | 可退还的费用：50 msat          |                              |                              |
  | 退款截止日期：100 秒          |                              |                              |
  |<-----------------------------|                              |                              |
  |                              | 不可退还的费用：14 msat        |                              |
  |                              |----------------------------->|                              |
  |                              | 可退还的费用：60 msat          |                              |
  |                              | 退款截止日期：90 秒           |                              |
  |                              |<-----------------------------|                              |
  |                              |                              | 不可退还的费用：13 msat        |
  |                              |                              |----------------------------->|
  |                              |                              | 可退还的费用：70 msat          |
  |                              |                              | 退款截止日期：80 秒           |
  |                              |                              |<-----------------------------|
  |                              |                              |                              |

• A 向 B 发送一个 HTLC：

  • hold_grace_period = 100 秒
  • hold_fees = 50 msat
  • outgoing_hold_grace_period = 90 秒
  • spam_fees = 15 msat
  • outgoing_spam_fees = 14 msat
  • 正向预付款：从 A 的主输出中扣除 15 msat 并添加到 B 的主输出中
  • 后向预付款：从 B 的主输出中扣除 50 msat 并添加到 A 的主输出中

• B 将 HTLC 转发到 C：

  • hold_grace_period = 90 秒
  • hold_fees = 60 msat
  • outgoing_hold_grace_period = 80 秒
  • spam_fees = 14 msat
  • outgoing_spam_fees = 13 msat
  • 正向预付款：从 B 的主输出中扣除 14 msat 并添加到 C 的主输出中
  • 后向预付款：从 C 的主输出中扣除 60 msat 并添加到 B 的主输出中

• C 将 HTLC 转发到 D：

  • hold_grace_period = 80 秒
  • hold_fees = 70 msat
  • spam_fees = 13 msat
  • 正向预付款：从 C 的主输出中扣除 13 msat 并添加到 D 的主输出中
  • 后向预付款：从 D 的主输出中扣除 70 msat 并添加到 C 的主输出中

• 场景 1：D 快速结算 HTLC：

  • 所有后向预付款都将退还（返回到各自的主输出）
  • 仅支付了正向预付款（以防止 uncontrolled spam 和 short-lived controlled spam）

• 场景 2：D 在宽限期后结算 HTLC：

  • D 的后向预付款不予退还
  • 如果 C 和 B 快速向上游中继结算（在 hold_grace_period_delta 之前），则会退还其后向的预付款
  • 所有正向预付款都已支付（以防止 uncontrolled spam 和 short-lived controlled spam）

• 场景 3：C 延迟 HTLC：

  • D 在其 grace_period 之前结算，因此 C 退还其后向的预付款
  • C 在向上游结算之前延迟：它可以确保 B 不会获得退款，但 C 也不会获得退款，因此 B 获得了后向的预付款的差额（从而防止了 controlled spam）
  • 所有正向预付款都已支付（以防止 uncontrolled spam 和 short-lived controlled spam）

• 场景 4：通道 B <-> C 关闭：

  • D 在其 grace_period 之前结算，因此 C 退还其后向的预付款
  • 无论出于何种原因（恶意的与否），B <-> C 通道都会关闭
  • 这确保了 C 的后向预付款已支付给 B
  • 如果 C 快速发布 HTLC-fulfill，则 A 可能会退还 B 的后向预付款
  • 如果 B 被迫等待其 HTLC 超时，则不会退还其后向的预付款，但这没关系，因为 B 收到了 C 的后向预付款
  • 所有正向预付款都已支付（以防止 uncontrolled spam 和 short-lived controlled spam）

后向预付款是固定的，而不是根据 HTLC 的待处理时间缩放； 它对垃圾邮件发送者的惩罚略少，但复杂度较低，并且对诚实节点造成的潜在不良影响也较少。 通过缩放方法，单方面关闭其通道的诚实节点会受到过重的惩罚（因为它必须支付最长持有期限的费用）。

缺点：

• 如果以幼稚的方式进行，此机制可能允许中间节点取消发送者/接收者的匿名。随机化基本 grace_period、hold_fees 和 spam_fees 可能会消除该探测向量。
• 处理 grace_period 将是一个麻烦：
  • 你何时开始计数：当你发送/接收 commit_sig 或 revoke_and_ack 时？
  • 如果出现断开连接会发生什么情况（如何解释重新连接的延迟）？
  • 如果远程节点在 grace_period 之后结算，但在发送其 commit_sig 时退还自己（从他的角度来看，这使得看起来像他在 grace_period 之前结算了）会发生什么？ 在这种情况下，行为可能应该是给你的对等方一些回旋余地并让他们逃脱，但要记录下来。 如果他们这样做太频繁，请关闭通道并禁止他们； 窃取预付款永远不值得失去通道。

与持有时间相关的双向预付款

如上所述，双向预付款的一个特点是 hold_fees 与时间无关。 如果 htlc 未在 grace_period 内解决，则 htlc 的接收方将被迫支付全额持有费用。 持有费用应涵盖锁定 htlc 最长时间（可能是 2000 个区块）的费用，因此这可能是一笔可观的罚款。 原子链上/脱链交换（Lightning Loop 等）等应用程序依赖于锁定资金一段时间，并且可能会因固定的持有费用而变得昂贵。

双向预付款的另一种变体使用与时间成比例的持有费率来解决上述限制。 它旨在将支付的费用更直接地与发生的实际成本相关联，从而减少参数的数量。

完整的提案可以在此处找到。

信任网络 HTLC 持有费用

此提案引入了取决于 HTLC 保持待处理的时间量的费用。 节点在提供 HTLC 时根据以下公式支付费用：

hold_fee = lock_time * (fee_base + fee_rate * htlc_value)

fee_base 和 fee_rate 取决于两个对等方之间的信任关系：

• 节点向他们不认识/不信任的节点收取高额费用
• 随着时间的推移，节点会观察其对等方，并且如果他们正确地运行了足够长的时间，则可能会降低费用
• 这确保了垃圾邮件发送对攻击者的成本更高，攻击者必须：
  • 花费聪来发送垃圾邮件
  • 或花费时间来建立声誉
• 持有费用可以在协议层面上实施，但也可以从外部强制执行该策略。 例如：当持有费用预算耗尽时停止转发付款，并要求对等方通过 keysend 充值。

缺点：

• 进入壁垒（对于新的路由节点）可能会导致中心化
• 正确评估对等方很难：大多数指标都可以通过远程节点来控制，以降低对等方的分数
• 可能进行小规模的悲伤：对等方有动机持有 HTLC 更长时间以收取更多费用：对于所有基于按时间付费的提案，其中发送方支付费用，情况都是如此
• “退出诈骗”类型的攻击：恶意节点运行足够长的时间，然后发起攻击

相邻问题

解决通道垃圾邮件攻击可能有助于 LN 的其他极端情况。

无成本通道探测

一个不断探测网络中通道的节点可能会发现路由节点的付款流量，从而全局跟踪 LN 付款流量。

瞭望塔信用耗尽

考虑到即将部署的公共瞭望塔，LN 节点可能必须支付每个通道更新的成本，以避免瞭望塔资源 DoS。 恶意对手不断更新通道可能会迫使受害者耗尽其瞭望塔信用，从而使受害者失去撤销保护。

如果恶意 HTLC 发送者/中继者必须向受害者支付固定费用，则会在受害者瞭望塔预算上创建一个更高的上限。 超出此固定费用所能承受的额外瞭望塔覆盖范围必须由受害者承担。

Eltoo 可能会通过将每个更新的瞭望塔资源成本限制为仅带宽成本来解决此问题。

来源

邮件列表（按时间顺序排列）

• Loop attack
• Analysis: alternative DoS prevention concept
• Mitigations for loop attacks
• A proposal for upfront payment
• A proposal for upfront payment (reverse upfront)
• Proof-of-closure as griefing attack mitigation
• Hold fees: 402 Payment Required for Lightning itself

论文

• Discharged Payment Channels: Quantifying the Lightning Network's Resilience to Topology-Based Attacks
• LockDown: Balance Availability Attack Against Lightning Network Channels
• Congestion Attacks in Payment Channel Networks
• Probing Channel Balances in the Lightning Network

• 原文链接： github.com/t-bast/lightn...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～