Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pay enhancements: remove legacy, add maxfee and description params #5122

Merged
merged 8 commits into from
Apr 4, 2022

Conversation

rustyrussell
Copy link
Contributor

@rustyrussell rustyrussell commented Mar 24, 2022

This builds on #5121 (first three commits). merged, rebased

That PR made me realize we violate bolt11 when paying a description_hash invoice, so add a description parameter and deprecate payment of such an invoice without it, and I want to do that this release if possible.

However, there was some more work I wanted to do on the way...

@rustyrussell rustyrussell added this to the v0.11 milestone Mar 24, 2022
@rustyrussell rustyrussell force-pushed the pay-enhancements branch 2 times, most recently from b0cf6b0 to a4c1d38 Compare March 30, 2022 03:59
Trips on our RPC checking introduced at the same time: msat should be
an integer or an "xxxmsat"/sat/btc string.

Signed-off-by: Rusty Russell <[email protected]>
I think the new pay command has proven itself in the last 18 months!

Also various pay tests took "compat" then didn't use it, so clean them
up.

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Removed: JSON-RPC: `legacypay` (`pay` replaced it in 0.9.0).
Fixes: ElementsProject#4665
Reported-by: @shesek
Signed-off-by: Rusty Russell <[email protected]>
This is what LND does, and it's better for upper layers than trying to
twist our maxfeepercent / exemptfee heuristics to suit.

(I don't remember who complained about this, sorry!)

I'm doing this now because I want to add YA parameter next!

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Added: JSON-RPC: `pay` has new parameter `maxfee` for setting absolute fee (instead of using `maxfeepercent` and/or `exemptfee`)
Signed-off-by: Rusty Russell <[email protected]>
Changelog-Added: JSON-RPC: `pay` has `description` parameter, will be required if bolt11 only has a hash.
Changelog-Deprecated: JSON-RPC: `pay` for a bolt11 which uses a `description_hash`, without setting `description`.
Copy link
Member

@cdecker cdecker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The requirement for description to be provided as a raw JSON value is too much of a restriction, and copying a potentially large description around to every single sendpay is a horrible waste of bytes (as well as copying the invstring, but that somehow sneaked in while I wasn't looking).

Comment on lines 3566 to 3567
if (p->description)
c->description = tal_strdup(c, p->description);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really bad, as it replicates the description in all child-payments, bloating the database with duplicate values. I thought we did the sane thing, and didn't copy the invstring either, as that is constant in the entire tree, but apparently it got changed somewhere along the line.

There is no point in duplicating these values, and we can use the convention of attaching them only to the root payment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, fixing this is a significant change. Let me try... (and add a test!). I copied the invstring, assuming that was doing The Right Thing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this was all a mess! This duplicate is only for the pre-splitter, but it turns out we were often returning listpays() without any bolt11.

I've fixed that.

Comment on lines +46 to +49
*description* is only required for bolt11 invoices which do not
contain a description themselves, but contain a description hash.
*description* is then checked against the hash inside the invoice
before it will be paid.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requirement is incredibly restrictive: it limits us to invoices with description_hash where the description itself is representable as a raw JSON value. Anything like a PDF, which is something that people have been asking for, is essentially impossible to do with this, unless we allows a hex-encoded value to be provided instead, which makes this cumbersome to use. I know I voted in favor of requiring the description but this version is too limiting imho

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the limits of json!

But we can add descriptionhex later for this case?

Copy link
Contributor Author

@rustyrussell rustyrussell Apr 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked at this, we need a non-trivial amount of re-engineering to add this. We cannot handle bolt11 descriptions which are not basically valid strings right now, and changing that would be an API change everywhere we print description.

So I'm leaving that for next release.

We were setting it on the root, but that doesn't get handed to
sendpay.  Our schema doesn't *require* bolt11, either, so this was
missed (there could be a *bolt12* instead).

Signed-off-by: Rusty Russell <[email protected]>
Changelog-Fixed: JSON-RPC: `listpays` always includes `bolt11` or `bolt12` field.
@rustyrussell
Copy link
Contributor Author

(Fixed keysend with the new invstring deduplication: it can still be NULL in this case!

Copy link
Collaborator

@vincenzopalazzo vincenzopalazzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just some minor doc format, where I'm not sure that the suggested syntax is required.

ACK 9d71db2

@@ -5,8 +5,8 @@ SYNOPSIS
--------

**pay** *bolt11* [*msatoshi*] [*label*] [*riskfactor*]
[*maxfeepercent*] [*retry\_for*] [*maxdelay*] [*exemptfee*]
[*exclude*]
[*maxfeepercent*] [*retry_for*] [*maxdelay*] [*exemptfee*]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[*maxfeepercent*] [*retry_for*] [*maxdelay*] [*exemptfee*]
[*maxfeepercent*] [*retry\_for*] [*maxdelay*] [*exemptfee*]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we've been eliminating those _

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh ok is the opposite!

Comment on lines +8 to +9
[*bolt11*] [*payment_secret*] [*partid*] [*localofferid*] [*groupid*]
[*payment_metadata*] [*description*]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[*bolt11*] [*payment_secret*] [*partid*] [*localofferid*] [*groupid*]
[*payment_metadata*] [*description*]
[*bolt11*] [*payment\_secret*] [*partid*] [*localofferid*] [*groupid*]
[*payment\_metadata*] [*description*]

this is not a new change, at this point, I'm not really sure that \ is required!

@rustyrussell rustyrussell merged commit c1e7c14 into ElementsProject:master Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants