From rusty at rustcorp.com.au Sat Jun 27 06:41:04 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Sat, 27 Jun 2015 16:11:04 +0930 Subject: [Lightning-dev] Payment Re-routing In-Reply-To: <877fqpvhte.fsf@rustcorp.com.au> References: <27F66CF8-85C5-409A-AC15-677C1898A31A@gmail.com> <877fqpvhte.fsf@rustcorp.com.au> Message-ID: <87381dvekf.fsf@rustcorp.com.au> Rusty Russell writes: > Stephen writes: >> Quick question on the security of the Lightning Network when rerouting payments. > > Hi Stephen, > > This is a good question! > >> Say A wants to make a payment to E, and they find a payment channel route through A->B->C->E. The payment is done in increments of 0.01 BTC until the full 1 BTC has been paid. However, part way through the payments, C becomes unresponsive. The contract has already been given to C that guarantees payment if C can produce the pre-image of a certain hash, and C does receive the pre-image from E. They do not share that pre-image with B, though. C must reveal the pre-image, either to B directly or on the blockchain, before B's contract times out, which guarantees B will receive payment. >> >> But A has not paid the full amount to E yet when C became unresponsive. A wants to re-route her payment to avoid delays, so she re-routes the rest of the payments through A->B->D->E. A finishes the payments through this alternate route. But now, can't C reveal the pre-image to B, who then reveals it to A? Which, will effectively steal an extra 0.01 BTC from Alice and give it to E. (C and E could have been colluding to do this, splitting the profits). > > Each of the messages needs a separate preimage. Oops, sorry. Scrap my dumb non-answer, I read your post properly now. Yes, C can just get the preimage from E and collude to steal the funds, which is a nasty failure mode. Delaying the entire payment is a poor option; can anyone see a better one? Cheers, Rusty.