From rusty at rustcorp.com.au Fri Aug 21 02:22:54 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 21 Aug 2015 11:52:54 +0930 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: <87egixidmp.fsf@rustcorp.com.au> Joseph Poon writes: > On Thu, Aug 20, 2015 at 03:19:29PM +0930, Rusty Russell wrote: >> So, with some prompting from AJ who has been working on node >> incentives, I realized there's a nasty attack available to the >> network. You simply route a payment back to another channel you own, >> then refuse to dislose R. >> >> You have to lock up N bitcoins, but so does every node in the path >> (and nobody gets paid!). Onion routing means nobody knows who to >> blame (you can simply claim there's another hop after you). > > This can be defined as a feature, though. If one expects the coins to be > locked up for the duration from the outset, the risk models are a lot > more clear. 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... > 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? >> I think in this case we need to peel the onion[1]: if a payment takes >> too long you tell the previous node where you sent it (and relay where >> it sent it, etc.) If you're the last in the queue, you also need to >> prove that you closed the channel to the offender[2] (which costs you >> a txfee, providing disincentive). > > My concern with mitigating this by establishing blame via information > disclosure is that it will encourage graph centralization. You lost me between these two statements? Though the important point is that some channel gets closed for slow payments, to produce disincentive. I think that's sufficient, and potentially leaks less information? But unacceptable risk levels will lead to onion protocol deprecation (thus, no financial privacy), so you can prevent attacks. The onion protocol will be so much more expensive because it's only used by Mallory and co, so you have to assume every HTLC will timeout. Everyone loses. >> 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? That seems to work... > However! The effect isn't necessarily that the cartel is successful, > there are always second order effects in preventing potential problems. > It's possible that B mitigates this by biasing the routing towards > certain participants that B "likes" (IOW, trusts to not withhold R to the > maximum time), which is where I think the real complexity with > incentives lie -- B will discourage using onion routing entirely. > > I see the tradeoffs as having both as an option may make sense, the > second order effect gives you an option for either (with one possibly > being slightly more expensive due to the withholding risks), whereas > forcing onion *only* on everything may create emergent cartelization > incentives. I haven't fully thought out the implications, and not > particularly attached to this viewpoint, though. I worry about not having onion because as we've seen in bitcoin, your privacy matters to my privacy: I can't be the only private one on the network. And onion is basically free on a technology level. > Thaddeus mentioned a possible solution to all this being funds sent to > each participant with multiple signatures for different times of > disclosure of R (having the spending transaction be double-spent with > different locktimes, this is dependent upon a longer-term malleability > fix and may require a more elaborate tree structure for the HTLC > spends). E.g. release within 4 hours will have each hop make slightly > more money in fees. It doesn't guarantee against withholding, it just > creates a material cost to do so. I don't think we've really fleshed out > the idea, though AFAIK. AJ has been assuming similar per-hop contracts, but I'd like to simplify for the first attempt if I can. 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". 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? Cheers, Rusty.