-
Notifications
You must be signed in to change notification settings - Fork 494
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
Add payment secret feature to Bolt 11 test vectors #898
Conversation
Bolt 11 invoices must contain a `payment_secret`, which means that the `features` field must set the `payment_secret` feature (and its dependency, `var_onion_optin`). Fixes #897
Add feature bits, as indicated by lightning/bolts#898
We now match the spec once lightning/bolts#898 is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least the "Signature is not recoverable." and "Invalid sub-millisatoshi precision." failure cases also need a feature flag, likely others as well but those are just the two that our implementation complains about as missing feature.
This pulls the BOLT 11 test vectors from lightning/bolts#898, tweaking our tests to properly handle them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes here LGTM, verified they pass our own tests, though the error cases could use the feature flag as well.
|
||
> ### On mainnet, with fallback address 1RustyRX2oai4EYYDpQGWvEL62BBGqN9T with extra routing info to go via nodes 029e03a901b85534ff1e92c43c74431f7ce72046060fcf7a95c37e148f78c77255 then 039e03a901b85534ff1e92c43c74431f7ce72046060fcf7a95c37e148f78c77255 | ||
> lnbc20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqqqqqpqqqqq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqqqqqgqqqqq7qqzqg042ea62q6wnxh909rfuu4x2amxc59mj99mrhr32kvqhytrm04us8edg0syy9n0ukgam0ud20jcxwskphv3rzpnengjsf8m3w9u5w8cqzrhtg2 | ||
> lnbc20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqsfpp3qjmp7lwpagxun9pygexvgpjdc4jdj85fr9yq20q82gphp2nflc7jtzrcazrra7wwgzxqc8u7754cdlpfrmccae92qgzqvzq2ps8pqqqqqqpqqqqq9qqqvpeuqafqxu92d8lr6fvg0r5gv0heeeqgcrqlnm6jhphu9y00rrhy4grqszsvpcgpy9qqqqqqgqqqqq7qqzq9qrsgqdfjcdk6w3ak5pca9hwfwfh63zrrz06wwfya0ydlzpgzxkn5xagsqz7x9j4jwe7yj7vaf2k9lqsdk45kts2fd0fkr28am0u4w95tt2nsq76cqw0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you're tweaking this, can you add an "0x" prefix on the short_channel_id fields a few lines down?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed to the friendlier short_channel_id notation that uses blockheight in 45222fb
Thanks, I wondered where that would be verified in each implementation, in eclair this is verified last, but there's no reason other implementations do the same. I'll update all failure cases that make sense. |
As you pointed out, only the last two failure test vectors need to be updated, the others have a completely invalid format which should always be checked before the actual contents. I updated them in c32d06a |
We now match the spec once lightning/bolts#898 is merged.
LDK still reports this failure case as "NoPaymentSecret": "Signature is not recoverable. |
This pulls the BOLT 11 test vectors from lightning/bolts#898, tweaking our tests to properly handle them.
This test vector was generated by creating a valid invoice, then flipping the recoveryId to be 2 instead of 0 or 1.
Right, there's no reason to assume recovering the pubkey from the sig should be done before validating the invoice's contents. |
This pulls the BOLT 11 test vectors from lightning/bolts#898, tweaking our tests to properly handle them.
Thanks! Tested the latest and it all passes/fails with expected errors. |
We now match the spec once lightning/bolts#898 is merged.
This pulls the BOLT 11 test vectors from lightning/bolts#898, tweaking our tests to properly handle them.
This pulls the BOLT 11 test vectors from lightning/bolts#898, tweaking our tests to properly handle them.
Add feature bits, as indicated by lightning/bolts#898
Merging as per yesterday's spec meeting. |
Add payment secrets (see lightning/bolts#887) Add feature bits (see lightning/bolts#898)
We now match the spec once lightning/bolts#898 is merged.
We now match the spec once lightning/bolts#898 is merged.
Bolt 11 invoices must contain a `payment_secret`, which means that the `features` field must set the `payment_secret` feature (and its dependency, `var_onion_optin`). Fixes lightning#897
Bolt 11 invoices must contain a `payment_secret`, which means that the `features` field must set the `payment_secret` feature (and its dependency, `var_onion_optin`). Fixes lightning#897
we now require payment_secret both for sending and for receiving (previously was optional for both) see lightning/bolts#898 ACINQ/eclair#1810 ElementsProject/lightning#4646 note: payment_secret depends on var_onion_optin, so that becomes mandatory as well, however this commit does not yet remove the ability of creating legacy onions
we now require payment_secret both for sending and for receiving (previously was optional for both) see lightning/bolts#898 ACINQ/eclair#1810 ElementsProject/lightning#4646 note: payment_secret depends on var_onion_optin, so that becomes mandatory as well, however this commit does not yet remove the ability of creating legacy onions
Bolt 11 invoices must contain a
payment_secret
, which means that thefeatures
field must set thepayment_secret
feature (and its dependency,var_onion_optin
).Fixes #897