From aj at erisian.com.au Fri Aug 21 13:26:41 2015 From: aj at erisian.com.au (Anthony Towns) Date: Fri, 21 Aug 2015 15:26:41 +0200 Subject: [Lightning-dev] Loop attack with onion routing.. In-Reply-To: <87egixidmp.fsf@rustcorp.com.au> References: <874mjujyqe.fsf@rustcorp.com.au> <20150820210823.GB1762@lightning.network> <87egixidmp.fsf@rustcorp.com.au> Message-ID: On 21 August 2015 at 04:22, Rusty Russell wrote: > My concern is that the risk model is "good txs take < 30 seconds, bad > take 4 days". And you have no way of judging which side of that 10,000 > factor this is... ?You charge fees for 4 days, and if it only takes <30s you get a bunch of profit, yay! Those fees are still pretty reasonable: 20% ROI per year is just 0.2% over four days; .2% times 8 hops is 1.6% which is still much better than Visa/Paypal etc, even without the benefit of scaling to microtransactions. Also, the extra profit on fast transactions is the only thing that you've got to pay for the coins in your channel(s) that aren't currently doing anything. > It forces the graph to be more diffuse. It also forces intermediate > > nodes who are well-connected (who therefore also are the most likely > > subject of attacks) to offload their HTLCs to 3rd party channel > > liquidity providers. > > E.g. If Mallory tries to tie up the Alice<->Bob link, then if Carol is > > connected to both Alice and Bob, she can take the HTLC to be > > Alice->Carol->Bob, so that the Alice<->Bob link is clear. > It's not clear to me how you would atomically move an HTLC? Or are you > assuming you know in advance? > /Alice/ always knows in advance -- she knows the state of the Alice/Bob channel before she tries adding an HTLC. I think she can just add a hop in the route even under onion routing with no particular problems. >> Anyone see any other problems? > > 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. This > > increases the costs for B and biases channels to use the C,D,E cartel > > due to lower costs (since the channels aren't locked up as long). > First time they do this, if they don't close a channel (costing them > on-blockchain fees), B closes connection to C as dishonest? > ?How does B know C is dishonest, and not D or E? How does B know someone was dishonest, and that the delay wasn't desired by both of A and E?? (Delays might be desirable if they assist with privacy by resisting traffic analysis) > AJ has been assuming similar per-hop contracts, but I'd like to simplify > for the first attempt if I can. > ?I think you need to have "reputation" as part of the routing service at that point; but while lightning is small, that's probably trivial, IMHO. So I think it makes sense to begin with to have a "per hop maxdelay" (so > you can indicate, and be charged appropriately, if this is expected to > be slow). Think "20 seconds". > ?Hmm. You'd have to have that be cumulative: A -> B -> C -> D A: I expect a response in 2 days + 40s B: you can expect a response in 2 days + 20s C: you can expect a response in 2 days But what happens if D takes longer than 2 days 90 seconds? C accuses D o being unreliable and maybe closes the channel. But does B also close the channel with C? Or does C say "Hey, D didn't contact me" at 2 days and 10s and get let off? (What happens if C is lying?) In either event, B only charged fees for 2 days + 20s of time-value, but still has to wait for the timeout, no matter how nice C is. If you can't complete the HTLC with the next node in maxdelay seconds, > you return route fail. If the next node doesn't complete or routefail > in maxdelay * MAX_HOPS (aka "20") seconds, you unilaterally close the > channel and send that tx in your "delay" message back. > I *think* this works? > ?Closing the channel doesn't give you your money back any earlier, so afaics you still need to charge fees for the full timeout. I don't /think/ a separate pretend-timeout makes things any less exploitable. If people get over-confident and run hubs at rates assuming the timeout will never get hit, I think you have to treat them as effectively subsidising the network; eventually they'll hit a bunch of slow transactions in a row either by happenstance or enemy action, and end up losing money.? ?Cheers, aj? ?-? - Anthony Towns -------------- next part -------------- An HTML attachment was scrubbed... URL: