LUD-25 draft: wiring LUD-21 verify onto minting invoices leaks the bearer note

[felixfelix-bot]

Title: LUD-25 draft: wiring LUD-21 verify onto minting invoices leaks the bearer note

Spec: 25.md (LNURLcash), MINTING a bearer note from a payRequest + Offline/verify sections.

The problem

Under LUD-25, the payment preimage P of a minting invoice IS the bearer note (k1 = P). The draft suggests a SERVICE MAY attach a LUD-21 verify endpoint to melts — and a natural implementation move is to expose verify for the minting invoice too (so the payer can watch it settle before pasting the preimage into the wallet).

That combination is an account-takeover primitive:

1. Mallory obtains the minting invoice pr (payment hash is not secret — it is handed to whoever pays, shown on invoice QRs, visible in forwarding nodes' logs).
2. Mallory polls GET verify?pr=....
3. Once the payment settles, LUD-21 requires the response to include preimage — which here equals k1, the bearer secret.
4. Mallory now holds a valid note and rotates it before the legitimate holder ever does. The legitimate holder's preimage copy is worthless — the note was already burned in the rotate.

Standard LUD-21 semantics are safe for payRequest because the preimage of an outgoing payment proves payment, it is not itself the asset. LUD-25 inverts that: for minting invoices, the preimage is the asset.

Suggested spec text

A SERVICE implementing LNURLcash MUST NOT return preimage from a verify endpoint for a minting invoice (any invoice whose preimage is or derives a note's k1). verify for such invoices MUST return "preimage": null while still reporting settled: true — settlement observability without secret disclosure.

For melt verification (the draft's current use), nothing changes: there the preimage is the receipt, and disclosure is the point.

Implementation note

LNURLwallet (the reference client) already tolerates preimage: null on verify polls, so mints can adopt this without breaking the only deployed client. We hit this while designing a mint on top of an existing NUT-01..05 stack and are happy to contribute a conformance test if useful.

[dni]

its a extremely big UX gain for wallets, without this, users need to copy paste their preimage from their lightning wallets into the lnurlcash wallets. which is very annoying. to window for an attacker on the 1st rotation is pretty small and most likely its the users itself paying the invoice for the mint so i dont think its a critical attack vector and definitly a known limitation. @hsjoberg @andrerfneves what do you think, i i would keep that security downside for massive UX gain.