From rusty at rustcorp.com.au Tue Mar 6 03:32:23 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 06 Mar 2018 14:02:23 +1030 Subject: [Lightning-dev] refunds -- was Re: BOLT 11, real time micro payments, and route redundancy In-Reply-To: <5A98EE6F.3020509@AndySchroder.com> References: <59A6316A.2050809@AndySchroder.com> <874lsl93c2.fsf@rustcorp.com.au> <59AB9A0F.9040702@AndySchroder.com> <87o9qr7152.fsf@rustcorp.com.au> <59B62689.3020807@AndySchroder.com> <87shfooc3l.fsf@rustcorp.com.au> <5A98EE6F.3020509@AndySchroder.com> Message-ID: <87a7vl98vs.fsf@rustcorp.com.au> Andy Schroder writes: > On 09/14/2017 11:49 PM, Rusty Russell wrote: >> So, we really need to be able to include a (smaller) return onion to >> fix this properly. I've added that to: >> >> https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#refunds >> >> Thanks! >> Rusty. > > If you are including a smaller return onion, you are including that with > the payment? That return onion would be created by the payer since they > know the routes from the payer to the payee? If so, how could this work > if the route no longer has capacity (or goes down) by the time the payee > decides it's going to send the refund back to the payer (which could be > minutes, hours, or days later)? Also, even if all routes are still up, > the payer may not necessarily know how much refund the payee will be > giving them, so they may not necessarily be able to even know what the > best route they should build an onion for? You're right. While optimal routes aren't necessary, failures are possible and made worse by the inability to retry via a different route. I've noted this on the brainstorming phase. We don't currently return a reply message on success, but we could. It's best-effort of course (it won't appear if we drop to chain). I wonder if we could use that somehow. The general solution seems to require an ability to send payments to an anonymous destinations, which we don't have. Thanks! Rusty.