Is channel spam economic?

[LLFourn]

The document here: https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md talks about a threat model but does not talk about the goal of the adversary specifically. Is the theory that sending spam HTLCs might be more profitable than just using the coins to create new valuable channels supported by any research?

This seems to be a crucial question and the document would benefit from at asking it or leaving it as an open question.

Thanks!

[t-bast]

You're right, I should enrich the introduction to motivate this.
The TL;DR is that attackers have a very good multiplier for locking up liquidity on target nodes (with N sats, the attacker is able to lock M sats of his target with M >> N).

[t-bast]

Is it better with 9dff654?

Note that the paragraph that describes the attack has a paragraph that explains the multiplier effect, which I believe in combination with the intro text I added explains the unfair advantage attackers have.

[ariard]

IMO, one of the most straightforward goal is channel-jamming the channels of your routing competitors, thus redirecting HTLC traffic to your routing channels and earning the fees.

@LLFourn I'm not sure about your point around non-economic adversary (https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002893.html), any channel-jamming security definition you will come with won't imply some reference to a scare resource you spend/commit ?

[LLFourn]

The TL;DR is that attackers have a very good multiplier for locking up liquidity on target nodes (with N sats, the attacker is able to lock M sats of his target with M >> N).

It sounds good but is it good enough to overwhelm the benefit of just using your coins to open up new channels?
In other words, as an adversary you have at least two ways to make profit:

1. Add new nodes to the graph by opening new channels
2. Delete nodes that others own from the graph through channel jamming

Both of these option require allocating coins for a period. In what topology and under what conditions is (2) a better option than
(1)? It seems to me that coming up with a model to answer this is a fundamental next step in this topic. One thing that probably influences this greatly was pointed out by @naumenkogs https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002895.html. Are loops possible? If so then then (2) is probably very attractive. But what if we are able to stop loops through some cryptography? i.e. have the sender prove that the entire path is well formed in ZK (my guess is this would be much easier than stake certificates). This might push things in favor of (1) most of the time (or not! depends on the results of modelling the problem).

Is it better with 9dff654?

The thing that I wanted to get at is as an attacker you could do this but we don't know yet under what conditions as an attacker you should do this if you are trying to make profit. This is a very important point IMO. It's possible that as a profit making strategy channel jamming is very weak.

@LLFourn I'm not sure about your point around non-economic adversary (https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002893.html), any channel-jamming security definition you will come with won't imply some reference to a scare resource you spend/commit ?

Right but the difference is the economic adversary needs to end up with more of the resource after the attack i.e. profit from it (with some reasonable probability).

Side question: do lightning implementations trivially make sure that the outgoing HTLC is not going to the same node as the incoming HTLC?

[t-bast]

I would be very surprised if you could prevent loops. Eclair doesn't let you do a loop payment, but anyone can modify the code to allow it. And I don't think cryptography can do anything against it, because attackers can then simply use two of their nodes (and the effect is the same as if they were using a loop).

Payment routing is a very thin margin business. If it ever becomes profitable, I don't think it will yield big returns.
So denying activity to one of your competitors can quickly put him out of business if he doesn't have enough upfront cash to keep him afloat.
And pure malice is also always an option: right now it's only temporarily wasted capital for the attacker, not funds spent, so it's a free attack for someone who has bitcoins and doesn't need these bitcoins to generate additional profit.

[ariard]

W.r.t to path proving, I don't think you can prove in ZKP that's the payment path isn't malicious. Proving A --> B --> C --> D is honest means proving that an economic interaction between A and D "makes sense" ? Also you might prove you have not knots in your payment paths to prevent loop but loop is just one of the jamming tactic ?

Payment routing is a very thin margin business. If it ever becomes profitable, I don't think it will yield big returns.
So denying activity to one of your competitors can quickly put him out of business if he doesn't have enough upfront cash to keep him afloat.

I wonder if we're not too far looking on the ground, ultimately your lightning node might be your only payment processor, censoring its usage through channel jamming might ultimately get you out of business. So routing nodes might not be the most concerned victims, more merchants nodes ? If Mallory can prevent Bob, a merchant, to receive HTLC through Caroll, a routing node, by jamming her, that's an economic motivation ?

[LLFourn]

Payment routing is a very thin margin business. If it ever becomes profitable, I don't think it will yield big returns.
So denying activity to one of your competitors can quickly put him out of business if he doesn't have enough upfront cash to keep him afloat.
And pure malice is also always an option: right now it's only temporarily wasted capital for the attacker, not funds spent, so it's a free attack for someone who has bitcoins and doesn't need these bitcoins to generate additional profit.

I wonder if we're not too far looking on the ground, ultimately your lightning node might be your only payment processor, censoring its usage through channel jamming might ultimately get you out of business. So routing nodes might not be the most concerned victims, more merchants nodes ? If Mallory can prevent Bob, a merchant, to receive HTLC through Caroll, a routing node, by jamming her, that's an economic motivation ?

These are really good points. Let's say you jam a competing hardware wallet vendor around Christmas time so people get frustrated buy from you instead. This could easily be profitable. Merchants should probably not allow forwarding in these cases (only receiving). But if you know the Merchants node then targeting the nodes forwarding to it is still a rather concerning attack.

I would be very surprised if you could prevent loops

Proving A --> B --> C --> D is honest means proving that an economic interaction between A and D "makes sense" ?

I think the confusion is that I am always thinking in PTLCs rather than HTLCs. With HTLC the loops I am talking about are trivially prevented since they all have the same payment hash (I guess implementations refuse to forward the same HTLC payment hash twice). With per-hop randomized PTLCs this is not be the case so you have to worry about a malicious sender sending a single payment which cycles through honest party nodes many times.

To be clear I'm talking about something like:

1. Payer cryptographically commits to the path
2. Each honest node randomizes the commitment when forwarding to the next node (just as PTLC points are randomized)
3. The payer embeds in the onion for each node a proof that (i) their node is the committed path and (ii) it only appears once (iii) it is further along than the node that forwarded to you.

The way of constructing a proof for this off the top of my head would be inefficient but with some research I wouldn't be surprised if you could make it efficient.

And I don't think cryptography can do anything against it, because attackers can then simply use two of their nodes (and the effect is the same as if they were using a loop).

If the attacker is in the loop it's not a problem since the attacker is owning themselves. The problem is:

A -> B -> C -> D -> B -> C -> D -> B -> C -> D  .... -> E

Where only A and E are owned by the attacker. This would be super effective are knocking out the nodes in the cycle with very little funds locked by A and E.

Eclair doesn't let you do a loop payment

Does it let you forward a HTLC to the same node you received it from? Or alternatively does it check if you've already forwarded the payment hash?

[naumenkogs]

A -> B -> C -> D -> B -> C -> D -> B -> C -> D .... -> E

I always called this a loop. A little loop "B -> C -> D -> B" inside the route.

I think your definition of the loop is correct from the scientific point of view though, it's about first/last vertices. I dunno how the "subloop" should be called.

[LLFourn]

I always called this a loop. A little loop "B -> C -> D -> B" inside the route.

The technical term for this is a cycle I think https://en.wikipedia.org/wiki/Cycle_(graph_theory)

[naumenkogs]

@LLFourn but then according to wikipedia, a loop is an edge:

In graph theory, a loop (also called a self-loop or a buckle) is an edge that connects a vertex to itself.

what we were discussing before is not a loop, but just a big cycle.

[LLFourn]

In graph theory, a loop (also called a self-loop or a buckle) is an edge that connects a vertex to itself.

I really hope that no implementation allows buckles in payment paths!!

what we were discussing before is not a loop, but just a big cycle.

Technically it would be a cycle if the malicious node sending was also the receiving node.
The more effective attack is where you have a repeated sub-cycle with only honest parties in it.