From aj at erisian.com.au Thu Aug 20 22:12:15 2015 From: aj at erisian.com.au (Anthony Towns) Date: Fri, 21 Aug 2015 00:12:15 +0200 Subject: [Lightning-dev] Loop attack with onion routing.. In-Reply-To: <20150820210823.GB1762@lightning.network> References: <874mjujyqe.fsf@rustcorp.com.au> <20150820210823.GB1762@lightning.network> Message-ID: On 20 August 2015 at 23:08, Joseph Poon 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: