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

CJP cjp at ultimatestunts.nl
Tue Sep 1 07:07:30 UTC 2015

Anthony Towns schreef op di 01-09-2015 om 07:08 [+1000]:
> On 31 August 2015 at 04:01, CJP <cjp at ultimatestunts.nl> wrote:
>         >         A - b - c - D - e - F - g - H
>         >         H pays 0.003 mBTC to F (explicit source routing fee;
>         H
>         >         selected F for
>         >         onion-routing towards D, without A's knowledge)
>         > You mean "D selected F for onion-routing towards H" here,
>         surely?
>         No :-)
>         Both sides of a payment may value their privacy, so both sides
>         may want
>         to perform onion routing independently.
>         ​ ​
>         It's a bit similar to TOR hidden
>         services: you route from both sides towards a "meeting point"
>         somewhere
>         on the route, which is not necessarily one of the end points.
> Hmm. I would look at that more like:
> Setup:
>  - H wants to be secretive.
>  - H establishes a channel with g


>  - H tells F he can route to H via g
>  - H tells D he can route to H via F

No. If H has a routable address (which is optional in this scenario,
since it's not used here), it would be "g tells F he can route to H via
g". But that information isn't used here, and the transaction isn't tied
to H's routable address, since there is no "routing to H" in this
scenario: there is only routing from A to D and from H to D through F.

> Announcement:
>  - H tells other people (such as A) they can route to H via D

No. H just tells A he can route this particular transaction to D. A
doesn't know H.
> Then A sends a txn for H to D as instructed, and D chooses to forward
> it on via F.

No. The sequence is:
- A establishes a route to D as instructed
- H establishes a route to F, and instructs F to establish a route to D
- F establishes a route to D as instructed
- D matches the two sides, and informs both sides that a route is
- The transaction is locked (HTLC created), starting on the A-b link,
then b-c, and so on, all the way to the g-H link.
> (Hmm. In that scenario, if e tried to send a txn to H, she would route
> via D, then find D routed the txn back to it -- using the same R --
> and that F was the next destination. This would be an information
> leak, arguably. Likewise for anyone whose cheapest path to D was
> through e)

Does not apply to the way I describe how it should work.
>         Note that, because locking of transaction funds is always done
>         in payer
>         -> payee direction, this requires a separate routing phase
>         before the
>         locking. So, first you find a route (where all parties say
>         they agree to
>         fees, tx amount, timeouts and other conditions), and then you
>         start
>         performing transaction-channel actions.
> Isn't that a bit circular -- "you obtain the route by sending messages
> along the route" ? 

No. Route finding can consist of several attempts, and each attempt
consists of sending messages between nodes. Once you find a route
(probably the first attempt in a well-optimized routing system), you can
send further messages along the route, but you did in fact already send
messages along the route prior to knowing that it will become your
> It also relies on end-to-end communication in realtime, which wouldn't
> work for paying to a cold-wallet lightning channel that's only
> occassionally online.

I don't see how lightning could pay to a cold wallet. I assume that, at
least when starting a transaction, all nodes on the route are online.
> If you *did* assume everything is in realtime, you could avoid fines
> entirely just by having the protocol be something like:
>  - the official timeout was 4 days, the unofficial timeout is 4
> minutes
>  - ...
>  - okay 4 minutes is up, do you know R?
>  - no, okay, we're revoking the transaction.
>  - you don't want to? fine, channel is closed.

I assume the "official" timeout is the one mentioned in the HTLC; it has
to be large (several days) to avoid nodes becoming vulnerable due to
loss of connectivity in the middle of a transaction: it might take you
some time to establish an alternative internet connection, and it has to
happen before the official timeout.

Neighbors can always try to impose shorter unofficial time-outs, with
the sanction that the channel will be closed. The consequence is that
both sides, and the network as a whole, lose a link, so it should be
avoided if possible.
> Maybe that's what the default protocol should be anyway, and fines are
> just an extension to that to bribe the payer not to close the
> channel...


>         You could of course ignore source routing for the fines, and
>         distribute
>         the fines as if it is only a non-source routing path. The
>         problem is
>         that an attacker can create an arbitrarily long path with
>         source
>         routing, thereby creating arbitrarily large total damage to
>         the network,
>         corresponding to arbitrarily large total fines. 
> ​I don't think it can go arbitrarily large -- if the recipient is
> paying the fines at each point, then the scenario is:

I don't understand how an intermediate point (D or F) can enforce
payment of fines by A or H.

You could of course pre-pay the fines with a separate transaction, which
has D or F as payee endpoint, and send the fines back in case of a
successful transaction. This assumes the intermediate nodes are trusted
with the fine amounts.


More information about the Lightning-dev mailing list