[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