[v0.20.x-branch] Backport #11190: zpay32: reject duplicate payment hash fields - #11235
Merged
Merged
Conversation
Author
|
Please cherry-pick the changes locally and resolve any conflicts. git fetch origin backport-11190-to-v0.20.x-branch
git worktree add --checkout .worktree/backport-11190-to-v0.20.x-branch backport-11190-to-v0.20.x-branch
cd .worktree/backport-11190-to-v0.20.x-branch
git reset --hard HEAD^
git cherry-pick -x e2f2706367aa6e7a39f8ee14204b43087e27600f
git push --force-with-lease |
9 tasks
In this commit, we reject BOLT 11 invoices that contain more than one payment hash (`p`) field. `zpay32.Decode` previously kept the first supported payment hash and ignored later fields, so the interpreted payment hash depended on field order. The decoder now tracks whether a `p` field has appeared separately from whether its contents parsed successfully, and any later `p` field returns `ErrDuplicatePaymentHash`. This covers identical hashes, distinct hashes, and a malformed first field followed by a valid one. The change is deliberately stricter than the current BOLT 11 text, which tells a reader to use the first `p` field; it is motivated by lightning/bolts#1357, and will be backported to the v0.20.5 and v0.21.4 releases. We also replace the stale comment above parse32Bytes, which quoted the old BOLT 11 rule that a reader must skip over 32-byte fields with an unsupported length. The current reader requirements say the opposite: a reader must fail the payment if a fixed-length field (p, h, s, n) does not have the correct length. The new comment states that reporting the field as absent is a known divergence, and explains why the end result for the payment hash is the same either way. In the tests, we cover identical and distinct duplicate hashes, a malformed first field followed by a valid one, and the signed vectors. A valid variant of the flipped vector keeps the wrong-length h and n fields, so the coverage that such fields are skipped survives. The duplicate vector in the decode table pins ErrDuplicatePaymentHash through a new wantErr field rather than asserting any decode error. (cherry picked from commit e2f2706)
ziggie1984
force-pushed
the
backport-11190-to-v0.20.x-branch
branch
from
September 23, 2026 13:26
ac3ee08 to
5e7d3e1
Compare
ziggie1984
marked this pull request as ready for review
September 23, 2026 13:28
Author
🟡 PR Severity: MEDIUM
🟡 Medium (2 files)
🟢 Low (3 files)
AnalysisThis is a backport of #11190 (reject duplicate payment hashes) to the v0.20.x branch. The substantive change is confined to To override, add a |
This file contains hidden or 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
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.
Backport of #11190
Change Description
In this PR, we reject BOLT 11 invoices that contain more than one payment
hash (
p) field.zpay32.Decodepreviously kept the first supported paymenthash and ignored later fields, so the interpreted payment hash depended on
field order.
The decoder now tracks whether a
pfield has appeared separately from whetherits contents parsed successfully. Any later
pfield returnsErrDuplicatePaymentHash. This covers identical hashes, distinct hashes, and amalformed first field followed by a valid one.
This change is deliberately stricter than the current BOLT 11 text, which
tells a reader to use the first
pfield; it is motivated bylightning/bolts#1357.
Note: the same order dependence remains for the other single-occurrence fields
(
s,d,m,n,h,x,c,f,9), which all keep first-seen-winsbehavior. This PR is intentionally limited to the payment hash; the
s(payment address) field looks like the natural candidate for the same treatment
in a follow-up.
Steps to Test
go test ./zpay32 make lint-nativePull Request Checklist
Testing
Code Style and Documentation
[skip ci]in the commit message for small changes.