[Lightning-dev] Loop attack with onion routing..

[CJP]

>         So, with some prompting from AJ who has been working on node
> incentives, I realized there's a nasty attack available to the network.
> You simply route a payment back to another channel you own, then refuse
> to dislose R.
> 
> You have to lock up N bitcoins, but so does every node in the path (and
> nobody gets paid!).  Onion routing means nobody knows who to blame (you
> can simply claim there's another hop after you).

Yes, that's a nasty one: the total damage to the network is much larger
than the damage to the attacker, especially when the attacker is free to
choose a very long route. This could be used to perform a DoS attack on
the network.

> I think in this case we need to peel the onion[1]: if a payment takes
> too long you tell the previous node where you sent it (and relay where
> it sent it, etc.)  If you're the last in the queue, you also need to
> prove that you closed the channel to the offender[2] (which costs you a
> txfee, providing disincentive).
> 
> Anyone see any other problems?

I don't like the "peeling the onion" idea, since it breaks down a very
important privacy layer. This privacy is necessary e.g. to make sure the
network remains open for new participants to start routing, even against
the will of an existing cartel of routers.

Maybe I'm overlooking something, but wouldn't it be enough to add a
fine, to be paid from payee-side of a single link to the payer-side of
the link, if the R value is delayed? It wouldn't even be necessary to
cryptographically enforce such a fine: if the fine isn't paid, the other
node can simply close the channel, isolating the misbehaving node.
Well-behaving nodes will always pay the fine, thereby keeping their link
intact and keeping a healthy network of well-behaving nodes.

In order to punish the attacker, these fines should be accumulated
towards the payee side of the route; this sounds like a similar problem
as the accumulation of ordinary transaction fees across a route. 

Intuitively I'd say that, for a mixed source/non-source routing network,
it'd be reasonable that the endpoints of the transaction (final payer
and payee) explicitly pay fees to the source-routed nodes in a route,
and that any fees of non-source routed nodes are covered by the fees
paid to their closest source-routed nodes(**). Explicitly paying fines
to source-routed nodes also provides an incentive(*) to keep routes
short.

CJP

(*) unless the explicit fee is negative of course, but that's a feature,
not a bug.

(**) Example (for ordinary fees, but could be similar for fines):
capitals are source-routed nodes

A - b - c - D - e - F - g - H

A pays 1.000 mBTC to H (main payment from payer A to payee H)
A pays 0.003 mBTC to D (explicit source routing fee; D is the "meeting
point" agreed by A and H)
H pays 0.003 mBTC to F (explicit source routing fee; H selected F for
onion-routing towards D, without A's knowledge)
A pays 0.002 mBTC to b (non-source routing fee)
b pays 0.001 mBTC to c (non-source routing fee)
D pays 0.001 mBTC to c (non-source routing fee)
D pays 0.001 mBTC to e (non-source routing fee)
F pays 0.001 mBTC to e (non-source routing fee)
F pays 0.001 mBTC to g (non-source routing fee)
H pays 0.001 mBTC to g (non-source routing fee)

Net result:
A: -1.005
b: +0.001
c: +0.002
D: +0.001
e: +0.002
F: +0.001
g: +0.002
H: +0.996