Note

A Preimage Is Not a Receipt: What a Settled Lightning Payment Actually Proves

A preimage proves the secret behind a payment hash was released, so that HTLC settled. It does not prove who paid, stay secret after release, or show that a particular person was credited.

2026-10-14 · lightning, preimage, proof-of-payment, htlc, payment-secret, bolt-11, bolt-12, payer-proofs, lnurl, receive-only, tips, protocol-literacy, civil-liberties

Dark CryptoDecentral hex mesh — a single small teal key-shard travelling backward along a chain of bronze nodes, each node glowing faintly as it passes; no text.

Every completed Lightning payment leaves the payer holding 32 bytes they did not have before: the payment preimage. Wallets and specifications call it "proof of payment." That label is accurate and narrow. People stretch it into a receipt that names the payer, confirms the recipient was credited, or settles a dispute, and the protocol never promised any of that.

Thesis, stated once: a preimage proves that the secret behind a particular payment hash was released, which under the HTLC rules means the payment to that hash settled. It does not prove who paid, does not stay secret once released, and does not show that any particular human was credited. For receive-only tip jars, knowing that gap is the difference between honest bookkeeping and believing a story nobody can check.

This follows the receive-only primer and the BOLT-12 offers note, and asks what you actually hold once a tip has gone through.

The mechanism: a hash lock, not a signature from the payer

BOLT #11 requires the invoice writer to "set payment_hash to the SHA2 256-bit hash of the payment_preimage that will be given in return for payment," and describes the p field this way: "Preimage of this provides proof of payment." The invoice is signed by the receiving node's key, so it commits that node to a specific hash, amount, expiry, and description.

The BOLT #0 glossary defines an HTLC (hashed time-locked contract) as a conditional payment in which the recipient spends by presenting a signature and the preimage, and otherwise the payer reclaims after a timeout. Each hop on a route holds one of these contracts with its neighbour, all locked to the same hash. When the final node releases the preimage, it moves backward through every hop.

So the evidence you hold after paying is two things: a signed invoice (the receiver's node committed to this hash for this purpose) and a preimage that hashes to it (someone who knew the secret released it). Together they show that the invoicing node, or whoever controls its keys, accepted payment for that request. That is real and useful. It is also all there is.

Proof of payment, not proof of payer

The BOLT #12 specification is blunt about the limit: the normal Lightning proof of payment "can only demonstrate that an invoice was paid (by showing the preimage of the payment_hash), not who paid it. The merchant can claim an invoice was paid, and once revealed, anyone can claim they paid the invoice, too."

Nothing in a BOLT-11 payment binds the preimage to the sender. The sender's node does not sign anything the receiver keeps as an identity claim, and onion routing exists so the receiver doesn't learn the origin. If a donor posts their preimage publicly as a "receipt," anyone who copies it can make the same claim. The preimage is a bearer fact, not a name.

The secret leaks along the route

BOLT #0 calls the preimage a secret held by "the final recipient, who is the only person who knows this secret." That is true until settlement, and false straight after it.

BOLT #2's forwarding rules say that once a node receives update_fulfill_htlc for an outgoing HTLC, or discovers the preimage from an on-chain spend, it "MUST fulfill the incoming HTLC that corresponds to that outgoing HTLC." The rationale is plain: "knowledge of the preimage is, by definition, irrevocable." Every forwarding node on a successful route therefore learns the preimage as part of collecting its own side.

Three consequences follow:

A preimage is not private evidence. Every hop on the path saw it, and anyone they share it with can show it too.
Payment-hash reuse is dangerous. BOLT #4 lets a final node treat an already-paid hash as unknown, or accept it again. Either way, a hop that already saw the preimage could settle a second HTLC for the same hash without passing it on. That is one reason invoices are one-shot and why offers and LNURL-pay mint fresh hashes.
Hops can link the parts of one payment. Bitcoin Optech's PTLC (point time-locked contract) page notes that because every hop uses the same hash and preimage, payments become linkable "if they're routed offchain though surveillance nodes." PTLCs would give each hop a different lock. Optech also describes PTLC work on Bitcoin as mostly discussion rather than something actively being built, so treat it as future work, not current behaviour.

What the payment secret does, and doesn't

BOLT-11 invoices must also carry an s field, the payment secret. BOLT #4 requires the final node to fail the HTLC if "the payment_secret doesn't match the expected value for that payment_hash," and multi-part payments must carry the same secret on every part. This stops a forwarding node from probing the destination with a guessed hash and amount, because it doesn't know the secret.

It does not authenticate the payer either. Anyone holding the invoice has the payment secret. If you paste a BOLT-11 string publicly, as the BOLT-12 note warns, that protection weakens to "anyone who read the post."

Multi-part payments and hold invoices

For a payment split across paths, BOLT #4 says the receiver "MUST NOT fulfill any HTLCs in the HTLC set" until the parts add up to the total, should wait at least 60 seconds for missing parts, and, if it fulfils any, "MUST fulfill the entire HTLC set." So one preimage really does cover the whole amount; there's no half receipt.

Timing is a separate question. Bitcoin Optech's hold-invoice page describes invoices "where the receiver doesn't immediately release the preimage upon receiving a payment" and instead accepts, rejects, or lets the payment time out. A preimage tells you the payment settled, not when the receiver decided to let it.

Whose node signed the invoice?

For receive-only tips, this question matters most. With LNURL-pay (LUD-06), a wallet fetches a callback and receives a fresh invoice (pr) from an HTTP(S) or Onion service, then checks only that the amount matches what the user chose before paying. The invoice is signed by whatever node that service runs.

If the Lightning Address belongs to a custodial host, the preimage proves the host's node was paid. Whether the person named in the address was credited is a matter of the host's internal ledger. That's an IOU, not a Lightning fact. LUD-21 adds an optional verify URL that reports settled: true with the preimage; the caller can check that the preimage hashes to the invoice's payment_hash, but the "settled" flag is still the service vouching for itself.

The honest tip-jar sentence is: "this node accepted payment for this invoice." Whether that node belongs to the creator, a shared host, or an intermediary is a separate question you answer by checking whose key signed the invoice.

Payer proofs: the spec closing part of the gap

BOLT #12 adds the binding that BOLT-11 lacks. The payer's invoice_request includes an invreq_payer_id, a transient public key the payer must remember. The specification also defines payer proofs (human-readable prefix lnp): a proof built from the invoice fields plus a signature from the invreq_payer_id key, with Merkle branches so the payer can reveal only the fields needed in a dispute.

That proves that whoever holds the transient payer key requested and paid the invoice. It does not say who that is in the world, and support across implementations varies, so check what your software actually produces before relying on it.

Why the narrow reading travels

Tips, mutual aid, and support for open-source maintainers often happen where there's no processor to call and no chargeback desk, so people reach for whatever "proof" they hold. Knowing the limits protects both sides. A recipient can't be framed by a stranger waving a copied preimage, and a donor learns that attribution needs a deliberate mechanism such as a payer proof, a signed message, or simply a trusted relationship, not a leaked secret. Publishing invoices and preimages as public receipts also leaks the receiving node, the amount, the timestamp, and the description to everyone, and that is a privacy cost worth weighing anywhere.

What this is not

This note does not rank wallets, service providers, or hosts. It is not legal, tax, or accounting guidance on what counts as a receipt, and not a dispute procedure. It does not discuss prices, yields, swaps, or custody choices. It does not claim BOLT-12 payer proofs or PTLCs are deployed everywhere; check the implementation in front of you. And it doesn't say preimages are useless. They are precise evidence of settlement against a signed request, which is exactly what they were designed to be.