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.
TheBlueMatt
left a comment
There was a problem hiding this comment.
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.
TheBlueMatt
left a comment
There was a problem hiding this comment.
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.
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.
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
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 thefeaturesfield must set thepayment_secretfeature (and its dependency,var_onion_optin).Fixes #897