[c-lightning] Towards atomic multipath payments

Rusty Russell rusty at rustcorp.com.au
Wed Jan 16 06:51:40 AEDT 2019


ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty,
>
>> > Good morning c-lightningers,
>> > I would like to propose a JSON-RPC interface for low-level atomic multipath payments.
>>
>> Sorry I've been MIA on this thread, but I was in the middle of moving
>> `pay` out to a plugin.
>
> At least you are actually working on code, unlike I who am now mostly "theoretically a c-lightning developer".

You'll get there again :)

>> A result of that is a new `paystatus` command which details all payment
>> attempts in full detail (not yet persistent across restarts).
>>
>> I agree that we need to change the APIs, but I think we should do it
>> differently: have the pay plugin provide `listpays` which merges
>> `listpayments` back into whole payments.
>>
>
> I worry as this is a breaking change for existing systems.
> Currently, if we use `pay` we use `listpayments` to determine status of each `pay` payment.
> This will change once we enable bass amp and we should instead use `listpays`.

Agreed, it's kind of surprising to have multiple returns for
`listpayments` (possibly with different statuses!).

> I suppose as we are at "beta" level (pre 1.0), we can do:
>
> 1.  Introduce `listpays` as an alias of `listpayments`,
> 2.  Inform everyone to use `listpays` for `pay` attempts and `listpayments` for `sendpay` attempts.
>     Also add this warning strongly to release notes.
> 3.  Make a release *before* AMP is implemented with this `listpays == listpayments` initial implementation with this strong warning to move to using `listpays` for use of `pay`.

How about:
1) Add listpays; this will only ever contain a high level
   succeeded/failed.
2) Deprecate listpayments in favor of listsendpays, which is more
   explicitly associated with sendpay.

Cheers,
Rusty.


More information about the c-lightning mailing list