Skip to content

[RFC] Add BOLT 12 payer proof primitives#4297

Open
vincenzopalazzo wants to merge 7 commits intolightningdevkit:mainfrom
vincenzopalazzo:macros/proof-of-payment-bolt12-spec
Open

[RFC] Add BOLT 12 payer proof primitives#4297
vincenzopalazzo wants to merge 7 commits intolightningdevkit:mainfrom
vincenzopalazzo:macros/proof-of-payment-bolt12-spec

Conversation

@vincenzopalazzo
Copy link
Contributor

This is a first draft implementation of the payer proof extension to BOLT 12 as proposed in lightning/bolts#1295. The goal is to get early feedback on the API design before the spec is finalized.

Payer proofs allow proving that a BOLT 12 invoice was paid by demonstrating possession of:

  • The payment preimage
  • A valid invoice signature over a merkle root
  • The payer's signature

This PR adds the core building blocks:

  • Extends merkle.rs with selective disclosure primitives that allow creating and reconstructing merkle trees with partial TLV disclosure. This enables proving invoice authenticity while omitting sensitive fields.
  • Adds payer_proof.rs with PayerProof, PayerProofBuilder, and UnsignedPayerProof types. The builder pattern allows callers to selectively include invoice fields (description, amount, etc.) in the proof.
  • Implements bech32 encoding/decoding with the lnp prefix and proper TLV stream parsing with validation (ascending order, no duplicates, hash length checks).

This is explicitly a PoC to validate the API surface - the spec itself is still being refined. Looking for feedback on:

  • Whether the builder pattern makes sense for selective disclosure
  • The verification API
  • Integration points with the rest of the offers module

cc @TheBlueMatt @jkczyz

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jan 5, 2026

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@codecov
Copy link

codecov bot commented Jan 5, 2026

Codecov Report

❌ Patch coverage is 92.67606% with 78 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.24%. Comparing base (e39437d) to head (3378fa3).
⚠️ Report is 170 commits behind head on main.

Files with missing lines Patch % Lines
lightning/src/offers/payer_proof.rs 89.26% 34 Missing and 32 partials ⚠️
lightning/src/offers/merkle.rs 97.52% 8 Missing and 1 partial ⚠️
lightning/src/offers/invoice.rs 96.00% 2 Missing ⚠️
lightning/src/offers/signer.rs 97.29% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4297      +/-   ##
==========================================
+ Coverage   85.88%   86.24%   +0.36%     
==========================================
  Files         159      161       +2     
  Lines      104448   108586    +4138     
  Branches   104448   108586    +4138     
==========================================
+ Hits        89706    93655    +3949     
- Misses      12235    12272      +37     
- Partials     2507     2659     +152     
Flag Coverage Δ
tests 86.24% <92.67%> (+0.36%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few notes, though I didn't dig into the code at a particularly low level.

@vincenzopalazzo vincenzopalazzo marked this pull request as ready for review January 20, 2026 17:00
@vincenzopalazzo vincenzopalazzo force-pushed the macros/proof-of-payment-bolt12-spec branch 2 times, most recently from 2324361 to 9f84e19 Compare January 20, 2026 17:42
vincenzopalazzo added a commit to vincenzopalazzo/payer-proof-test-vectors that referenced this pull request Jan 20, 2026
Add a Rust CLI tool that generates and verifies test vectors for BOLT 12
payer proofs as specified in lightning/bolts#1295. The tool uses the
rust-lightning implementation from lightningdevkit/rust-lightning#4297.

Features:
- Generate deterministic test vectors with configurable seed
- Verify test vectors from JSON files
- Support for basic proofs, proofs with notes, and invalid test cases
- Uses refund flow for explicit payer key control

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some API comments. I'll review the actual code somewhat later (are we locked on on the spec or is it still in flux at all?), but would be nice to reduce allocations in it first anyway.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@valentinewallace valentinewallace removed their request for review January 26, 2026 17:25
@jkczyz jkczyz self-requested a review January 27, 2026 18:59
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 4th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 5th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 6th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 7th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 8th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 9th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@TheBlueMatt TheBlueMatt added this to the 0.3 milestone Feb 18, 2026
@vincenzopalazzo vincenzopalazzo force-pushed the macros/proof-of-payment-bolt12-spec branch 5 times, most recently from fb8c68c to 9ad5c35 Compare February 24, 2026 18:13
Comment on lines +383 to +411
/// Compute omitted markers per BOLT 12 payer proof spec.
fn compute_omitted_markers(tlv_data: &[TlvMerkleData]) -> Vec<u64> {
let mut markers = Vec::new();
let mut prev_included_type: Option<u64> = None;
let mut prev_marker: Option<u64> = None;

for data in tlv_data {
if data.tlv_type == 0 {
continue;
}

if !data.is_included {
let marker = if let Some(prev_type) = prev_included_type {
prev_type + 1
} else if let Some(last_marker) = prev_marker {
last_marker + 1
} else {
1
};

markers.push(marker);
prev_marker = Some(marker);
prev_included_type = None;
} else {
prev_included_type = Some(data.tlv_type);
prev_marker = None;
}
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Subtle invariant: compute_omitted_markers unconditionally skips TLV type 0 at line 390, assuming it's always the first record (payer_metadata). But the function operates on a &[TlvMerkleData] with no assertion that the first entry IS type 0. If this function were ever called with a TLV stream whose first record is NOT type 0 (e.g., a different invoice format), the implicit TLV0 assumption would produce incorrect markers.

Consider either:

  • Adding debug_assert!(tlv_data.first().map(|d| d.tlv_type) == Some(0)) at the top, or
  • Documenting the precondition that the first TLV must be type 0

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct by design — per spec, type 0 (invreq_metadata) is always omitted and implicit (never included in markers). The function receives the full TlvMerkleData vec which always starts with TLV 0 from the invoice bytes. The if data.tlv_type == 0 { continue } just skips the implicit omission. If called with pre-filtered data that excludes type 0, the skip is a no-op — the algorithm still works correctly.

fixup! Add BOLT 12 payer proof implementation

Guard include_type against signature-range TLV types (240-1000)

Per spec, the payer proof signature (type 240), preimage (242),
omitted_tlvs (244), missing_hashes (246), leaf_hashes (248), and
payer_signature (250) are all handled separately by the payer proof
format. Before this fix, include_type(240) would insert 240 into
included_types, causing serialize_payer_proof to emit the invoice's
signature record as an included invoice TLV *and* then emit it again
as the payer proof's own TLV_SIGNATURE field — producing a malformed
TLV stream with duplicate type 240.

Fix:
- include_type now rejects SIGNATURE_TYPES (240..=1000) with a new
  SignatureTypeNotAllowed error variant
- serialize_payer_proof defensively filters SIGNATURE_TYPES from the
  invoice bytes iteration as a belt-and-suspenders guard

Tests added:
- test_include_type_rejects_signature_types: validates boundary
  conditions (240, 250, 1000 rejected; 239, 1001 allowed)
- test_parsing_rejects_unknown_even_signature_range_types: ensures
  the parser rejects unknown even types in the signature range

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Comment on lines +306 to +322
fn compute_payer_signature_message(note: Option<&str>, merkle_root: &sha256::Hash) -> Message {
let mut inner_hasher = sha256::Hash::engine();
if let Some(n) = note {
inner_hasher.input(n.as_bytes());
}
inner_hasher.input(merkle_root.as_ref());
let inner_msg = sha256::Hash::from_engine(inner_hasher);

let tag_hash = sha256::Hash::hash(PAYER_SIGNATURE_TAG.as_bytes());

let mut final_hasher = sha256::Hash::engine();
final_hasher.input(tag_hash.as_ref());
final_hasher.input(tag_hash.as_ref());
final_hasher.input(inner_msg.as_ref());
let final_digest = sha256::Hash::from_engine(final_hasher);

Message::from_digest(*final_digest.as_byte_array())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The payer signature message uses a non-standard double-hash construction: H(tag || tag || H(note || merkle_root)). Standard BOLT 12 signature computation (as in TaggedHash::from_merkle_root) is a single tagged hash: H(tag || tag || merkle_root).

If the spec defines the payer signature differently from the standard BOLT 12 tagged hash, this should be documented with a reference to the spec section. If the spec uses the standard construction, this needs to be fixed — the inner hash would make this incompatible with other implementations.

Also, when note is None, this computes H(merkle_root) as the inner message. When note is Some("") (empty string), it also computes H(merkle_root) since empty input contributes nothing to the hasher. These two cases are indistinguishable, meaning a verifier cannot distinguish "no note" from "empty note".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added spec reference comment. The construction follows the spec: payer_signature.sig signs msg = SHA256(note || merkle_root) using the standard BOLT 12 tagged hash.

Comment on lines +1102 to +1114
// We should have 4 missing hashes for omitted types:
// - type 0 (single leaf)
// - types 20+30 (combined branch, min_type=20)
// - type 50 (single leaf)
// - type 60 (single leaf)
//
// The spec example only shows 3, but that appears to be incomplete
// (missing hash for type 60). Our implementation should produce 4.
assert_eq!(
disclosure.missing_hashes.len(),
4,
"Expected 4 missing hashes for omitted types [0, 20+30, 50, 60]"
);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test explicitly disagrees with the spec ("The spec example only shows 3, but that appears to be incomplete"). If the implementation produces 4 missing hashes but the spec says 3, one of them is wrong. This needs to be resolved against the spec before merging — either the spec is right and the tree construction has a bug (perhaps types 50 and 60 should be merged into a single missing hash at a higher level), or the spec example is indeed incomplete and should be updated.

Shipping code that knowingly diverges from the spec without a clear resolution risks incompatibility with other implementations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Known open question. The spec example omits TLV 60's hash — our 4 is correct per the tree structure. Will follow up with spec authors on BOLT PR 1295.

fixup! Add BOLT 12 payer proof implementation

Fix two issues found during spec cross-check review:

1. invoice_features inclusion: check TLV presence, not parsed value

   Per spec, invoice_features MUST be included "if present" — meaning
   if the TLV exists in the invoice byte stream. The previous check
   compared the parsed Bolt12InvoiceFeatures against empty(), which
   misses the case where another implementation serializes empty features
   (the TLV is present but the value has no bits set). Now scans the raw
   invoice bytes for INVOICE_FEATURES_TYPE.

2. Secp256k1::new() → Secp256k1::signing_only() in build_with_derived_key

   Secp256k1::new() allocates a full signing+verification context (~1MB).
   Since derive_payer_signing_keys and sign_schnorr_no_aux_rand only
   require a Signing context, use signing_only() instead. The
   verification step in sign() already creates its own verification_only
   context.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Comment on lines +366 to +370

let is_included = included_types.contains(&record.r#type);
if is_included {
leaf_hashes.push(nonce_hash);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming confusion: leaf_hashes stores nonce hashes (nonce_hash), not leaf hashes. In the BOLT 12 merkle tree, the "leaf hash" is H("LnLeaf" || record_bytes) while the "nonce hash" is H(nonce_tag || type_bytes) — these are distinct values. Storing nonce hashes under the name leaf_hashes here, in the SelectiveDisclosure struct, and in the TLV encoding (type 248 = TLV_LEAF_HASHES) is confusing.

If the spec calls these "leaf hashes," a code comment clarifying the distinction would help readers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a clarifying comment noting that these are nonce hashes, named leaf_hashes to match the spec's TLV type 248.

Comment on lines +515 to +519
included_records.push((
tlv_type,
record.end - record.record_bytes.len(),
record.end,
));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be cleaner if included_records stored TlvRecords instead and have reconstruct_merkle_root take them, too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partially addressed in 3378fa3 — added value_bytes to TlvRecord and read_value() method. The included_records still stores (u64, usize, usize) offsets rather than TlvRecords because TlvRecord borrows from the byte slice and can't outlive the iterator loop. Storing offsets and indexing bytes[start..end] after the loop is the borrow-checker-friendly approach.

Comment on lines +509 to +521
match tlv_type {
INVOICE_REQUEST_PAYER_ID_TYPE => {
let mut record_cursor = io::Cursor::new(record.record_bytes);
let _type: BigSize = Readable::read(&mut record_cursor)?;
let _len: BigSize = Readable::read(&mut record_cursor)?;
payer_id = Some(Readable::read(&mut record_cursor)?);
included_types.insert(tlv_type);
included_records.push((
tlv_type,
record.end - record.record_bytes.len(),
record.end,
));
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add as a method to TlvRecord? We've already read the bytes, so re-reading the bytes is redundant. We can always store a value_bytes field in TlvRecord to avoid re-parsing.

Copy link
Contributor

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With inspiration from my last round of comments, I asked Claude if there are any more opportunities to simplify the code.

Comment on lines +384 to +387
fn compute_omitted_markers(tlv_data: &[TlvMerkleData]) -> Vec<u64> {
let mut markers = Vec::new();
let mut prev_included_type: Option<u64> = None;
let mut prev_marker: Option<u64> = None;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Straight from Claude:

prev_included_type and prev_marker are mutually exclusive. The marker is always prev_value + 1 where prev_value tracks the last included type or last marker. The whole function reduces to:

  fn compute_omitted_markers(tlv_data: &[TlvMerkleData]) -> Vec<u64> {
      let mut markers = Vec::new();
      let mut prev_value: u64 = 0;
      for data in tlv_data {
          if data.tlv_type == 0 { continue; }
          if !data.is_included {
              let marker = prev_value + 1;
              markers.push(marker);
              prev_value = marker;
          } else {
              prev_value = data.tlv_type;
          }
      }
      markers
  }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 3378fa3. Simplified to single prev_value tracking variable.

Comment on lines +465 to +497
match (left_hash, right_hash, left_incl, right_incl) {
(Some(l), Some(r), true, false) => {
missing_with_types.push((right_min_type, r));
nodes[left_pos].hash =
Some(tagged_branch_hash_from_engine(branch_tag.clone(), l, r));
nodes[left_pos].included = true;
nodes[left_pos].min_type =
core::cmp::min(nodes[left_pos].min_type, right_min_type);
},
(Some(l), Some(r), false, true) => {
missing_with_types.push((nodes[left_pos].min_type, l));
let left_min = nodes[left_pos].min_type;
nodes[left_pos].hash =
Some(tagged_branch_hash_from_engine(branch_tag.clone(), l, r));
nodes[left_pos].included = true;
nodes[left_pos].min_type = core::cmp::min(left_min, right_min_type);
},
(Some(l), Some(r), true, true) => {
nodes[left_pos].hash =
Some(tagged_branch_hash_from_engine(branch_tag.clone(), l, r));
nodes[left_pos].included = true;
nodes[left_pos].min_type =
core::cmp::min(nodes[left_pos].min_type, right_min_type);
},
(Some(l), Some(r), false, false) => {
nodes[left_pos].hash =
Some(tagged_branch_hash_from_engine(branch_tag.clone(), l, r));
nodes[left_pos].min_type =
core::cmp::min(nodes[left_pos].min_type, right_min_type);
},
(Some(_), None, _, _) => {},
_ => unreachable!("Invalid state in merkle tree construction"),
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also from Claude:

All four (Some(l), Some(r), ...) arms compute the branch hash and update min_type. The only differences: whether to push to missing_with_types and whether to set included = true. Could be restructured as:

let combined = tagged_branch_hash_from_engine(branch_tag.clone(), l, r);
if left_incl != right_incl {
    let (missing_type, missing_hash) = if right_incl {
        (nodes[left_pos].min_type, l)
    } else {
        (right_min_type, r)
    };
    missing_with_types.push((missing_type, missing_hash));
    nodes[left_pos].included = true;
} else {
    nodes[left_pos].included |= left_incl;
}
nodes[left_pos].hash = Some(combined);
nodes[left_pos].min_type = core::cmp::min(nodes[left_pos].min_type,
right_min_type);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 3378fa3. Collapsed into a single (Some(l), Some(r)) arm with conditional missing_hash push and included |= left_incl || right_incl.

Comment on lines +348 to +389
BigSize(TLV_PREIMAGE).write(&mut bytes).expect("Vec write should not fail");
BigSize(32).write(&mut bytes).expect("Vec write should not fail");
bytes.extend_from_slice(&self.preimage.0);

if !self.disclosure.omitted_markers.is_empty() {
let omitted_len: u64 = self
.disclosure
.omitted_markers
.iter()
.map(|m| BigSize(*m).serialized_length() as u64)
.sum();
BigSize(TLV_OMITTED_TLVS).write(&mut bytes).expect("Vec write should not fail");
BigSize(omitted_len).write(&mut bytes).expect("Vec write should not fail");
for marker in &self.disclosure.omitted_markers {
BigSize(*marker).write(&mut bytes).expect("Vec write should not fail");
}
}

if !self.disclosure.missing_hashes.is_empty() {
let len = self.disclosure.missing_hashes.len() * 32;
BigSize(TLV_MISSING_HASHES).write(&mut bytes).expect("Vec write should not fail");
BigSize(len as u64).write(&mut bytes).expect("Vec write should not fail");
for hash in &self.disclosure.missing_hashes {
bytes.extend_from_slice(hash.as_ref());
}
}

if !self.disclosure.leaf_hashes.is_empty() {
let len = self.disclosure.leaf_hashes.len() * 32;
BigSize(TLV_LEAF_HASHES).write(&mut bytes).expect("Vec write should not fail");
BigSize(len as u64).write(&mut bytes).expect("Vec write should not fail");
for hash in &self.disclosure.leaf_hashes {
bytes.extend_from_slice(hash.as_ref());
}
}

let note_bytes = note.map(|n| n.as_bytes()).unwrap_or(&[]);
let payer_sig_len = 64 + note_bytes.len();
BigSize(TLV_PAYER_SIGNATURE).write(&mut bytes).expect("Vec write should not fail");
BigSize(payer_sig_len as u64).write(&mut bytes).expect("Vec write should not fail");
payer_signature.write(&mut bytes).expect("Vec write should not fail");
bytes.extend_from_slice(note_bytes);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly here with Writeable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed as part of the TlvRecord changes. Serialization already uses Writeable for BigSize and Signature. Hash lists use extend_from_slice since sha256::Hash doesn't impl Writeable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partially addressed in 3378fa3 — the serialization still uses manual BigSize().write() + extend_from_slice() for the payer proof TLVs since they have non-standard formats (concatenated hashes, BigSize lists). The included invoice records use TlvRecord::write() via the existing Writeable impl.

Comment on lines +592 to +593
payer_signature = Some(Readable::read(&mut record_cursor)?);
let note_len = len.0.saturating_sub(64);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might make sense to make a composite type for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deferred — creating a composite type requires implementing Readable/Writeable for sha256::Hash which isn't available. The current approach of iterating value_bytes with manual reads is practical for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll defer this for a follow-up. The hash list encoding (concatenated 32-byte hashes without individual length prefixes) doesn't match standard Readable/Writeable for Vec<sha256::Hash>, so a custom wrapper would be needed. Happy to add it if you feel strongly.

/// - marker=42, prev=41: 42 == 42, continuation → omitted, prev=42
/// Result: [O, I, O, O, I, O, O]
#[cfg(test)]
fn reconstruct_positions(included_types: &[u64], omitted_markers: &[u64]) -> Vec<bool> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this duplicates much of reconstruct_merkle_root. What be great if we can re-use that somehow without introducing new Vec allocations in non-test code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test helper and reconstruct_merkle_root serve different purposes — one builds Vec<bool> positions, the other TreeNodes with hashes. Sharing the interleaving logic without Vec allocations in non-test code would need a callback pattern that adds more complexity than it removes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this more carefully, reconstruct_positions (test-only) and reconstruct_merkle_root share the interleaving logic but diverge significantly: one builds a Vec<bool>, the other builds TreeNodes with hashes. Extracting the shared part would require a callback/closure pattern that's arguably harder to follow. Since reconstruct_positions is #[cfg(test)] only, I'd lean towards keeping them separate for clarity. Happy to revisit if you disagree.

Comment on lines +795 to +807

// Count markers larger than largest included
if marker > max_included {
trailing_count += 1;
}

prev = marker;
}

// MUST NOT contain more than one number larger than largest included
if trailing_count > 1 {
return Err(PayerProofError::TooManyTrailingOmittedMarkers);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Producer-consumer mismatch on trailing_count. The compute_omitted_markers function (merkle.rs:384) produces one marker per omitted TLV after the last included type, with no limit. But this validation rejects proofs with trailing_count > 1.

This means build_unsigned can produce proofs that TryFrom<Vec<u8>> rejects. Concrete scenario:

If a BOLT 12 invoice has unknown/future invoice TLV types above 176 (the highest required included type INVOICE_NODE_ID_TYPE), those types are present in bytes_without_sig (since SIGNATURE_TYPES only filters 240..=1000) and will be omitted by default. Each generates a trailing marker > 176.

Example: Invoice has TLV types [0, 88, 168, 176, 178, 180] (types 178/180 are unknown future invoice types in the valid 160..240 range). Required included types: {88, 168, 176}, so max_included = 176. Markers for omitted types 178 and 180 would be [177, 178] — both > 176, so trailing_count = 2 → rejected.

This also applies to invoices with experimental invoice types (3_000_000_000+), which are not filtered by SIGNATURE_TYPES.

The trailing_count check and compute_omitted_markers need to agree — either the producer should cap trailing markers (merging multiple trailing omitted TLVs into a single marker), or the consumer should accept multiple trailing markers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Investigating — there's a conflict between spec text ('more than one number larger than...') and the spec example which has [41, 42] both > 40. Will follow up on BOLT PR 1295.

Comment on lines +245 to +254
fn build_unsigned(self) -> Result<UnsignedPayerProof, PayerProofError> {
let mut invoice_bytes = Vec::new();
self.invoice.write(&mut invoice_bytes).expect("Vec write should not fail");
let mut bytes_without_sig = Vec::with_capacity(invoice_bytes.len());
for r in TlvStream::new(&invoice_bytes).filter(|r| !SIGNATURE_TYPES.contains(&r.r#type)) {
bytes_without_sig.extend_from_slice(r.record_bytes);
}

let disclosure =
merkle::compute_selective_disclosure(&bytes_without_sig, &self.included_types)?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: bytes_without_sig includes ALL non-signature TLVs from the invoice, including experimental invoice types (3_000_000_000+) and any unknown types in ranges 1001-999_999_999. These get processed by compute_selective_disclosure and will be omitted by default (since they're not in included_types). This interacts with the trailing_count > 1 validation bug noted on validate_omitted_markers_for_parsing — invoices with experimental types will produce unparseable proofs.

Consider documenting that the TLV stream fed to compute_selective_disclosure should match the set of TLVs that contribute to the invoice's merkle root, and ensuring the producer and consumer agree on the handling of trailing omitted types.

Comment on lines +529 to +535

// Build TreeNode vec directly by interleaving included/omitted positions,
// eliminating the intermediate Vec<bool> from reconstruct_positions_from_records.
let num_nodes = 1 + included_records.len() + omitted_markers.len();
let mut nodes: Vec<TreeNode> = Vec::with_capacity(num_nodes);

// TLV0 is always omitted
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implicit TLV0 node prepended here assumes the original TLV stream starts with type 0 (payer_metadata). This is true for BOLT 12 invoices, but the function's API doesn't enforce or document this invariant.

If compute_selective_disclosure is called on a TLV stream that doesn't contain type 0 (as in the unit test test_selective_disclosure_computation with types [1, 2]), the producer creates a 2-node tree but this reconstruction creates a 3-node tree (with the extra TLV0 node), causing InsufficientMissingHashes because the needs_hash count won't match missing_hashes.

Consider either:

  1. Adding a debug_assert! that omitted_markers and included_records are consistent with the TLV0 assumption, or
  2. Documenting on both compute_selective_disclosure and reconstruct_merkle_root that the TLV stream MUST start with type 0.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above — TLV0 is always prepended in payer proof context. The function is private (pub(super)) and only called from TryFrom<Vec<u8>> which always has TLV0. Adding a doc comment noting the invariant.

Comment on lines +780 to +792
for inc_type in inc_iter.by_ref() {
if inc_type + 1 == marker {
found = true;
break;
}
if inc_type >= marker {
return Err(PayerProofError::InvalidData("omitted_markers not minimized"));
}
}
if !found {
return Err(PayerProofError::InvalidData("omitted_markers not minimized"));
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential issue: inc_type + 1 on line 781 can overflow if inc_type == u64::MAX. While include_type() rejects types >= 240, the parser's catch-all _ arm accepts any type < 240 as included — but an adversary who crafts a TLV with type 239 would have inc_type + 1 = 240, which is fine. However, this function is also called with included_types populated from parsed data. On 32-bit platforms or with unusual inputs, inc_type could theoretically be very large. Using inc_type.checked_add(1) would be defensive.

Similarly, expected_next = marker + 1 on line 794 would overflow if marker == u64::MAX. A subsequent marker != expected_next comparison against expected_next = 0 would always succeed (since markers must be > 0), causing the code to search for a matching included type rather than treating it as a continuation. While the ascending order check prevents marker == u64::MAX from being followed by another marker, the overflow is still unsound.

Comment on lines +162 to +170
let mut invoice_bytes = Vec::new();
invoice.write(&mut invoice_bytes).expect("Vec write should not fail");
let has_features_tlv =
TlvStream::new(&invoice_bytes).any(|r| r.r#type == INVOICE_FEATURES_TYPE);
if has_features_tlv {
included_types.insert(INVOICE_FEATURES_TYPE);
}

Ok(Self { invoice, preimage, included_types })
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The invoice is serialized here to check for the features TLV, and then serialized again in build_unsigned() (line 246-247). Since Bolt12Invoice::write just copies self.bytes, the result is deterministic and the double serialization is functionally correct — but it's an unnecessary allocation. Consider storing the serialized bytes in the builder or deferring the features check.

More importantly: this check uses TlvStream::new(&invoice_bytes) which iterates ALL TLVs. But INVOICE_FEATURES_TYPE (174) is in the invoice range — the any() call will short-circuit after finding it, but it still scans through all preceding TLVs (offer, invreq, etc.). A TlvStream::new(&invoice_bytes).range(INVOICE_TYPES) would be more targeted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noted — the double serialization is functionally correct since Bolt12Invoice::write just copies self.bytes. Deferring optimization.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 3378fa3 — same change, serialize once in new().

Fix five parsing safety issues found during review:

1. TlvStream panic on malformed input (CRITICAL): TlvStream::new() assumes
   well-formed input and panics on malformed BigSize or out-of-bounds lengths.
   Added validate_tlv_framing() pre-check before TlvStream::new() in
   TryFrom<Vec<u8>>, mirroring the validation ParsedMessage/CursorReadable
   provides for other BOLT 12 types.

2. include_type() allowed types > 1000: SIGNATURE_TYPES is 240..=1000, so
   experimental types > 1000 slipped through. Changed guard to reject all
   types >= 240 (TLV_SIGNATURE) since the entire range is reserved for
   signature/payer-proof TLVs.

3. Duplicate type-0 not detected: prev_tlv_type was initialized to 0 with
   a `!= 0` guard, so `if tlv_type <= prev_tlv_type && prev_tlv_type != 0`
   passed for two consecutive type-0 records. Changed to Option<u64>.

4. note_len truncation on 32-bit: `note_len as usize` truncates on 32-bit
   platforms. Changed to usize::try_from() with proper error.

5. Missing len < 64 check for payer_signature: saturating_sub(64) silently
   produced 0 for short values, masking malformed input. Added explicit
   check returning InvalidValue.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@vincenzopalazzo vincenzopalazzo force-pushed the macros/proof-of-payment-bolt12-spec branch from 712d3fc to 64c7f9c Compare March 21, 2026 19:52
Address jkczyz review feedback:

- Add `value_bytes` field and `read_value()` method to `TlvRecord`,
  eliminating the `read_tlv_value` helper. TLV parsing in TryFrom now
  uses `record.read_value()` for known types and `record.value_bytes`
  for hash lists and omitted markers, avoiding redundant type+length
  re-parsing. (Threads 2, 5, 19, 22, 49)

- Simplify `compute_omitted_markers` from dual tracking variables
  (`prev_included_type` / `prev_marker`) to a single `prev_value`,
  since they are mutually exclusive. (Thread 20, 47)

- Simplify `build_tree_with_disclosure` match: all four `(Some, Some)`
  arms shared the same branch hash + min_type update. Collapsed into
  a single arm with conditional missing_hash push. (Thread 21, 48)

- Use `PrintableString` for `payer_note()` accessor return type,
  matching the pattern used by other BOLT 12 types. (Thread 25, 52)

- Change `validate_omitted_markers_for_parsing` to return `DecodeError`
  directly instead of `PayerProofError`, since the only caller maps
  to `Bolt12ParseError::Decode` anyway. Removed unused error variants
  `InvalidData`, `MissingRequiredField`, `OmittedMarkersContainIncluded`,
  `TooManyTrailingOmittedMarkers`. (Thread 18, 45)

- Avoid double serialization of invoice bytes: serialize once in
  `PayerProofBuilder::new()` and store in the builder, reusing in
  `build_unsigned()`. (Thread 16, 31, 42, 58)

- Remove unused `crate::io::Read` import.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

// MUST NOT contain signature TLV types
if SIGNATURE_TYPES.contains(&marker) {
return Err(crate::ln::msgs::DecodeError::InvalidValue);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit (performance): The parser allocates two Secp256k1::verification_only() contexts (~0.6 MB each): one inside merkle::verify_signature (line 706) and another here. Consider passing a single context to both verification calls — e.g., by inlining the verify_signature logic or accepting a context parameter:

let secp_ctx = Secp256k1::verification_only();

// Verify invoice signature
let tagged_hash = TaggedHash::from_merkle_root(SIGNATURE_TAG, merkle_root);
let issuer_xonly: XOnlyPublicKey = issuer_signing_pubkey.into();
secp_ctx.verify_schnorr(&invoice_signature, tagged_hash.as_digest(), &issuer_xonly)
    .map_err(|_| Bolt12ParseError::Decode(DecodeError::InvalidValue))?;

// Verify payer signature  
let message = UnsignedPayerProof::compute_payer_signature_message(...);
secp_ctx.verify_schnorr(&payer_signature, &message, &payer_id.into())
    .map_err(|_| Bolt12ParseError::Decode(DecodeError::InvalidValue))?;

This halves the heap allocation for signature verification during parsing.

let mut payment_hash: Option<PaymentHash> = None;
let mut issuer_signing_pubkey: Option<PublicKey> = None;
let mut invoice_signature: Option<Signature> = None;
let mut preimage: Option<PaymentPreimage> = None;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Empty bytes input passes validate_tlv_framing (the while loop body is never entered), then TlvStream::new(&bytes) produces an empty iterator. The for record in TlvStream::new(&bytes) loop doesn't execute, so all required fields (payer_id, payment_hash, etc.) remain None. The subsequent .ok_or(...) checks correctly return errors.

However, this is a minor robustness concern — consider adding an explicit early return for empty input before the TlvStream iteration to provide a clearer error:

if bytes.is_empty() {
    return Err(Bolt12ParseError::Decode(DecodeError::InvalidValue));
}

This avoids running the rest of the parser and producing potentially confusing error messages (e.g., MissingPayerSigningPubkey instead of a more descriptive "empty proof").

hash: Some(data.per_tlv_hash),
included: data.is_included,
min_type: data.tlv_type,
})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential overflow: 2 << level will overflow usize when level >= usize::BITS - 1 (63 on 64-bit, 31 on 32-bit). While this can't happen in practice (would require ~2^31 TLV records on 32-bit, impossible to allocate), the same pattern appears in four places:

  • build_tree_with_disclosure (here)
  • reconstruct_merkle_root first pass (line 587)
  • reconstruct_merkle_root second pass (line 634)
  • root_hash (existing code, line 179)

Consider using 1usize.checked_shl(level + 1) and breaking on None, or simply adding if level >= usize::BITS as u32 - 1 { break; } as a safety guard. This would make the code robust against pathological inputs regardless of platform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

5 participants