invoice: Use PaymentHash in raw invoice types by jgmcalpine · Pull Request #4363 · lightningdevkit/rust-lightning

jgmcalpine · 2026-01-30T17:27:31Z

Note: This is a breaking change for InvoiceBuilder. Downstream consumers (like ldk-node) will need to update their builder calls to pass PaymentHash directly.

Refactors RawBolt11Invoice, RawDataPart, and TaggedField to use
lightning_types::payment::PaymentHash instead of bitcoin::hashes::sha256::Hash.
This improves type safety and aligns the raw invoice types with the high-level
Bolt11Invoice.

This is a follow-up to #4293 to complete the migration of invoice types to PaymentHash.

Specific changes:

TaggedField::PaymentHash now holds a PaymentHash.
InvoiceBuilder::payment_hash now accepts a PaymentHash directly.
Implemented Base32 traits for PaymentHash in lightning-invoice to support
serialization.
Updated tests to resolve name collisions between the PaymentHash type and
the TaggedField variant.
Updated downstream usage in the lightning crate (channelmanager and
invoice_utils) to remove redundant hash conversions now that the builder
accepts the strong type.

ldk-reviews-bot · 2026-01-30T17:27:34Z

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

TheBlueMatt · 2026-01-30T20:41:51Z

lightning/src/ln/channelmanager.rs

 		let _persistence_guard = PersistenceNotifierGuard::notify_on_drop(self);
-		let payment_hash = invoice.payment_hash();
+		let payment_hash =
+			PaymentHash(Sha256::from_byte_array(invoice.payment_hash().0).to_byte_array());


Huh? Same below.

Ah, good catch. That was a redundant round-trip left over from when I was refactoring the types. Simplified it to just use invoice.payment_hash() directly

codecov · 2026-01-30T20:45:57Z

Codecov Report

❌ Patch coverage is 99.35484% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 86.01%. Comparing base (f9ad345) to head (d652d86).
⚠️ Report is 49 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-invoice/src/de.rs	98.63%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4363      +/-   ##
==========================================
- Coverage   86.09%   86.01%   -0.09%     
==========================================
  Files         156      156              
  Lines      102804   102693     -111     
  Branches   102804   102693     -111     
==========================================
- Hits        88508    88327     -181     
- Misses      11788    11858      +70     
  Partials     2508     2508

Flag	Coverage Δ
tests	`86.01% <99.35%> (-0.09%)`	⬇️

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.

tnull

Note: This is a breaking change for InvoiceBuilder. Downstream consumers (like ldk-node) will need to update their builder calls to pass PaymentHash directly.

Please note that we employ a "if you break it, you keep it" rule here by now. ;)

I.e., please make sure to open a PR on the LDK Node end to clean up the breakage as soon as this lands.

TheBlueMatt · 2026-02-02T13:24:34Z

lightning/src/ln/channelmanager.rs

 					Err(()) => return None,
 				};

+				let payment_hash = invoice.payment_hash();


Unnecessary diff.

TheBlueMatt · 2026-02-02T13:24:49Z

lightning-liquidity/tests/lsps2_integration_tests.rs

 	let mut invoice_builder = InvoiceBuilder::new(currency)
 		.description(description.to_string())
-		.payment_hash(payment_hash)
+		.payment_hash(PaymentHash(payment_hash.to_byte_array()))


Here too we're building a sha256::Hash just to undo it.

TheBlueMatt · 2026-02-02T13:25:42Z

lightning/src/ln/invoice_utils.rs

 			Bolt11InvoiceDescriptionRef::Direct(&Description::new("test".to_string()).unwrap())
 		);
-		assert_eq!(invoice.payment_hash(), payment_hash);
+		assert_eq!(invoice.payment_hash().0, payment_hash.0);


Unnecessary diff.

Fixed in the latest push

jgmcalpine · 2026-02-02T13:55:38Z

Note: This is a breaking change for InvoiceBuilder. Downstream consumers (like ldk-node) will need to update their builder calls to pass PaymentHash directly.

Please note that we employ a "if you break it, you keep it" rule here by now. ;)

I.e., please make sure to open a PR on the LDK Node end to clean up the breakage as soon as this lands.

Understood! I'm happy to handle the LDK Node fix. I'll keep an eye on this and open the fix PR in ldk-node after this lands.

TheBlueMatt

thanks!

ldk-reviews-bot requested a review from valentinewallace January 30, 2026 17:38

jgmcalpine force-pushed the invoice-raw-use-payment-hash branch 5 times, most recently from da905d6 to f967d8a Compare January 30, 2026 18:56

TheBlueMatt reviewed Jan 30, 2026

View reviewed changes

TheBlueMatt removed the request for review from valentinewallace January 30, 2026 20:42

jgmcalpine force-pushed the invoice-raw-use-payment-hash branch 2 times, most recently from 6b9f7ec to 59b1623 Compare January 30, 2026 21:01

tnull reviewed Feb 2, 2026

View reviewed changes

TheBlueMatt reviewed Feb 2, 2026

View reviewed changes

invoice: Use PaymentHash in raw invoice types

d652d86

jgmcalpine force-pushed the invoice-raw-use-payment-hash branch from 59b1623 to d652d86 Compare February 2, 2026 17:19

TheBlueMatt approved these changes Feb 3, 2026

View reviewed changes

TheBlueMatt merged commit 817ab5e into lightningdevkit:main Feb 3, 2026
20 of 21 checks passed

jgmcalpine mentioned this pull request Feb 3, 2026

Update rust-lightning to fix InvoiceBuilder breakage lightningdevkit/ldk-node#783

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

invoice: Use PaymentHash in raw invoice types#4363

invoice: Use PaymentHash in raw invoice types#4363
TheBlueMatt merged 1 commit intolightningdevkit:mainfrom
jgmcalpine:invoice-raw-use-payment-hash

jgmcalpine commented Jan 30, 2026 •

edited

Loading

Uh oh!

ldk-reviews-bot commented Jan 30, 2026 •

edited

Loading

Uh oh!

TheBlueMatt Jan 30, 2026

Uh oh!

jgmcalpine Jan 30, 2026

Uh oh!

codecov bot commented Jan 30, 2026 •

edited

Loading

Uh oh!

tnull left a comment

Uh oh!

TheBlueMatt Feb 2, 2026

Uh oh!

TheBlueMatt Feb 2, 2026

Uh oh!

TheBlueMatt Feb 2, 2026

Uh oh!

jgmcalpine Feb 2, 2026

Uh oh!

jgmcalpine commented Feb 2, 2026

Uh oh!

TheBlueMatt left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

jgmcalpine commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheBlueMatt Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

jgmcalpine Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

jgmcalpine Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

jgmcalpine commented Feb 2, 2026

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jgmcalpine commented Jan 30, 2026 •

edited

Loading

ldk-reviews-bot commented Jan 30, 2026 •

edited

Loading

codecov bot commented Jan 30, 2026 •

edited

Loading