[Lightning-dev] refunds -- was Re: BOLT 11, real time micro payments, and route redundancy

Rusty Russell rusty at rustcorp.com.au
Tue Mar 6 03:32:23 UTC 2018


Andy Schroder <info at 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.


More information about the Lightning-dev mailing list