From aj at erisian.com.au Tue Sep 1 07:56:54 2015 From: aj at erisian.com.au (Anthony Towns) Date: Tue, 1 Sep 2015 17:56:54 +1000 Subject: [Lightning-dev] Loop attack with onion routing.. In-Reply-To: <1441091250.4549.25.camel@hppg6.kloosterkade> References: <874mjujyqe.fsf@rustcorp.com.au> <1440870652.4197.88.camel@hppg6.kloosterkade> <1440957679.5747.48.camel@hppg6.kloosterkade> <1441091250.4549.25.camel@hppg6.kloosterkade> Message-ID: On 1 September 2015 at 17:07, CJP wrote: > Anthony Towns schreef op di 01-09-2015 om 07:08 [+1000]: > > On 31 August 2015 at 04:01, CJP wrote: > > > A - b - c - D - e - F - g - H > No. H just tells A he can route this particular transaction to D. A > doesn't know H. > ?That doesn't make sense to me -- if A doesn't know H, how can H tell A anything? > > 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 > ?Same here; how does H know to do anything? A doesn't know H, so A can't tell them. If D's telling H, then isn't D already using the F/g route to do so?? - F establishes a route to D as instructed > - D matches the two sides, and informs both sides that a route is > present. > - 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. > > > 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. ?Maybe. The case I'm thinking about is if you're doing most of your day-to-day transactions over lightning (buying coffee and lunch and groceries and bus tickets and fuel and whatnot), then your channels will empty out pretty quickly; so you'll want to have some way to "get money from the ATM" once a week or so. And conversely you'll want some way to put your salary into the "ATM" as well. Doing that via the blockchain works fine of course, but then your average lightning user is doing a blockchain transaction once every week or three, rather than once every two years, > 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. > I think fines have to be paid on the payee side, so H not A -- it's the payee that can close the transaction early, so if they choose not to, it's their responsibility. I think that's independent of whether the routing was source/non-source (though for source routing, the original payer might add some fees to cover the potential fines). Then doesn't it just reduce to enforcing payments from your direct neighbour, and relying on them transitively doing the same? ie, D forces e to pay a fine, and in order to cover those costs e forces F to pay a larger fine, F forces g to pay an even larger fine, and g forces H to cover all of that. Cheers, aj -- Anthony Towns -------------- next part -------------- An HTML attachment was scrubbed... URL: