BOLT12 - Revision history

NotATether: Restore content and fix Offers Invoice fetch Deployment sections

2026-09-13T07:34:10Z

Restore content and fix Offers Invoice fetch Deployment sections

← Older revision		Revision as of 07:34, 13 September 2026
Line 15:		Line 15:
	Onion messages that carry offers use the same Sphinx-style onion as payments but without an HTLC. Blinded path hops include encrypted recipient data so intermediate nodes forward without learning the final issuer. If blinded-path onion messages are unavailable end to end, wallets may fall back to a cleartext node id in the offer when the issuer accepts the privacy trade-off.		Onion messages that carry offers use the same Sphinx-style onion as payments but without an HTLC. Blinded path hops include encrypted recipient data so intermediate nodes forward without learning the final issuer. If blinded-path onion messages are unavailable end to end, wallets may fall back to a cleartext node id in the offer when the issuer accepts the privacy trade-off.

	Nodes that do not support onion messages cannot fetch BOLT12 invoices even when they can pay BOLT11. Deployment therefore tracks onion-message and blinded-path support across major Lightning implementations.		Refunds and recurring subscriptions can reuse one offer while each invoice request still creates a fresh payment hash. Merchant software often stores the offer string in a QR or LNURL-style link and lets the wallet complete negotiation silently. Feature bits in the offer tell the payer which invoice fields and payment capabilities are required before it sends an HTLC. Nodes that do not support onion messages cannot fetch BOLT12 invoices even when they can pay BOLT11. Deployment therefore tracks onion-message and blinded-path support across major Lightning implementations.


	== See also ==		== See also ==

NotATether: Add Offers, Invoice fetch, and Deployment sections

2026-09-13T07:33:23Z

Add Offers, Invoice fetch, and Deployment sections

← Older revision		Revision as of 07:33, 13 September 2026
Line 2:		Line 2:

	BOLT11 invoices are static: they fix a payment hash and usually an amount, they expose the destination public key, and they grow long when many routing hints are attached. Recurring or merchant payments need a reusable handle that still yields a unique preimage per payment. Onion messages and blinded paths (BOLT 4 extensions) made it possible to deliver an invoice request without publishing the recipient's location in the invoice. BOLT12, led by Rusty Russell and others, defines offers (<code>lno...</code>), invoice requests, and invoices as TLV streams with Merkle-tree signatures, carried over Lightning onion messages.		BOLT11 invoices are static: they fix a payment hash and usually an amount, they expose the destination public key, and they grow long when many routing hints are attached. Recurring or merchant payments need a reusable handle that still yields a unique preimage per payment. Onion messages and blinded paths (BOLT 4 extensions) made it possible to deliver an invoice request without publishing the recipient's location in the invoice. BOLT12, led by Rusty Russell and others, defines offers (<code>lno...</code>), invoice requests, and invoices as TLV streams with Merkle-tree signatures, carried over Lightning onion messages.

			== Offers ==

	An '''offer''' contains a description, optional amount, issuer fields, feature bits, and either an issuer node id or blinded paths to the issuer. It is encoded as a Bech32 string beginning with <code>lno</code> and may be reused. A payer constructs an '''invoice request''' that includes the offer fields it is responding to, a payer key, an amount if the offer left it open, and a blinded path back to the payer for the reply. The request is sent as an onion message to the issuer. The issuer returns a BOLT12 '''invoice''' with a unique payment hash, amount, created-at time, relative expiry, and one or more blinded paths for the [[Hash Time Locked Contracts\|HTLC]] payment so the payer need not learn the recipient's node id. The invoice is signed with a Merkle-root signature scheme over TLV fields. The payer then sends an ordinary Lightning payment (HTLC, possibly multi-path) along the blinded path.		An '''offer''' contains a description, optional amount, issuer fields, feature bits, and either an issuer node id or blinded paths to the issuer. It is encoded as a Bech32 string beginning with <code>lno</code> and may be reused. A payer constructs an '''invoice request''' that includes the offer fields it is responding to, a payer key, an amount if the offer left it open, and a blinded path back to the payer for the reply. The request is sent as an onion message to the issuer. The issuer returns a BOLT12 '''invoice''' with a unique payment hash, amount, created-at time, relative expiry, and one or more blinded paths for the [[Hash Time Locked Contracts\|HTLC]] payment so the payer need not learn the recipient's node id. The invoice is signed with a Merkle-root signature scheme over TLV fields. The payer then sends an ordinary Lightning payment (HTLC, possibly multi-path) along the blinded path.

			== Invoice fetch ==

	Blinded paths wrap hops in an onion the payer cannot fully inspect, which improves receiver privacy relative to BOLT11's cleartext destination. Reusable offers do not reuse payment hashes. Amount can be chosen at request time, which supports tips and donations. Proof of payment remains a preimage until [[PTLC]]s change that. Onion messages require network support; if a path cannot carry them, the payer cannot fetch an invoice from the offer. Implementations may also fetch invoices over HTTP for the same TLV types, but the native path is Lightning. Related receive UX includes [[Lightning address]] and [[LNURL]].		Blinded paths wrap hops in an onion the payer cannot fully inspect, which improves receiver privacy relative to BOLT11's cleartext destination. Reusable offers do not reuse payment hashes. Amount can be chosen at request time, which supports tips and donations. Proof of payment remains a preimage until [[PTLC]]s change that. Onion messages require network support; if a path cannot carry them, the payer cannot fetch an invoice from the offer. Implementations may also fetch invoices over HTTP for the same TLV types, but the native path is Lightning. Related receive UX includes [[Lightning address]] and [[LNURL]].

			== Deployment ==

	Onion messages that carry offers use the same Sphinx-style onion as payments but without an HTLC. Blinded path hops include encrypted recipient data so intermediate nodes forward without learning the final issuer. If blinded-path onion messages are unavailable end to end, wallets may fall back to a cleartext node id in the offer when the issuer accepts the privacy trade-off.		Onion messages that carry offers use the same Sphinx-style onion as payments but without an HTLC. Blinded path hops include encrypted recipient data so intermediate nodes forward without learning the final issuer. If blinded-path onion messages are unavailable end to end, wallets may fall back to a cleartext node id in the offer when the issuer accepts the privacy trade-off.

	~~Refunds and recurring subscriptions~~ can ~~reuse one offer while each invoice request still creates a fresh payment hash~~. ~~Merchant software often stores the offer string in a QR or LNURL~~-~~style link~~ and ~~lets the wallet complete negotiation silently. Feature bits in the offer tell the payer which invoice fields and payment capabilities are required before it sends an HTLC~~.		Nodes that do not support onion messages cannot fetch BOLT12 invoices even when they can pay BOLT11. Deployment therefore tracks onion-message and blinded-path support across major Lightning implementations.


	== See also ==		== See also ==

NotATether: Add reusable offers and merchant UX

2026-09-13T07:19:45Z

Add reusable offers and merchant UX

← Older revision		Revision as of 07:19, 13 September 2026
Line 8:		Line 8:

	Onion messages that carry offers use the same Sphinx-style onion as payments but without an HTLC. Blinded path hops include encrypted recipient data so intermediate nodes forward without learning the final issuer. If blinded-path onion messages are unavailable end to end, wallets may fall back to a cleartext node id in the offer when the issuer accepts the privacy trade-off.		Onion messages that carry offers use the same Sphinx-style onion as payments but without an HTLC. Blinded path hops include encrypted recipient data so intermediate nodes forward without learning the final issuer. If blinded-path onion messages are unavailable end to end, wallets may fall back to a cleartext node id in the offer when the issuer accepts the privacy trade-off.

			Refunds and recurring subscriptions can reuse one offer while each invoice request still creates a fresh payment hash. Merchant software often stores the offer string in a QR or LNURL-style link and lets the wallet complete negotiation silently. Feature bits in the offer tell the payer which invoice fields and payment capabilities are required before it sends an HTLC.

	== See also ==		== See also ==

NotATether: Add onion-message and blinded-path transport

2026-09-13T07:19:44Z

Add onion-message and blinded-path transport

← Older revision		Revision as of 07:19, 13 September 2026
Line 6:		Line 6:

	Blinded paths wrap hops in an onion the payer cannot fully inspect, which improves receiver privacy relative to BOLT11's cleartext destination. Reusable offers do not reuse payment hashes. Amount can be chosen at request time, which supports tips and donations. Proof of payment remains a preimage until [[PTLC]]s change that. Onion messages require network support; if a path cannot carry them, the payer cannot fetch an invoice from the offer. Implementations may also fetch invoices over HTTP for the same TLV types, but the native path is Lightning. Related receive UX includes [[Lightning address]] and [[LNURL]].		Blinded paths wrap hops in an onion the payer cannot fully inspect, which improves receiver privacy relative to BOLT11's cleartext destination. Reusable offers do not reuse payment hashes. Amount can be chosen at request time, which supports tips and donations. Proof of payment remains a preimage until [[PTLC]]s change that. Onion messages require network support; if a path cannot carry them, the payer cannot fetch an invoice from the offer. Implementations may also fetch invoices over HTTP for the same TLV types, but the native path is Lightning. Related receive UX includes [[Lightning address]] and [[LNURL]].

			Onion messages that carry offers use the same Sphinx-style onion as payments but without an HTLC. Blinded path hops include encrypted recipient data so intermediate nodes forward without learning the final issuer. If blinded-path onion messages are unavailable end to end, wallets may fall back to a cleartext node id in the offer when the issuer accepts the privacy trade-off.

	== See also ==		== See also ==

NotATether: Create BOLT12 stub (offers / invoice requests)

2026-09-12T09:39:01Z

Create BOLT12 stub (offers / invoice requests)

New page

'''BOLT12''' is the Lightning Network protocol for offers, invoice requests, and invoices that are fetched over the Lightning network rather than encoded as a static [[BOLT11]] string. An offer is a compact, often reusable QR that the payer uses to request a fresh invoice, optionally via blinded paths that hide the recipient's node. BOLT 12 is specified in the Lightning BOLTs repository as the offer encoding and negotiation documents.

BOLT11 invoices are static: they fix a payment hash and usually an amount, they expose the destination public key, and they grow long when many routing hints are attached. Recurring or merchant payments need a reusable handle that still yields a unique preimage per payment. Onion messages and blinded paths (BOLT 4 extensions) made it possible to deliver an invoice request without publishing the recipient's location in the invoice. BOLT12, led by Rusty Russell and others, defines offers (<code>lno...</code>), invoice requests, and invoices as TLV streams with Merkle-tree signatures, carried over Lightning onion messages.

An '''offer''' contains a description, optional amount, issuer fields, feature bits, and either an issuer node id or blinded paths to the issuer. It is encoded as a Bech32 string beginning with <code>lno</code> and may be reused. A payer constructs an '''invoice request''' that includes the offer fields it is responding to, a payer key, an amount if the offer left it open, and a blinded path back to the payer for the reply. The request is sent as an onion message to the issuer. The issuer returns a BOLT12 '''invoice''' with a unique payment hash, amount, created-at time, relative expiry, and one or more blinded paths for the [[Hash Time Locked Contracts|HTLC]] payment so the payer need not learn the recipient's node id. The invoice is signed with a Merkle-root signature scheme over TLV fields. The payer then sends an ordinary Lightning payment (HTLC, possibly multi-path) along the blinded path.

Blinded paths wrap hops in an onion the payer cannot fully inspect, which improves receiver privacy relative to BOLT11's cleartext destination. Reusable offers do not reuse payment hashes. Amount can be chosen at request time, which supports tips and donations. Proof of payment remains a preimage until [[PTLC]]s change that. Onion messages require network support; if a path cannot carry them, the payer cannot fetch an invoice from the offer. Implementations may also fetch invoices over HTTP for the same TLV types, but the native path is Lightning. Related receive UX includes [[Lightning address]] and [[LNURL]].

== See also ==
* [[BOLT11]]
* [[Lightning Network]]
* [[Hash Time Locked Contracts]]
* [[PTLC]]
* [[Lightning address]]
* [[LNURL]]

== External links ==
* [https://github.com/lightning/bolts/blob/master/12-offer-encoding.md BOLT 12: Negotiation Protocol for Lightning Payments]
* [https://github.com/lightning/bolts/blob/master/04-onion-routing.md BOLT 4: Onion Routing Protocol]
* [https://bolt12.org/ bolt12.org]

[[Category:Technical]]
[[Category:Privacy]]