From rusty at rustcorp.com.au Mon Aug 24 00:59:09 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 24 Aug 2015 10:29:09 +0930 Subject: [Lightning-dev] Loop attack with onion routing.. In-Reply-To: References: <874mjujyqe.fsf@rustcorp.com.au> Message-ID: <87k2sljyci.fsf@rustcorp.com.au> Anthony Towns writes: > On 20 August 2015 at 07:49, Rusty Russell wrote: > >> I think in this case we need to peel the onion[1]: I changed my mind by the way. You don't need to peel the onion, you just need the commit transaction + htlc transactions tied to the closure (and you can see the HTLC is yours, by the R value). > ?Okay, so how might this actually work? > > Alice sends a payment to Emma, via Bob, Carol and Dave. > > Case 1: Dave misbehaves by taking a few minutes rather than a few seconds > to talk to Emma. > > * Carol decides that's unacceptable and asks Dave for an excuse. Dave > cannot provide one. Carol closes the channel (unilaterally, or with Dave's > grudging cooperation) A -> B -> C XXX D -> E > * At this point Bob believes Carol has taken too long too, so he asks > Carol for an excuses. Carol says its Dave's fault, and points to the > transaction closing the Carol/Dave channel as evidence; Bob knows that Dave > was cheating because the HTLC is still present in that transaction (Carol > reveals the P2SH script if necessary); Bob knows that Dave was who Carol > was forwarding to, because Carol provides a verifiable decryption of the > onion routing message Bob passed on to Carol. > * Bob likewise passes this back on to Alice as the explanation of why it's > taking so long. Yep, seems to work. > Case 2: Carol misbehaves by pretending Dave was misbehaving, when he wasn't. > > ?* Carol closes the channel with Dave before accepting Dave's resolution > of the HTLC, passing the info to Bob as before. > ? * ?Since he's not cheating, Dave claims the HTLC output on the blockchain. > * Bob sees the HTLC output Carol was pointing at has been spent in a > timely fashion, indicating Carol is cheating. > * Bob claims funds from Alice in a timely fashion, so does not have to > justify being a cheat himself. > * Bob closes the channel with Carol since she's being weird. > > ?That seems like it works as expected to me?? No, that doesn't work: Bob can't tell if Dave really sent it to Carol or not. But Alice doesn't care: she just knows that someone paid 2 txfees in apology money for the delay. To recap (mainly for others), there are two failure cases: The good one: 1) Carol can't reach Dave in 20 seconds (no timely response to the update_add_htlc packet). She send update_remove_htlc() back to Bob, who sends it back to Alice, undoing all the HTLCs just like any route or fee failure. The bad one: 2) Dave starts the HTLC process, but then times out (doesn't resolve HTLC in 20*11 seconds, and doesn't send back a blame packet from Emma, either). In the latter case, Carol dumps the commit tx to the blockchain, and the screwed-up HTLC (and any other casualty HTLCs in progress, sorry). She can include this commit tx + htlc txs in the blame packet back to Bob; there's no reason to name Dave AFAICT[1]. If Carol values Dave too much to drop the channel, she risks that Bob will drop the channel with her. It's not foolproof, but it provides some disincentive. I'm hoping that along with the profit motive, it's sufficient. Cheers, Rusty. [1] Normal bitcoin coin analysis might reveal who Dave is, of course...