[Lightning-dev] Payment Re-routing

Rusty Russell rusty at rustcorp.com.au
Sat Jun 27 06:41:04 UTC 2015


Rusty Russell <rusty at rustcorp.com.au> writes:
> Stephen <stephencalebmorse at gmail.com> 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.


More information about the Lightning-dev mailing list