Andy Schroder <i...@andyschroder.com> 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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
