Changed/Added: Bolt12 deterministic path key for offer paths' node IDs recovery by 21M4TW · Pull Request #8853 · ElementsProject/lightning

21M4TW · 2026-01-19T15:38:05Z

This PR is an extension to #8238. In addition to signing invoices that don't have an offer_issuer_id using the key from the last used blinded_path node, this new PR generates the private path key deterministically (see derive_first_path_privkey from common/blindedpath.c) in such situation and it is then used to recover the offer paths' node IDs (unblind_paths from common/blindedpath.c). It also derives the path_pubkey that is then used to tweak the private key to sign the invoice. In contrast, in #8238, path_pubkey was derived using information from the onion message, but the offer paths' node IDs could not be recovered, as the path_privkey information was lost after the offer was generated.

So in addition to generating offers without an issuer_id and signing related invoices using the proper key, this PR recovers the offer paths' node IDs, which will enable the generation of invoices with matching paths (addressing #8041) in a future PR.

In this PR, the first path private key for a given path is generated using
e_0 = HMAC256(\text{"first_path_privkey"}, SHA256(path_id || N_0 || path_index))

where path_id is the secret stored in the offer's encrypted_data_tlv and that is only known by the payee, and where N_0 and path_index are the first_node_id and the 64-bit index of the path, respectively.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

The changelog has been updated in the relevant commit(s) according to the guidelines.
Tests have been added or modified to reflect the changes.
Documentation has been reviewed and updated as needed.
Related issues have been listed and linked, including any that this PR closes.
Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

offers: offers that include offer_paths now omit offer_issuer_id and sign with the blinded path alias' key by default. An optional force_issuer_id field is also added to the offer command so the offer_issuer_id is included even when not required to reach the issuer due to the existence of offer_paths.

…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

madelinevibes · 2026-06-15T05:43:00Z

@21M4TW would love to see the conflicts resolve so we can merge this

21M4TW · 2026-01-19T15:38:05Z

This PR is an extension to #8238. In addition to signing invoices that don't have an offer_issuer_id using the key from the last used blinded_path node, this new PR generates the private path key deterministically (see derive_first_path_privkey from common/blindedpath.c) in such situation and it is then used to recover the offer paths' node IDs (unblind_paths from common/blindedpath.c). It also derives the path_pubkey that is then used to tweak the private key to sign the invoice. In contrast, in #8238, path_pubkey was derived using information from the onion message, but the offer paths' node IDs could not be recovered, as the path_privkey information was lost after the offer was generated.

So in addition to generating offers without an issuer_id and signing related invoices using the proper key, this PR recovers the offer paths' node IDs, which will enable the generation of invoices with matching paths (addressing #8041) in a future PR.

In this PR, the first path private key for a given path is generated using
e_0 = HMAC256(\text{"first_path_privkey"}, SHA256(path_id || N_0 || path_index))

where path_id is the secret stored in the offer's encrypted_data_tlv and that is only known by the payee, and where N_0 and path_index are the first_node_id and the 64-bit index of the path, respectively.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

The changelog has been updated in the relevant commit(s) according to the guidelines.
Tests have been added or modified to reflect the changes.
Documentation has been reviewed and updated as needed.
Related issues have been listed and linked, including any that this PR closes.
Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

offers: offers that include offer_paths now omit offer_issuer_id and sign with the blinded path alias' key by default. An optional force_issuer_id field is also added to the offer command so the offer_issuer_id is included even when not required to reach the issuer due to the existence of offer_paths.

…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

madelinevibes · 2026-06-15T05:43:00Z

@21M4TW would love to see the conflicts resolve so we can merge this

21M4TW · 2026-01-19T15:38:05Z

This PR is an extension to #8238. In addition to signing invoices that don't have an offer_issuer_id using the key from the last used blinded_path node, this new PR generates the private path key deterministically (see derive_first_path_privkey from common/blindedpath.c) in such situation and it is then used to recover the offer paths' node IDs (unblind_paths from common/blindedpath.c). It also derives the path_pubkey that is then used to tweak the private key to sign the invoice. In contrast, in #8238, path_pubkey was derived using information from the onion message, but the offer paths' node IDs could not be recovered, as the path_privkey information was lost after the offer was generated.

So in addition to generating offers without an issuer_id and signing related invoices using the proper key, this PR recovers the offer paths' node IDs, which will enable the generation of invoices with matching paths (addressing #8041) in a future PR.

In this PR, the first path private key for a given path is generated using
e_0 = HMAC256(\text{"first_path_privkey"}, SHA256(path_id || N_0 || path_index))

where path_id is the secret stored in the offer's encrypted_data_tlv and that is only known by the payee, and where N_0 and path_index are the first_node_id and the 64-bit index of the path, respectively.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

The changelog has been updated in the relevant commit(s) according to the guidelines.
Tests have been added or modified to reflect the changes.
Documentation has been reviewed and updated as needed.
Related issues have been listed and linked, including any that this PR closes.
Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

offers: offers that include offer_paths now omit offer_issuer_id and sign with the blinded path alias' key by default. An optional force_issuer_id field is also added to the offer command so the offer_issuer_id is included even when not required to reach the issuer due to the existence of offer_paths.

…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

madelinevibes · 2026-06-15T05:43:00Z

@21M4TW would love to see the conflicts resolve so we can merge this

21M4TW · 2026-01-19T15:38:05Z

This PR is an extension to #8238. In addition to signing invoices that don't have an offer_issuer_id using the key from the last used blinded_path node, this new PR generates the private path key deterministically (see derive_first_path_privkey from common/blindedpath.c) in such situation and it is then used to recover the offer paths' node IDs (unblind_paths from common/blindedpath.c). It also derives the path_pubkey that is then used to tweak the private key to sign the invoice. In contrast, in #8238, path_pubkey was derived using information from the onion message, but the offer paths' node IDs could not be recovered, as the path_privkey information was lost after the offer was generated.

So in addition to generating offers without an issuer_id and signing related invoices using the proper key, this PR recovers the offer paths' node IDs, which will enable the generation of invoices with matching paths (addressing #8041) in a future PR.

In this PR, the first path private key for a given path is generated using
e_0 = HMAC256(\text{"first_path_privkey"}, SHA256(path_id || N_0 || path_index))

where path_id is the secret stored in the offer's encrypted_data_tlv and that is only known by the payee, and where N_0 and path_index are the first_node_id and the 64-bit index of the path, respectively.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

The changelog has been updated in the relevant commit(s) according to the guidelines.
Tests have been added or modified to reflect the changes.
Documentation has been reviewed and updated as needed.
Related issues have been listed and linked, including any that this PR closes.
Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

offers: offers that include offer_paths now omit offer_issuer_id and sign with the blinded path alias' key by default. An optional force_issuer_id field is also added to the offer command so the offer_issuer_id is included even when not required to reach the issuer due to the existence of offer_paths.

…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

madelinevibes · 2026-06-15T05:43:00Z

@21M4TW would love to see the conflicts resolve so we can merge this

21M4TW · 2026-01-19T15:38:05Z

This PR is an extension to #8238. In addition to signing invoices that don't have an offer_issuer_id using the key from the last used blinded_path node, this new PR generates the private path key deterministically (see derive_first_path_privkey from common/blindedpath.c) in such situation and it is then used to recover the offer paths' node IDs (unblind_paths from common/blindedpath.c). It also derives the path_pubkey that is then used to tweak the private key to sign the invoice. In contrast, in #8238, path_pubkey was derived using information from the onion message, but the offer paths' node IDs could not be recovered, as the path_privkey information was lost after the offer was generated.

So in addition to generating offers without an issuer_id and signing related invoices using the proper key, this PR recovers the offer paths' node IDs, which will enable the generation of invoices with matching paths (addressing #8041) in a future PR.

In this PR, the first path private key for a given path is generated using
e_0 = HMAC256(\text{"first_path_privkey"}, SHA256(path_id || N_0 || path_index))

where path_id is the secret stored in the offer's encrypted_data_tlv and that is only known by the payee, and where N_0 and path_index are the first_node_id and the 64-bit index of the path, respectively.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

The changelog has been updated in the relevant commit(s) according to the guidelines.
Tests have been added or modified to reflect the changes.
Documentation has been reviewed and updated as needed.
Related issues have been listed and linked, including any that this PR closes.
Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

offers: offers that include offer_paths now omit offer_issuer_id and sign with the blinded path alias' key by default. An optional force_issuer_id field is also added to the offer command so the offer_issuer_id is included even when not required to reach the issuer due to the existence of offer_paths.

…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

madelinevibes · 2026-06-15T05:43:00Z

@21M4TW would love to see the conflicts resolve so we can merge this

21M4TW · 2026-01-19T15:38:05Z

This PR is an extension to #8238. In addition to signing invoices that don't have an offer_issuer_id using the key from the last used blinded_path node, this new PR generates the private path key deterministically (see derive_first_path_privkey from common/blindedpath.c) in such situation and it is then used to recover the offer paths' node IDs (unblind_paths from common/blindedpath.c). It also derives the path_pubkey that is then used to tweak the private key to sign the invoice. In contrast, in #8238, path_pubkey was derived using information from the onion message, but the offer paths' node IDs could not be recovered, as the path_privkey information was lost after the offer was generated.

So in addition to generating offers without an issuer_id and signing related invoices using the proper key, this PR recovers the offer paths' node IDs, which will enable the generation of invoices with matching paths (addressing #8041) in a future PR.

In this PR, the first path private key for a given path is generated using
e_0 = HMAC256(\text{"first_path_privkey"}, SHA256(path_id || N_0 || path_index))

where path_id is the secret stored in the offer's encrypted_data_tlv and that is only known by the payee, and where N_0 and path_index are the first_node_id and the 64-bit index of the path, respectively.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

The changelog has been updated in the relevant commit(s) according to the guidelines.
Tests have been added or modified to reflect the changes.
Documentation has been reviewed and updated as needed.
Related issues have been listed and linked, including any that this PR closes.
Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

offers: offers that include offer_paths now omit offer_issuer_id and sign with the blinded path alias' key by default. An optional force_issuer_id field is also added to the offer command so the offer_issuer_id is included even when not required to reach the issuer due to the existence of offer_paths.

…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

madelinevibes · 2026-06-15T05:43:00Z

@21M4TW would love to see the conflicts resolve so we can merge this

21M4TW · 2026-01-19T15:38:05Z

This PR is an extension to #8238. In addition to signing invoices that don't have an offer_issuer_id using the key from the last used blinded_path node, this new PR generates the private path key deterministically (see derive_first_path_privkey from common/blindedpath.c) in such situation and it is then used to recover the offer paths' node IDs (unblind_paths from common/blindedpath.c). It also derives the path_pubkey that is then used to tweak the private key to sign the invoice. In contrast, in #8238, path_pubkey was derived using information from the onion message, but the offer paths' node IDs could not be recovered, as the path_privkey information was lost after the offer was generated.

So in addition to generating offers without an issuer_id and signing related invoices using the proper key, this PR recovers the offer paths' node IDs, which will enable the generation of invoices with matching paths (addressing #8041) in a future PR.

In this PR, the first path private key for a given path is generated using
e_0 = HMAC256(\text{"first_path_privkey"}, SHA256(path_id || N_0 || path_index))

where path_id is the secret stored in the offer's encrypted_data_tlv and that is only known by the payee, and where N_0 and path_index are the first_node_id and the 64-bit index of the path, respectively.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

The changelog has been updated in the relevant commit(s) according to the guidelines.
Tests have been added or modified to reflect the changes.
Documentation has been reviewed and updated as needed.
Related issues have been listed and linked, including any that this PR closes.
Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

offers: offers that include offer_paths now omit offer_issuer_id and sign with the blinded path alias' key by default. An optional force_issuer_id field is also added to the offer command so the offer_issuer_id is included even when not required to reach the issuer due to the existence of offer_paths.

…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

madelinevibes · 2026-06-15T05:43:00Z

@21M4TW would love to see the conflicts resolve so we can merge this

21M4TW · 2026-01-19T15:38:05Z

This PR is an extension to #8238. In addition to signing invoices that don't have an offer_issuer_id using the key from the last used blinded_path node, this new PR generates the private path key deterministically (see derive_first_path_privkey from common/blindedpath.c) in such situation and it is then used to recover the offer paths' node IDs (unblind_paths from common/blindedpath.c). It also derives the path_pubkey that is then used to tweak the private key to sign the invoice. In contrast, in #8238, path_pubkey was derived using information from the onion message, but the offer paths' node IDs could not be recovered, as the path_privkey information was lost after the offer was generated.

So in addition to generating offers without an issuer_id and signing related invoices using the proper key, this PR recovers the offer paths' node IDs, which will enable the generation of invoices with matching paths (addressing #8041) in a future PR.

In this PR, the first path private key for a given path is generated using
e_0 = HMAC256(\text{"first_path_privkey"}, SHA256(path_id || N_0 || path_index))

where path_id is the secret stored in the offer's encrypted_data_tlv and that is only known by the payee, and where N_0 and path_index are the first_node_id and the 64-bit index of the path, respectively.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

The changelog has been updated in the relevant commit(s) according to the guidelines.
Tests have been added or modified to reflect the changes.
Documentation has been reviewed and updated as needed.
Related issues have been listed and linked, including any that this PR closes.
Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade

offers: offers that include offer_paths now omit offer_issuer_id and sign with the blinded path alias' key by default. An optional force_issuer_id field is also added to the offer command so the offer_issuer_id is included even when not required to reach the issuer due to the existence of offer_paths.

…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

madelinevibes · 2026-06-15T05:43:00Z

@21M4TW would love to see the conflicts resolve so we can merge this

21M4TW requested a review from cdecker as a code owner January 19, 2026 15:38

Changelog-Changed: offer_paths' e_0 derived deterministically fro…
62435d8
…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

21M4TW force-pushed the bolt12_deterministic_path_key branch from 2e09992 to 62435d8Compare January 25, 2026 03:30

21M4TW mentioned this pull request Jan 25, 2026
Added: Support for non-final onion messages hops to self #8862
Open
5 tasks

madelinevibes added this to the v26.09 milestone Jun 15, 2026

daywalker90 added the needs-rebase label Aug 17, 2026

daywalker90 modified the milestones: v26.09, v26.12 Aug 17, 2026

21M4TW requested a review from cdecker as a code owner January 19, 2026 15:38

Changelog-Changed: offer_paths' e_0 derived deterministically fro…
62435d8
…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

21M4TW force-pushed the bolt12_deterministic_path_key branch from 2e09992 to 62435d8Compare January 25, 2026 03:30

21M4TW mentioned this pull request Jan 25, 2026
Added: Support for non-final onion messages hops to self #8862
Open
5 tasks

madelinevibes added this to the v26.09 milestone Jun 15, 2026

daywalker90 added the needs-rebase label Aug 17, 2026

daywalker90 modified the milestones: v26.09, v26.12 Aug 17, 2026

21M4TW requested a review from cdecker as a code owner January 19, 2026 15:38

Changelog-Changed: offer_paths' e_0 derived deterministically fro…
62435d8
…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

21M4TW force-pushed the bolt12_deterministic_path_key branch from 2e09992 to 62435d8Compare January 25, 2026 03:30

21M4TW mentioned this pull request Jan 25, 2026
Added: Support for non-final onion messages hops to self #8862
Open
5 tasks

madelinevibes added this to the v26.09 milestone Jun 15, 2026

daywalker90 added the needs-rebase label Aug 17, 2026

daywalker90 modified the milestones: v26.09, v26.12 Aug 17, 2026

21M4TW requested a review from cdecker as a code owner January 19, 2026 15:38

Changelog-Changed: offer_paths' e_0 derived deterministically fro…
62435d8
…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

21M4TW force-pushed the bolt12_deterministic_path_key branch from 2e09992 to 62435d8Compare January 25, 2026 03:30

21M4TW mentioned this pull request Jan 25, 2026
Added: Support for non-final onion messages hops to self #8862
Open
5 tasks

madelinevibes added this to the v26.09 milestone Jun 15, 2026

daywalker90 added the needs-rebase label Aug 17, 2026

daywalker90 modified the milestones: v26.09, v26.12 Aug 17, 2026

21M4TW requested a review from cdecker as a code owner January 19, 2026 15:38

Changelog-Changed: offer_paths' e_0 derived deterministically fro…
62435d8
…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

21M4TW force-pushed the bolt12_deterministic_path_key branch from 2e09992 to 62435d8Compare January 25, 2026 03:30

21M4TW mentioned this pull request Jan 25, 2026
Added: Support for non-final onion messages hops to self #8862
Open
5 tasks

madelinevibes added this to the v26.09 milestone Jun 15, 2026

daywalker90 added the needs-rebase label Aug 17, 2026

daywalker90 modified the milestones: v26.09, v26.12 Aug 17, 2026

21M4TW requested a review from cdecker as a code owner January 19, 2026 15:38

Changelog-Changed: offer_paths' e_0 derived deterministically fro…
62435d8
…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

21M4TW force-pushed the bolt12_deterministic_path_key branch from 2e09992 to 62435d8Compare January 25, 2026 03:30

21M4TW mentioned this pull request Jan 25, 2026
Added: Support for non-final onion messages hops to self #8862
Open
5 tasks

madelinevibes added this to the v26.09 milestone Jun 15, 2026

daywalker90 added the needs-rebase label Aug 17, 2026

daywalker90 modified the milestones: v26.09, v26.12 Aug 17, 2026

21M4TW requested a review from cdecker as a code owner January 19, 2026 15:38

Changelog-Changed: offer_paths' e_0 derived deterministically fro…
62435d8
…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

21M4TW force-pushed the bolt12_deterministic_path_key branch from 2e09992 to 62435d8Compare January 25, 2026 03:30

21M4TW mentioned this pull request Jan 25, 2026
Added: Support for non-final onion messages hops to self #8862
Open
5 tasks

madelinevibes added this to the v26.09 milestone Jun 15, 2026

daywalker90 added the needs-rebase label Aug 17, 2026

daywalker90 modified the milestones: v26.09, v26.12 Aug 17, 2026

21M4TW requested a review from cdecker as a code owner January 19, 2026 15:38

Changelog-Changed: offer_paths' e_0 derived deterministically fro…
62435d8
…m the offer's `path_id`, `N_0` and the path's index so the offer's paths can be recovered when an invoice is fetched. Offer paths' node IDs and the used path index stored in struct invreq.

21M4TW force-pushed the bolt12_deterministic_path_key branch from 2e09992 to 62435d8Compare January 25, 2026 03:30

21M4TW mentioned this pull request Jan 25, 2026
Added: Support for non-final onion messages hops to self #8862
Open
5 tasks

madelinevibes added this to the v26.09 milestone Jun 15, 2026

daywalker90 added the needs-rebase label Aug 17, 2026

daywalker90 modified the milestones: v26.09, v26.12 Aug 17, 2026

Uh oh!

Conversation

21M4TW commented Jan 19, 2026

Checklist

Uh oh!

madelinevibes commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

21M4TW commented Jan 19, 2026

Checklist

Uh oh!

madelinevibes commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

21M4TW commented Jan 19, 2026

Checklist

Uh oh!

madelinevibes commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

21M4TW commented Jan 19, 2026

Checklist

Uh oh!

madelinevibes commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

21M4TW commented Jan 19, 2026

Checklist

Uh oh!

madelinevibes commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

21M4TW commented Jan 19, 2026

Checklist

Uh oh!