[Lightning-dev] Loop attack with onion routing..
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;
> > selected F for
> > onion-routing towards D, without A's knowledge)
> > You mean "D selected F for onion-routing towards H" here,
> 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"
> on the route, which is not necessarily one of the end points.
> Hmm. I would look at that more like:
> - 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.
> - 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
> 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
> - ...
> - 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
> You could of course ignore source routing for the fines, and
> 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
> 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