From stephencalebmorse at gmail.com Tue Jun 30 04:59:43 2015 From: stephencalebmorse at gmail.com (Stephen Morse) Date: Tue, 30 Jun 2015 00:59:43 -0400 Subject: [Lightning-dev] Payment Re-routing In-Reply-To: <87381dvekf.fsf@rustcorp.com.au> References: <27F66CF8-85C5-409A-AC15-677C1898A31A@gmail.com> <877fqpvhte.fsf@rustcorp.com.au> <87381dvekf.fsf@rustcorp.com.au> Message-ID: 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. To fix the non-malicious case, C could get a refund from E (a new signed transaction with a lower lock time), if C knows he has been offline for longer than B's willingness to wait before re-routing. But this isn't perfect, or even good, because E cannot know that C isn't just trying to get a refund even though they have taken the payment from B. In fact, C is guaranteed the payment from B, since they have the pre-image. > Delaying the entire payment is a poor option; can anyone see a better > one? > Like you say, delaying the payment seems like a bad way to go, as then the payments wouldn't be quite "Lightning" fast anymore. 99% of the payment could be re-routed though. Perhaps the 99% could be re-routed, while A waits for C to rejoin. Or if multiple paths are being used to process the payment, just redistribute the remaining payments allotted for the broken path among the other functioning paths. The bigger problem here seems to be that the incentives are slightly skewed in favor of dishonestly. One can minimize the impact of that dishonesty by breaking the payment into smaller chunks and across diverse paths, but this comes at the cost of bandwidth and speed. Some sort of a rating system could come into play possibly, if nothing can be cryptographically worked out. Best, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: