Onion Message Jamming in the Lightning Network

Thanks @erickcestari. Let me take a step back to add some color.

Fundamentally, onions are designed to obscure the source. Without a source, direct attribution is impossible, and without direct attribution, an incremental cost must be inferred to hold peers accountable. So, the question becomes, what is that cost? Payment is ideal, but complex in practice. That’s not to say it shouldn’t be done, but I maintain reputation is an underutilized lever that can be deployed today without a protocol change.

By “reputation,” I’m referring to a long-term, holistic judgment about a peer. A rate limit, by comparison, is like a circuit-breaker: a short-term reflex to a burst of traffic. Rate limiting schemes alone, such as (4), leave routing nodes vulnerable to repeated attacks over time.

My argument is, if a circuit is broken, the offending node’s reputation should be charged. To protect its reputation, that node lowers its ingress limits. Lowering ingress limits reduces amplification and increases long-term reputation risk in the direction of the malicious source. Similar to (4), back-propagation limits the short-term damage. Unlike (4), reputation charges diminish the durability of an attack; an adversary can only attack the network as long as they have goodwill with their peers. The underlying assumption is that good actors will have a higher reputation than bad actors and can therefore resist attacks.

a node can build a high score by forwarding HTLCs correctly and then spend it on onion message spam without losing anything.

I contend this attack is not free. The adversary has to do useful work to earn a reputation that is subsequently spent. Also, note that these behaviors can be represented as a cost function that are weighted against each other (i.e “tuning” parameters). A node can charge a high price to relay OMs, but that makes them unreliable as an OM forwarder. If priced too cheaply, a routing node expends system resources as an OM relay without adequate compensation and risks reputation damage with its peers.

This reputation function can be defined by each node independently and can be incrementally improved over time. Individual weights are likely to be more dynamic and unique to a node, while the shape of the function is likely to be widespread. For example, repeatedly breaking a circuit should be charged more than an isolated instance.

With that said, I acknowledge that reputation alone does not fully resolve current attack vectors. Most notably, long-paths take a long time to back-propagate and loops can be used to easily trigger rate limits. The hop-limit described in (2) limits the reach of an adversary, but doesn’t fully resolve the amplification of a loop. A hypothetical onion_message_id could be used to detect loops, but comes at a small privacy cost.

1 Like

Thanks for explaining further. Two things I want to check before responding:

  • This implies forwarding OM only to peers you have a channel.
  • Is this reputation a separate metric from the channel-jamming one, or the same score?

And when does an OM cost reputation: only once the upstream peer trips a configured limit, or does every message debit something?

This implies forwarding OM only to peers you have a channel.

Out of self-interest, I would expect most OM relaying to occur over channels. But that’s not a necessary constraint here because nodes can evaluate the reputation of any other node on the network, including non-channel peers. For a given node, non-channel peers would presumably have a lower reputation than channel peers, which aligns with the example in (4) where channel peers are afforded 10/sec while non-channel peers only 1/sec.

Is this reputation a separate metric from the channel-jamming one, or the same score?

Independent metrics can be jointly assessed. For example, fee revenue may influence OM budget. But because OM can be misattributed, OM score probably should not influence payments much.

And when does an OM cost reputation: only once the upstream peer trips a configured limit, or does every message debit something?

For the implementations to decide. Generally speaking, coarser accounting (i.e charge on broken circuit) is easier to account for, but also easier for an adversary to game. A routing node that employs a coarser strategy is more likely to take reputational damage from an adversary that maximizes flow through them without tripping the circuit. Meanwhile, granular accounting is more work, but quicker to respond to the adversary. Calling a reputation function is light work with bounded state, so I’d speculate granular accounting is do-able. I suppose a node could even employ a hybrid. In good times, a node can keep a meter; in adversarial times, (after a circuit is broken) the node may switch to a more granular approach.