You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, LND only requires the payment secret (s field) for BOLT11 invoice writers but not for readers. This creates an inconsistency with the updated Lightning Network specifications where the payment secret is now mandatory for both writing and reading.
Describe the solution you'd like
Update LND to make the payment secret (s field) mandatory when reading/processing BOLT11 invoices. Specifically:
Modify the invoice validation logic to reject invoices that lack a payment secret field
Remove any code that allows skipping s fields with incorrect length
Update relevant tests to ensure invoices without payment secrets are properly rejected
Update LND's feature bit handling to treat payment_secret as ASSUMED (per BOLT 9 changes)
Additional context
This change aligns with recent updates to the BOLT11 specifications where the payment secret field (s) is now mandatory for both writers and readers. The change is motivated by privacy improvements - payment secrets prevent intermediate nodes from probing for the destination by generating their own payment onions.
Other implementations like LDK have already implemented this requirement by refusing to pay invoices missing a payment secret. Since it has been approximately 4 years since the writer-side requirement was introduced, and all modern implementations now include payment secrets in their invoices, this change represents the formalization of existing best practices.
The BOLT 9 specification has also been updated to change the payment_secret feature to ASSUMED status, reflecting that this is now considered a core part of the Lightning Network protocol rather than an optional feature.
Hello @saubyk, I’ve been talking to @erickcestari about the specs update he made a few days ago (already merged).
He’s ready to take over the issue also.
Is your feature request related to a problem? Please describe.
Currently, LND only requires the payment secret (
s
field) for BOLT11 invoice writers but not for readers. This creates an inconsistency with the updated Lightning Network specifications where the payment secret is now mandatory for both writing and reading.Describe the solution you'd like
Update LND to make the payment secret (
s
field) mandatory when reading/processing BOLT11 invoices. Specifically:s
fields with incorrect lengthpayment_secret
as ASSUMED (per BOLT 9 changes)Additional context
This change aligns with recent updates to the BOLT11 specifications where the payment secret field (
s
) is now mandatory for both writers and readers. The change is motivated by privacy improvements - payment secrets prevent intermediate nodes from probing for the destination by generating their own payment onions.Other implementations like LDK have already implemented this requirement by refusing to pay invoices missing a payment secret. Since it has been approximately 4 years since the writer-side requirement was introduced, and all modern implementations now include payment secrets in their invoices, this change represents the formalization of existing best practices.
The BOLT 9 specification has also been updated to change the payment_secret feature to ASSUMED status, reflecting that this is now considered a core part of the Lightning Network protocol rather than an optional feature.
Related changes in the BOLT specifications (lightning/bolts#1242):
s
field is missings
fieldpayment_secret
feature to ASSUMED in BOLT 9The text was updated successfully, but these errors were encountered: