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

Anthony Towns aj at erisian.com.au
Thu Aug 20 22:12:15 UTC 2015


On 20 August 2015 at 23:08, Joseph Poon <joseph at lightning.network> wrote:

> I see the primary problem with "onion" routing is that some parts of the
> graph may be faster with disclosure of R. In effect, some people may
> have higher costs in the "time" part of "time-value"
>
> E.g. A->B->C->D->E. If C, D, and E are colluding participants to each
> other, and their R gets disclosed immediately, their channel's value
> permits much lower fees. They can collude to be dishonest with B, so
> that B's channel is tied up for the maximum period of time.


​If they do that, C doesn't get paid until the timeout; and the only way D
gets paid is from C, and the only way E gets paid is from D. So I don't see
what good colluding actually does them? ie you just get:

Immediate:
  D pays E
  C pays D
Later:
  B pays C
  A pays B

But C could achieve that outcome on its own, just by delaying notifying B
until near the timeout; no collusion necessary. In any event, if the
transaction's going to succeed, the money on the B-C channel's HTLC is
going to be C's, so C is mainly depriving itself by filing to communicate.

If you have B and D collude instead, so that E reveals R to D, and D
reveals R to B instead of C, then the payments could go:

  D pays E
  D reveals R to B
  A pays B
  B pays D

with the transaction from B->C and C->D remaining open until the timeout,
but everyone else is square.​ That would inconvenience C, possibly cheaply
for B and D. If there's already a channel between B and D (for the "B pays
D" step), I'm not sure why B and D wouldn't just announce that, and once it
was announced, I don't see why A would route via C anyway...

Cheers,
aj

-- 
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150821/80d29a60/attachment.html>


More information about the Lightning-dev mailing list