[Lightning-dev] Payment Re-routing

[Rusty Russell]

Stephen Morse <stephencalebmorse at gmail.com> writes:
> Hi Rusty,
>
> On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
>
>> Yes, C can just get the preimage from E and collude to steal the funds,
>> which is a nasty failure mode.
>>
> This scenario may even happen non-maliciously, if C has an honest outage
> and attempts to pick up where it left off on each of its channels.

Indeed.

Off-list, Joseph Poon suggested a solution, which I urged him to post
here.  As he hasn't done so, I'll try to paraphrase.

So the basic problem is that A -> C -> E fails because C is
unresponsive: A is waiting (say) 2 days before the HTLC to C times out.

Joseph's solution is that E can route a conditional refund back to A
with a larger timeout (say 3 days) via some other route: this pays back
the amount to A if they present the preimage for the initial stalled
payment and another preimage A only has.  This serves as a guarantee
that E will not reveal the preimage required to take the stalled
payment.

This raises other questions, such as who would pay E (and any other
intermediate nodes) for locking up their money for such a time.  Could A
provide evidence that the route really had timed out?  How many times
can A claim "payment failed"?  etc.

In general, how nodes get paid is an open question; I'll add this to the
pile.  One problem at a time though...

Cheers,
Rusty.