From rusty at rustcorp.com.au Tue Jun 30 08:03:00 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 30 Jun 2015 17:33:00 +0930 Subject: [Lightning-dev] Payment Re-routing In-Reply-To: References: <27F66CF8-85C5-409A-AC15-677C1898A31A@gmail.com> <877fqpvhte.fsf@rustcorp.com.au> <87381dvekf.fsf@rustcorp.com.au> Message-ID: <87lhf1sjwr.fsf@rustcorp.com.au> Stephen Morse writes: > Hi Rusty, > > On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell > 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.