BOLT11 - Revision history

NotATether: Fix Relation to BOLT12 section placement

2026-09-13T07:34:39Z

Fix Relation to BOLT12 section placement

← Older revision		Revision as of 07:34, 13 September 2026
Line 9:		Line 9:
	== Tagged fields ==		== Tagged fields ==

	Tagged fields include <code>p</code> (required 256-bit payment hash), <code>n</code> (destination public key if not recovered from the signature), <code>d</code> or <code>h</code> (description or description hash), <code>x</code> (expiry in seconds, default 3600), <code>c</code> (min_final_cltv_expiry), <code>f</code> (on-chain fallback address), <code>r</code> (private routing hints for unannounced channels), and <code>9</code> (feature bits the payer must understand). The payer looks up the destination in the network graph, builds an onion (BOLT 4), and sends an HTLC whose payment hash matches the invoice. The receiver reveals the preimage to settle; the preimage is the proof of payment. Expired invoices must not be paid. Payers that retry after expiry should request a new invoice rather than reuse the old payment hash, which would risk payment correlation and stuck HTLCs if the receiver has rotated secrets.		Tagged fields include <code>p</code> (required 256-bit payment hash), <code>n</code> (destination public key if not recovered from the signature), <code>d</code> or <code>h</code> (description or description hash), <code>x</code> (expiry in seconds, default 3600), <code>c</code> (min_final_cltv_expiry), <code>f</code> (on-chain fallback address), <code>r</code> (private routing hints for unannounced channels), and <code>9</code> (feature bits the payer must understand). The payer looks up the destination in the network graph, builds an onion (BOLT 4), and sends an HTLC whose payment hash matches the invoice. The receiver reveals the preimage to settle; the preimage is the proof of payment.

	~~== Relation to~~ BOLT12 ==		BOLT11 invoices are usually single-use: paying the same hash twice reuses HTLC correlation. Amount is fixed in the invoice, though some nodes allow overpayment. There is no built-in reusable offer, payer-blinded path, or asynchronous request for an invoice (those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense. Feature bits signal multi-path payments, payment secrets, and other BOLT 4/9 capabilities; a payer that does not understand compulsory bits must fail. Related receive UX includes [[Lightning address]] and [[LNURL]].

	~~BOLT11 invoices are usually single~~-~~use: paying~~ the ~~same hash twice reuses HTLC correlation. Amount is fixed in~~ the ~~invoice~~, ~~though some nodes allow overpayment~~. ~~There is no built-in reusable offer, payer~~-~~blinded~~ path~~, or asynchronous request for an~~ invoice ~~(those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense~~. ~~Feature bits signal multi~~-~~path payments, payment secrets,~~ and ~~other BOLT 4/9 capabilities;~~ a ~~payer that does~~ not ~~understand compulsory bits must fail~~. ~~Related receive UX includes [[Lightning address]]~~ and ~~[[LNURL]]~~.		The payment secret field (feature-gated) binds the invoice to a secret the final hop must present, which reduces probing that guesses payment hashes. Multi-path payments may split value across several HTLCs that share the same payment hash from one invoice when both peers support the feature bits. Fallback on-chain addresses let a payer abandon Lightning and pay the invoice amount as a normal Bitcoin transaction if routing fails before expiry. Expired invoices must not be paid. Payers that retry after expiry should request a new invoice rather than reuse the old payment hash, which would risk payment correlation and stuck HTLCs if the receiver has rotated secrets.

	~~The payment secret field (feature-gated) binds the invoice~~ to a secret the final hop must present, which reduces probing that guesses payment hashes. Multi-path payments may split value across several HTLCs that share the same payment hash from one invoice when both peers support the feature bits. Fallback on-chain addresses let a payer abandon Lightning and pay the invoice amount as a normal Bitcoin transaction if routing fails before expiry.		== Relation to BOLT12 ==

	Signature recovery yields the destination node id when the <code>n</code> field is omitted, which shortens the string. Payers still verify that recovered key against the network graph before sending value. [[BOLT12]] offers are intended for reusable and privacy-sensitive receives. BOLT11 remains common for one-shot QR payments and for software that has not yet implemented onion-message invoice fetch.		Signature recovery yields the destination node id when the <code>n</code> field is omitted, which shortens the string. Payers still verify that recovered key against the network graph before sending value. [[BOLT12]] offers are intended for reusable and privacy-sensitive receives. BOLT11 remains common for one-shot QR payments and for software that has not yet implemented onion-message invoice fetch.

NotATether: Restore content and fix Encoding Tagged fields Relation sections

2026-09-13T07:34:08Z

Restore content and fix Encoding Tagged fields Relation sections

← Older revision		Revision as of 07:34, 13 September 2026
Line 9:		Line 9:
	== Tagged fields ==		== Tagged fields ==

	Tagged fields include <code>p</code> (required 256-bit payment hash), <code>n</code> (destination public key if not recovered from the signature), <code>d</code> or <code>h</code> (description or description hash), <code>x</code> (expiry in seconds, default 3600), <code>c</code> (min_final_cltv_expiry), <code>f</code> (on-chain fallback address), <code>r</code> (private routing hints for unannounced channels), and <code>9</code> (feature bits the payer must understand). The payer looks up the destination in the network graph, builds an onion (BOLT 4), and sends an HTLC whose payment hash matches the invoice. The receiver reveals the preimage to settle; the preimage is the proof of payment.		Tagged fields include <code>p</code> (required 256-bit payment hash), <code>n</code> (destination public key if not recovered from the signature), <code>d</code> or <code>h</code> (description or description hash), <code>x</code> (expiry in seconds, default 3600), <code>c</code> (min_final_cltv_expiry), <code>f</code> (on-chain fallback address), <code>r</code> (private routing hints for unannounced channels), and <code>9</code> (feature bits the payer must understand). The payer looks up the destination in the network graph, builds an onion (BOLT 4), and sends an HTLC whose payment hash matches the invoice. The receiver reveals the preimage to settle; the preimage is the proof of payment. Expired invoices must not be paid. Payers that retry after expiry should request a new invoice rather than reuse the old payment hash, which would risk payment correlation and stuck HTLCs if the receiver has rotated secrets.

	Expired invoices must not be paid. Payers that retry after expiry should request a new invoice rather than reuse the old payment hash, which would risk payment correlation and stuck HTLCs if the receiver has rotated secrets.

	== Relation to BOLT12 ==		== Relation to BOLT12 ==
Line 17:		Line 15:
	BOLT11 invoices are usually single-use: paying the same hash twice reuses HTLC correlation. Amount is fixed in the invoice, though some nodes allow overpayment. There is no built-in reusable offer, payer-blinded path, or asynchronous request for an invoice (those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense. Feature bits signal multi-path payments, payment secrets, and other BOLT 4/9 capabilities; a payer that does not understand compulsory bits must fail. Related receive UX includes [[Lightning address]] and [[LNURL]].		BOLT11 invoices are usually single-use: paying the same hash twice reuses HTLC correlation. Amount is fixed in the invoice, though some nodes allow overpayment. There is no built-in reusable offer, payer-blinded path, or asynchronous request for an invoice (those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense. Feature bits signal multi-path payments, payment secrets, and other BOLT 4/9 capabilities; a payer that does not understand compulsory bits must fail. Related receive UX includes [[Lightning address]] and [[LNURL]].

			The payment secret field (feature-gated) binds the invoice to a secret the final hop must present, which reduces probing that guesses payment hashes. Multi-path payments may split value across several HTLCs that share the same payment hash from one invoice when both peers support the feature bits. Fallback on-chain addresses let a payer abandon Lightning and pay the invoice amount as a normal Bitcoin transaction if routing fails before expiry.

			Signature recovery yields the destination node id when the <code>n</code> field is omitted, which shortens the string. Payers still verify that recovered key against the network graph before sending value. [[BOLT12]] offers are intended for reusable and privacy-sensitive receives. BOLT11 remains common for one-shot QR payments and for software that has not yet implemented onion-message invoice fetch.

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

NotATether: Add Encoding, Tagged fields, and Relation to BOLT12 sections

2026-09-13T07:33:22Z

Add Encoding, Tagged fields, and Relation to BOLT12 sections

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

	Lightning payments need a way for a receiver to communicate a payment hash (the SHA256 of a secret preimage), the amount, and how to reach the receiving node if it is not in the public graph. BOLT 11 defined a signed, human-copyable invoice before BOLT12 offers. It remains the most widely scanned Lightning invoice type on the [[Lightning Network]].		Lightning payments need a way for a receiver to communicate a payment hash (the SHA256 of a secret preimage), the amount, and how to reach the receiving node if it is not in the public graph. BOLT 11 defined a signed, human-copyable invoice before BOLT12 offers. It remains the most widely scanned Lightning invoice type on the [[Lightning Network]].

			== Encoding ==

	The string is a human-readable prefix plus a Bech32 data part. The prefix is <code>ln</code> concatenated with a currency code (<code>bc</code> for Bitcoin mainnet, <code>tb</code> for testnet) and an optional amount with a multiplier (for example <code>lnbc2500u</code> for 2500 microbitcoin). The data part contains a timestamp and tagged fields, then a 512-bit recoverable signature over the invoice data using the destination node's key.		The string is a human-readable prefix plus a Bech32 data part. The prefix is <code>ln</code> concatenated with a currency code (<code>bc</code> for Bitcoin mainnet, <code>tb</code> for testnet) and an optional amount with a multiplier (for example <code>lnbc2500u</code> for 2500 microbitcoin). The data part contains a timestamp and tagged fields, then a 512-bit recoverable signature over the invoice data using the destination node's key.

			== Tagged fields ==

	Tagged fields include <code>p</code> (required 256-bit payment hash), <code>n</code> (destination public key if not recovered from the signature), <code>d</code> or <code>h</code> (description or description hash), <code>x</code> (expiry in seconds, default 3600), <code>c</code> (min_final_cltv_expiry), <code>f</code> (on-chain fallback address), <code>r</code> (private routing hints for unannounced channels), and <code>9</code> (feature bits the payer must understand). The payer looks up the destination in the network graph, builds an onion (BOLT 4), and sends an HTLC whose payment hash matches the invoice. The receiver reveals the preimage to settle; the preimage is the proof of payment.		Tagged fields include <code>p</code> (required 256-bit payment hash), <code>n</code> (destination public key if not recovered from the signature), <code>d</code> or <code>h</code> (description or description hash), <code>x</code> (expiry in seconds, default 3600), <code>c</code> (min_final_cltv_expiry), <code>f</code> (on-chain fallback address), <code>r</code> (private routing hints for unannounced channels), and <code>9</code> (feature bits the payer must understand). The payer looks up the destination in the network graph, builds an onion (BOLT 4), and sends an HTLC whose payment hash matches the invoice. The receiver reveals the preimage to settle; the preimage is the proof of payment.

			Expired invoices must not be paid. Payers that retry after expiry should request a new invoice rather than reuse the old payment hash, which would risk payment correlation and stuck HTLCs if the receiver has rotated secrets.

			== Relation to BOLT12 ==

	BOLT11 invoices are usually single-use: paying the same hash twice reuses HTLC correlation. Amount is fixed in the invoice, though some nodes allow overpayment. There is no built-in reusable offer, payer-blinded path, or asynchronous request for an invoice (those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense. Feature bits signal multi-path payments, payment secrets, and other BOLT 4/9 capabilities; a payer that does not understand compulsory bits must fail. Related receive UX includes [[Lightning address]] and [[LNURL]].		BOLT11 invoices are usually single-use: paying the same hash twice reuses HTLC correlation. Amount is fixed in the invoice, though some nodes allow overpayment. There is no built-in reusable offer, payer-blinded path, or asynchronous request for an invoice (those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense. Feature bits signal multi-path payments, payment secrets, and other BOLT 4/9 capabilities; a payer that does not understand compulsory bits must fail. Related receive UX includes [[Lightning address]] and [[LNURL]].

	The payment secret field (feature-gated) binds the invoice to a secret the final hop must present, which reduces probing that guesses payment hashes. Multi-path payments may split value across several HTLCs that share the same payment hash from one invoice when both peers support the feature bits. Fallback on-chain addresses let a payer abandon Lightning and pay the invoice amount as a normal Bitcoin transaction if routing fails before expiry.

	Signature recovery yields the destination node id when the <code>n</code> field is omitted, which shortens the string. Payers still verify that recovered key against the network graph before sending value. [[BOLT12]] offers are intended for reusable and privacy-sensitive receives. BOLT11 remains common for one-shot QR payments and for software that has not yet implemented onion-message invoice fetch.

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

NotATether: Expand See also links

2026-09-13T07:19:42Z

Expand See also links

← Older revision		Revision as of 07:19, 13 September 2026
Line 15:		Line 15:
	== See also ==		== See also ==
	* [[Lightning Network]]		* [[Lightning Network]]
			* [[BOLT12]]
	* [[Hash Time Locked Contracts]]		* [[Hash Time Locked Contracts]]
	* [[Lightning address]]		* [[Lightning address]]

NotATether: Add signature recovery and BOLT12 contrast

2026-09-13T07:19:40Z

Add signature recovery and BOLT12 contrast

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

	The payment secret field (feature-gated) binds the invoice to a secret the final hop must present, which reduces probing that guesses payment hashes. Multi-path payments may split value across several HTLCs that share the same payment hash from one invoice when both peers support the feature bits. Fallback on-chain addresses let a payer abandon Lightning and pay the invoice amount as a normal Bitcoin transaction if routing fails before expiry.		The payment secret field (feature-gated) binds the invoice to a secret the final hop must present, which reduces probing that guesses payment hashes. Multi-path payments may split value across several HTLCs that share the same payment hash from one invoice when both peers support the feature bits. Fallback on-chain addresses let a payer abandon Lightning and pay the invoice amount as a normal Bitcoin transaction if routing fails before expiry.

			Signature recovery yields the destination node id when the <code>n</code> field is omitted, which shortens the string. Payers still verify that recovered key against the network graph before sending value. [[BOLT12]] offers are intended for reusable and privacy-sensitive receives. BOLT11 remains common for one-shot QR payments and for software that has not yet implemented onion-message invoice fetch.

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

NotATether: Add payment secret, MPP, and fallback

2026-09-13T07:19:39Z

Add payment secret, MPP, and fallback

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

	BOLT11 invoices are usually single-use: paying the same hash twice reuses HTLC correlation. Amount is fixed in the invoice, though some nodes allow overpayment. There is no built-in reusable offer, payer-blinded path, or asynchronous request for an invoice (those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense. Feature bits signal multi-path payments, payment secrets, and other BOLT 4/9 capabilities; a payer that does not understand compulsory bits must fail. Related receive UX includes [[Lightning address]] and [[LNURL]].		BOLT11 invoices are usually single-use: paying the same hash twice reuses HTLC correlation. Amount is fixed in the invoice, though some nodes allow overpayment. There is no built-in reusable offer, payer-blinded path, or asynchronous request for an invoice (those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense. Feature bits signal multi-path payments, payment secrets, and other BOLT 4/9 capabilities; a payer that does not understand compulsory bits must fail. Related receive UX includes [[Lightning address]] and [[LNURL]].

			The payment secret field (feature-gated) binds the invoice to a secret the final hop must present, which reduces probing that guesses payment hashes. Multi-path payments may split value across several HTLCs that share the same payment hash from one invoice when both peers support the feature bits. Fallback on-chain addresses let a payer abandon Lightning and pay the invoice amount as a normal Bitcoin transaction if routing fails before expiry.

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

NotATether: Create BOLT11 stub (Lightning invoice encoding)

2026-09-12T04:57:29Z

Create BOLT11 stub (Lightning invoice encoding)

New page

'''BOLT11''' is the Lightning Network invoice format specified in BOLT 11 of the Basis of Lightning Technology. An invoice encodes a payment hash, amount, expiry, destination node, and optional routing hints in a Bech32-style string that usually starts with <code>lnbc</code> on Bitcoin mainnet. Wallets scan a QR code or paste the string, then send an onion-routed [[Hash Time Locked Contracts|HTLC]] to the destination.

Lightning payments need a way for a receiver to communicate a payment hash (the SHA256 of a secret preimage), the amount, and how to reach the receiving node if it is not in the public graph. BOLT 11 defined a signed, human-copyable invoice before BOLT12 offers. It remains the most widely scanned Lightning invoice type on the [[Lightning Network]].

The string is a human-readable prefix plus a Bech32 data part. The prefix is <code>ln</code> concatenated with a currency code (<code>bc</code> for Bitcoin mainnet, <code>tb</code> for testnet) and an optional amount with a multiplier (for example <code>lnbc2500u</code> for 2500 microbitcoin). The data part contains a timestamp and tagged fields, then a 512-bit recoverable signature over the invoice data using the destination node's key.

Tagged fields include <code>p</code> (required 256-bit payment hash), <code>n</code> (destination public key if not recovered from the signature), <code>d</code> or <code>h</code> (description or description hash), <code>x</code> (expiry in seconds, default 3600), <code>c</code> (min_final_cltv_expiry), <code>f</code> (on-chain fallback address), <code>r</code> (private routing hints for unannounced channels), and <code>9</code> (feature bits the payer must understand). The payer looks up the destination in the network graph, builds an onion (BOLT 4), and sends an HTLC whose payment hash matches the invoice. The receiver reveals the preimage to settle; the preimage is the proof of payment.

BOLT11 invoices are usually single-use: paying the same hash twice reuses HTLC correlation. Amount is fixed in the invoice, though some nodes allow overpayment. There is no built-in reusable offer, payer-blinded path, or asynchronous request for an invoice (those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense. Feature bits signal multi-path payments, payment secrets, and other BOLT 4/9 capabilities; a payer that does not understand compulsory bits must fail. Related receive UX includes [[Lightning address]] and [[LNURL]].

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

== External links ==
* [https://github.com/lightning/bolts/blob/master/11-payment-encoding.md BOLT 11: Invoice Protocol for Lightning Payments]
* [https://github.com/lightning/bolts/blob/master/04-onion-routing.md BOLT 4: Onion Routing Protocol]
* [https://github.com/lightning/bolts/blob/master/09-features.md BOLT 9: Assigned Feature Flags]

[[Category:Technical]]