Part 6: final catchup to latest BOLT spec #7476
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d03d8f9 to
d1e83aa
Compare
d95b817 to
950ab26
Compare
niftynei
reviewed
Jul 31, 2024
| "Invalid tweak"); | ||
| /* If the payer_id is not our node id, we sanity check that it | ||
| * correctly maps from invreq_metadata */ | ||
| if (!pubkey_eq(invreq->invreq_payer_id, &cmd->ld->our_pubkey)) { |
There was a problem hiding this comment.
why is this so cool. very cool.
950ab26 to
7fcb9f2
Compare
This mistake was revealed when we start using experimental range for recurrence (next commit). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The `invreq_recurrence_counter` clashes with the coming addition of invreq_paths, so we might as well move them all to the new experimental ranges. Changelog-EXPERIMENTAL: Recurring offers had incompatible changes, won't work against older versions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…ecated. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the blinded path for offerless invoice_requests. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a good idea, but also specifically called out in the latest BOLT spec. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The latest spec allows this to be omitted iff there is a blinded path and it would be made up anyway. In that case, the key they will use to sign the invoice will be the final blinded key in the path we use. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…rectly. 1. Missing offer_description iff offer_amount also missing. 2. Missing offer_issuer_id iff offer_paths is present. 3. Short channel id on introduction point. 4. Experimental range. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
invoice_path_id is actually a generic path_id thing, so rename it. We're going to use the same scheme for path secrets and the tweak to node_id when we create a fake pubkey for invoice_requests, so a new header is appropriate. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For now we only use a fake id for requesting invoices (as a payer_key), but we will eventually use this generically, and we want plugins to be able to map them too, so use the same scheme as path_id: a generated secret using the makesecret API. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
… our key. The current interface, if given a tweak, uses a *different secret key* and tweaks it. This was an early experiment: we will switch to using a secret tweak for invoice_requests like we do for invoice path ids. To make sure there's no funny business, *hsmd* hashes to form the tweak (i.e. no zero tweaks!). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…ng invoices. This is going to allow us to move it out from lightingd into plugin, easily. It's legal because the combination of offer id and label must be unique (with recurrence, we use the same metadata anyay, since they want to correlate with prior payments anyway). We already broke recurrence in this PR, so we don't need another note to say we're changing the key derivation. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They can do it now: before it would have been awkward to look up previous payments to match it up for recurring offers (which need to use the same key, hence the same invreq_metadata). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…request`. It's an internal difference, so doesn't actually break compatibility (it would if we tried to prove we owned an old invoicerequest, but we don't have infrastructure for that anyway). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…or createinvoicerequest. It's an internal undocumented interface, which makes this change less painful. We *do* check that the invreq_metadata maps to the given invreq_payer_id, which would is required for us to sign it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…necessary. Changelog-EXPERIMENTAL: offers: `invoicerequest` will set a blinded path if we're an unannounced node. Changelog-EXPERIMENTAL: offers: `sendinvoice` will use a blinded path in an invoice_request, if specified. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a final sweep to match the current BOLT12 text:
1563d13999d342680140c693de0b9d65aa522372 ("More bolt12 test vectors.")
Only two code changes, to change the order of checks to match the bolt,
and to give a warning on decode if a path is empty.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7fcb9f2 to
5298871
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(based on #7474 )Merged!The final changes to the spec are reflected here, and we get more serious about ID aliases. These are currently only used for invoice requests to remote nodes, but they used a tweak on different pubkey than the normal one, which made it hard for plugins to operate. Change them to tweak based on the node id, which unfortunately means a new HSM function (a trivial one though!).