Accept LNURL-pay invoices without matching description_hash#2
Merged
martinsaposnic merged 1 commit intoMay 18, 2026
Merged
Conversation
Some real-world LNURL-pay servers (e.g. bringin.xyz) mint BOLT11 invoices with a plain `d` tag instead of the `h` tag = sha256(metadata) required by LUD-06. Upstream correctly rejects these. This fork accepts them to match the permissive behavior of wallets like Strike, so payouts from moneydevkit to addresses on these servers go through. Tradeoff: we lose the cryptographic binding between the LNURL metadata the payer saw and the invoice the wallet signs. A malicious or buggy LNURL host can swap the description after the fact. Acceptable here because the alternative is "payouts to popular non-compliant servers just fail".
2 tasks
This was referenced May 18, 2026
Open
martinsaposnic
added a commit
to moneydevkit/lightning-js
that referenced
this pull request
May 18, 2026
Point at the `2025-12-ldk-node-base` branch (rev bc7d03f) of our fork, which includes a patch to accept LNURL-pay BOLT11 invoices that ship a plain `d` description tag instead of the LUD-06-required `h = sha256(metadata)` tag. Unblocks payouts to Bringin lightning addresses (e.g. vincenzopalazzo@bringin.xyz) and any other LNURL servers with the same non-compliance. See moneydevkit/bitcoin-payment-instructions#2. Builds clean; verified live against vincenzopalazzo@bringin.xyz which previously failed with "BOLT 11 invoice resolved via LNURL must have a matching description hash" and now returns a valid invoice. Note: ldk-node still transitively pins rev 6796e87 of the same crate, so `cargo tree -d` shows two copies of bitcoin-payment-instructions until ldk-node is bumped in a follow-up.
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.
Summary
HTTPHrnResolver::resolve_lnurl_to_invoiceso BOLT11 invoices with a plaindtag (or a mismatchedhtag) are accepted instead of being rejected with"BOLT 11 invoice resolved via LNURL must have a matching description hash".bringin.xyz) which mint invoices withd = "Topup 22000 sats"and nohtag. Strike pays these fine; upstreambitcoin-payment-instructionsdoes not, so moneydevkit payouts to these addresses fail.Targets
2025-12-ldk-node-base(the branchmdkdandldk-nodepin via rev6796e87) instead ofmain, so a single rev bump in those consumers picks up the fix without dragging in the LDK version drift between this branch andmain.Tradeoff
LUD-06 requires the invoice's
htag to commit tosha256(metadata)so the payer's wallet can prove the invoice it signs matches the metadata it displayed. Dropping the check means a malicious or buggy LNURL host can swap the invoice description out from under the user. We accept this here to unblock payouts. Callers that want the spec-correct behavior should use upstream.Test plan
cargo build --features httpclean on this branchcargo buildclean onlightning-jswith itsbitcoin-payment-instructionsdep swapped to this branch (the only build error encountered was a pre-existing, unrelatedLSPS4ServiceEvent::SendWebhookfield mismatch in local ldk-node/rust-lightning working trees)vincenzopalazzo@bringin.xyzviaHTTPHrnResolver:description: Direct(...)is exactly the case upstream rejects; this fork passes through.Followups (not in this PR)
lightning-js,ldk-node, andmdkdto the new SHA so all three resolve to a single copy of this crate.mainby mistake.