Changed: offers: offers that include offer_paths now omit the offer_issuer_id and sign with the last used blinded path alias' key by default

[21M4TW]

• Removing the offer_issuer_id from created offers when there's an offer_path, as explained in the Bolt12 specifications. This saves space and enhance privacy when it's not needed because we already have a blinded path.
• Allowing signing an invoice referencing the above offer by signing with the last used blinded node id, as per the Bolt12 specifications.
• Adding a force_issuer_id optional field to the offer command so the offer_issuer_id is included even when not required due the presence of blinded paths.

• [ x] The changelog has been updated in the relevant commit(s) according to the guidelines.
• [ x] Tests have been added or modified to reflect the changes.
• [ x] Documentation has been reviewed and updated as needed.
• [ x] Related issues have been listed and linked, including any that this PR closes.

[21M4TW]

As requested by @vincenzopalazzo

[rustyrussell]

This invoice is invalid: let's break it down by type, length, value (hex)

• 00 10 fc84667539e41bd6564fbbdb87d3375e
• 02 20 43497fd7f826957108f4a30fd9cec3aeba79972084e90ead01ea330900000000
• 0a 07 6e657774657374
• 10 ee 03e5c9e190e93af5f757e533ad12ca2da9daef99f337a7af0320e70feae9a7890003b224fa465507bf714641c64a1018ccc05bbcda60d3aa15212e577dfd8e0fb9ea020202a9628f99168a0b09c8ddc71bd9191e31f871075cd8854968dbb72d47c3912100338139ad02276007ea918fa7208765a306c200c7af814c0284deca7ced13b36863c84d03393572ef44d44d78cce9b0bf58a6ff8c02c1a165fe61b4fc6c2097bee34d538fbc84902df62e0bf8eac81495971d491b3600324a46184f1c237f594b5cd4797f794c0b3f2267b8ff51e55376aa7053a5b708ad7c7056dd0b537494580af8f872b9972cebba
• 50 20 43497fd7f826957108f4a30fd9cec3aeba79972084e90ead01ea330900000000
• 52 01 0b
• 54 00
• 58 21 037d942d1f385d68bf600ed3ce14d1e0b84f99eaa594196e60dedc4a6eae3064fe
• a0 fd00fd 03e5c9e190e93af5f757e533ad12ca2da9daef99f337a7af0320e70feae9a789000304e360cbffb0e81e6489baad6b24762b28c1f98bec4fcd7771db32906baababd02038e48152e6f2388282153b34bd136a812b71648f3c15c894d1c50afc45ac154cd0042f6ace0f6e49219b7dbca6f38e0f53a2f70b06403692dfa04d6ba0734fb2084b1c4cf1d7d42567c59715cdbef764fe63440ddb41e7fe67e34be6bdccac4a59f7d596002d7759d4d3b3d3a2fe68bffbbcad4b68456f60fe8c0877c92990e7ed402939cc000323fd7cf52b11be81729bcf3a0dcf3b9aae68351b3f1bd40c29db363573aebefa38d44988c0929ae3c1ad3052b48d38327ab6b
• a2 1c 000000010000000a0010000000000000000000000000002380000000
• a4 04 68ac799e
• a8 20 d6e635a2de2108f755ac860e2a6e80ab9798dc73ab55e6b6c54eda1025e6dadf
• aa 01 0b
• ae 03 020000
• f0 40 9558b15edc9a8b402eb1a54512caae3b82d31f61c04e849a5491d075d5d0ebf7b3f0ae39e8541496ec374a38ec8ea947de2a74ba4b22efb34a859e55506726cc

This has no "b0" field (i.e. type: 176 (invoice_node_id)).

To quote bolt12:

A writer of an invoice:
...
  - if `offer_issuer_id` is present:
    - MUST set `invoice_node_id` to the `offer_issuer_id`
  - otherwise, if `offer_paths` is present:
    - MUST set `invoice_node_id` to the final `blinded_node_id` on the path it received the invoice request

And:

A reader of an invoice:
  - MUST reject the invoice if `invoice_amount` is not present.
  - MUST reject the invoice if `invoice_created_at` is not present.
  - MUST reject the invoice if `invoice_payment_hash` is not present.
  - MUST reject the invoice if `invoice_node_id` is not present.

So, who is producing this invalid invoice?

[21M4TW]

Thank you Rusty, and sorry for the late reply.

I just updated this PR with what I think fixes the issue. It now does the following:
-When offer_paths are present and offer_issuer_id is no longer needed, set offer_issuer_id to NULL in found_best_peer
-In listoffers_done, when there is no offer_issuer_id, set invoice_node_id to the final blinded_node_id from the used offer path (as described in the Bolt12 specs)
-handle_sign_bolt12 was only used to sign invoices, but was not able to sign using the blinded node id. I modified the function to support using a path_pubkey (I created the function node_blinded_privkey as well).

So as far as I know, this code is now properly working and addresses the issues I had identified. The invoice signature is recognized as valid by fetchinvoice, and it works whether or not an offer contains an issuer_id. Thank you!

[21M4TW]

This solves the issuer_id issue identified in #4689

[madelinevibes]

It seems this one slipped through the 25.12 release crack because the issue it was linked to had been closed. will request and prompt for review ahead of early 2026 release. @21M4TW can you please rebase?

[21M4TW]

It seems this one slipped through the 25.12 release crack because the issue it was linked to had been closed. will request and prompt for review ahead of early 2026 release. @21M4TW can you please rebase?

Thanks. I just rebased it to the latest commit from master.

[madelinevibes]

thanks! now over to @endothermicdev for review please.

[21M4TW]

I'm just catching up with this PR, but the commit message is unclear. I'm not convinced anything is currently broken - if so, please describe the issue and preferably reproduce it with a test so we can make sure to check for it in the future.

I think this is doing two things:

* Removing the `offer_issuer_id` from created offers when there's an `offer_path`.  I presume this is to save space and/or enhance privacy when it's not needed because we already have a blinded path.

* Allowing signing an invoice referencing the above offer by signing with the blinded node id.

In that case, it would be nice to document the rationale for the change in the commit, and the changelog should be changed, because it changes behavior rather than fixing a broken feature. The commit message would then look something like:

offers: omit `offer_issuer_id` from new offers when using blinded `offer_path`s

describe the rationale and changes...

Changelog-Changed: offers: offers that include offer_paths now omit the offer_issuer_id and sign with the blinded path alias' key

This is a nice improvement! The only other thing is I wonder if it's always correct to omit offer_issuer_id if we can. Would a vendor want to force inclusion here so that customers can verify they're dealing with the right node? In that case, an optional parameter to the offer rpc to force inclusion of the offer_issuer_id might be appropriate.

I agree with you that it was not "broken" in the sense that it was not preventing a payment, but the offer from a node with only private channels contained the unannounced node ID of that node. I can tag it as "changed". I will look into adding an optional parameter to the offer rpc. Thanks!

[21M4TW]

@endothermicdev I added an optional force_issuer_id field to the offer rpc as you suggested (hopefully I changed all the files I had to change regarding this).

[vincenzopalazzo]

I still need to review the core part of this PR because it requires me to look at the code that I haven't been looking at for a long time, but I left some comments during my light review.

BTW review the commit is hard because you are putting all together, unfortunately, and probably splitting this in the right way is hard too, because it's like a chicken and eggs problem, but I would love to see the gen file stripped out and add them in a separate commit.

What I would do if I were writing the commit from 0 is:

1. Core functionality
2. auto gen files
3. tests

But if the CLN team is fine with the current organisation, I am fine too!

[vincenzopalazzo]

assert on the offer kind, like you expect that there is a blinded path and offer issuer id, otherwise this test will pass also if there is no offer issuer id because the code should use the blinded path introductory node

[vincenzopalazzo]

I need to look more inside the code, but is the path_pubkey already includd inside the invoice? the spec should enforce to copy it down IIRC

[vincenzopalazzo]

I checked this more closely: path_pubkey is not copied into the invoice TLVs themselves. In this patch it is passed out-of-band to createinvoice and only used to select which key hsmd signs the invoice with, so the spec copy-down requirement does not apply to that value directly.

The concrete issue I do see here is HSM compatibility: this patch changes hsmd_sign_bolt12 (message 25) from the old u16 + bytes payload to ?pubkey, but lightningd still negotiates with HSM versions 5-7 and always calls towire_hsmd_sign_bolt12 with the new encoding. That means an older external signer can still pass init and then misparse the first BOLT12 invoice-signing request. I think this needs either a new wire message / version-gated fallback, or a minimum HSM bump to 7 so older signers fail fast at startup.

[21M4TW]

I still need to review the core part of this PR because it requires me to look at the code that I haven't been looking at for a long time, but I left some comments during my light review.

BTW review the commit is hard because you are putting all together, unfortunately, and probably splitting this in the right way is hard too, because it's like a chicken and eggs problem, but I would love to see the gen file stripped out and add them in a separate commit.

What I would do if I were writing the commit from 0 is:

1. Core functionality

2. auto gen files

3. tests

But if the CLN team is fine with the current organisation, I am fine too!

If I was putting the new force_issuer_id part in a separate commit it would separate the core functionalities quite well I think. Do you want me to do that?

For the core functionalities, it is mostly divided in two, that is the more trivial part where I simply set the offer_issuer_id to NULL when offer_paths is present (and the issuer ID is not enforced through force_issuer_id), and the part where I pass down the last blinded_node_id and the associated path_pubkey starting at the onion message level, and where I use these to tweak the private key and sign the invoice.

[vincenzopalazzo]

Code Review

Positive Aspects

• The core approach is spec-correct: omitting offer_issuer_id when offer_paths is present saves space and enhances privacy, as per BOLT #12.
• The node_blinded_privkey derivation correctly follows BOLT #4 (ECDH + HMAC blinding factor), which is the right way to derive the signing key for the blinded node.
• The force_issuer_id escape hatch addresses the valid use case endothermicdev raised (vendor identity verification), and the fallback re-adding offer_issuer_id when no blinded path can be created is correct.
• The test covers both the default (omit issuer_id) and forced-inclusion paths.

---

Issues & Suggestions

1. Error message typo propagated from old code (Cleanup)

hsmd/libhsmd.c — the new node_blinded_privkey has:

hsmd_status_failed(STATUS_FAIL_INTERNAL_ERROR,
    "Could tweak bolt12 key.");

This is in the failure path (!= 1), so it should say "Could not tweak bolt12 key." This was a pre-existing issue in the old handle_sign_bolt12, but since the function is being rewritten, worth fixing.

2. Pointer declaration style (Cleanup)

CLN convention is struct foo *ptr, not struct foo* ptr. Two occurrences:

• hsmd/libhsmd.c: struct pubkey* path_pubkey
• lightningd/invoice.c: const struct pubkey* path_pubkey

3. Indentation and whitespace in offers_offer.c (Cleanup)

if (!we_want_blinded_path(cmd->plugin, false) || *force_issuer_id ) {
  offer->offer_issuer_id = tal_dup(offer, struct pubkey, &id);
}

• Uses 2-space indent instead of tab (CLN uses tabs)
• Trailing space before ) in *force_issuer_id )

4. Comment typo in offers_offer.c (Cleanup)

"it can be forced is requested" should be "it can be forced if requested"

5. createinvoice schema not updated (Medium)

The path_pubkey optional parameter was added to createinvoice in lightningd/invoice.c, but there is no corresponding update to doc/schemas/createinvoice.json. This is a user-facing API change that should be documented.

6. Empty line inside if block (Cleanup)

plugins/offers_invreq_hook.c:

if (!ir->inv->offer_issuer_id && ir->invreq->offer_paths) {
    ir->inv->invoice_node_id = ir->blinded_node_id;

} else {

Trailing blank line before } else { is unusual for CLN style.

---

Summary

Concept ACK. The spec compliance and crypto derivation are correct. Needs a minor fix for the createinvoice schema documentation and some style cleanups before merging.

[madelinevibes]

@21M4TW can you update per @vincenzopalazzo 's coments?

Concept ACK. The spec compliance and crypto derivation are correct. Needs a minor fix for the createinvoice schema documentation and some style cleanups before merging.

By the end of this week (with enough time for someone to review) is the timeline so we can add this to 26.06? Release candidate planned for Monday 11 May.

If you can't we'll move it to 25.09.

[vincenzopalazzo]

@madelinevibes this is also a kind of privacy like feature that people want to have, probably if there is anyone taking it over I could try to pair with claude and take it over if you want to include it inside the current release

[madelinevibes]

@vincenzopalazzo if you are @21M4TW are on the same page, then it'd be great to get in! We will need it by Thursday, Friday at the latest Australia time in order to give time to review for the Release candidate.

[sangbida]

It would be really great if this PR could be cleaned up a bit more. We want commits to be atomic (do one thing at a time) to preserve bisectability. The changelog is added in the commit description and the commit message starts with the relevant subdaemon, such as lightningd: or onchaind:. Our style guide lives here and has a lot more info: https://docs.corelightning.org/docs/coding-style-guidelines#creating-pull-requests