From rusty at rustcorp.com.au  Sat Jun 27 05:30:53 2015
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Sat, 27 Jun 2015 15:00:53 +0930
Subject: [Lightning-dev] Payment Re-routing
In-Reply-To: <27F66CF8-85C5-409A-AC15-677C1898A31A@gmail.com>
References: <27F66CF8-85C5-409A-AC15-677C1898A31A@gmail.com>
Message-ID: <877fqpvhte.fsf@rustcorp.com.au>

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.

The simplest method is for E to simply provide A with (say) 100 hashes
to use as she wishes.

Though I think we can do better than this using crypto rather than
hashes, in practice producing 100 preimages is pretty easy (hash a
per-payment secret + counter).

Cheers,
Rusty.