Lightning address - Revision history

NotATether: Restore content and fix Resolution Tags Availability sections

2026-09-13T07:34:05Z

Restore content and fix Resolution Tags Availability sections

← Older revision		Revision as of 07:34, 13 September 2026
Line 7:		Line 7:
	The wallet splits the string on the last <code>@</code>. The local part is restricted to <code>a-z0-9-_.</code>, which is stricter than RFC 5322 email. A plus sign is allowed when the service supports tags. For <code>satoshi@example.com</code> the wallet GETs:		The wallet splits the string on the last <code>@</code>. The local part is restricted to <code>a-z0-9-_.</code>, which is stricter than RFC 5322 email. A plus sign is allowed when the service supports tags. For <code>satoshi@example.com</code> the wallet GETs:

	<code>https://example.com/.well-known/lnurlp/satoshi</code>		<code>https://example.com/.well-known/lnurlp/satoshi</code>

			On an onion domain the scheme is HTTP rather than HTTPS. The JSON response is an LNURL-pay (LUD-06) document.

			The LUD-06 document includes a callback URL, min and max sendable amounts, and metadata. The metadata must include a <code>text/identifier</code> or <code>text/email</code> entry for the address. The wallet then requests an invoice from the callback with the chosen amount in millisatoshis, checks that the invoice amount matches, and pays it.

	== Tags ==		== Tags ==

	~~On an onion~~ domain ~~the scheme is HTTP rather than HTTPS~~. The ~~JSON response is an LNURL~~-~~pay (LUD-06) document~~.		A <code>user+tag@domain</code> form lets a service offer several identifiers for one user. The wallet requests <code>/.well-known/lnurlp/user+tag</code>. The server may strip the tag for routing and may put the tag into metadata.

	== Availability ==		== Availability ==

	~~The LUD~~-~~06 document includes a callback URL, min and max sendable amounts, and metadata~~. The ~~metadata~~ must ~~include~~ a <code>~~text/identifier~~</code> or <code>~~text/email~~</code> ~~entry for the~~ address. ~~The wallet then requests an invoice from the callback with the chosen amount in millisatoshis, checks that the invoice amount matches, and pays it~~.		Lightning address inherits LNURL-pay's properties. The receiver's server must be online. The payer's IP is visible to that server. Successive payments to the same address can be correlated by the server even though each invoice is unique. The address itself never appears on the Bitcoin chain.

			Later work such as [https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki BIP 353] encodes a payment URI in a DNS TXT record under <code><user>.user._bitcoin-payment.<domain></code>. That record can point to BOLT 12 offers, on-chain addresses, or Silent Payment codes, and is authenticated with DNSSEC rather than with an HTTPS server. BIP 353 addresses may be displayed with a bitcoin symbol prefix. They are a different resolution mechanism that happens to use a similar <code>user@domain</code> display format. BIP 353 is intended to extend and subsume Lightning address. Wallets may fall back to LUD-16 if DNS resolution fails.

	~~Services that publish Lightning addresses should keep the well~~-~~known path behind authenticated TLS~~ and ~~should not redirect payers to unrelated hosts~~. ~~A hijacked DNS or certificate~~ can ~~replace~~ the ~~LNURL-pay document without touching~~ the Lightning node.		Servers may rate-limit invoice minting to reduce probing and denial-of-service load. Payers that fetch many quotes without paying can still learn the receiver's liquidity hints from returned invoices. Some deployments put the Lightning node behind a reverse proxy that only exposes the well-known LNURL paths.

			Unlike a static on-chain address, a Lightning address never receives coins by itself. Every successful pay path ends in a BOLT11 (or occasionally BOLT12) invoice settlement. If the HTTPS endpoint is unavailable, payers cannot resolve the address even when the Lightning node is online. Operators therefore treat web uptime as part of receive availability. Services that publish Lightning addresses should keep the well-known path behind authenticated TLS and should not redirect payers to unrelated hosts. A hijacked DNS or certificate can replace the LNURL-pay document without touching the Lightning node.

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

NotATether: Add Resolution, Tags, and Availability sections

2026-09-13T07:33:25Z

Add Resolution, Tags, and Availability sections

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

	Lightning invoices are long, usually single-use, and inconvenient to read aloud or print. LNURL-pay already allowed a reusable HTTPS URL. The mapping from that URL to an email-shaped string was published as LUD-16 in 2021 (authors akumaigorodski, André Neves, and fiatjaf). It requires a web server and a Lightning node that can mint invoices, not a change to Bitcoin or to the Lightning BOLTs.		Lightning invoices are long, usually single-use, and inconvenient to read aloud or print. LNURL-pay already allowed a reusable HTTPS URL. The mapping from that URL to an email-shaped string was published as LUD-16 in 2021 (authors akumaigorodski, André Neves, and fiatjaf). It requires a web server and a Lightning node that can mint invoices, not a change to Bitcoin or to the Lightning BOLTs.

			== Resolution ==

	The wallet splits the string on the last <code>@</code>. The local part is restricted to <code>a-z0-9-_.</code>, which is stricter than RFC 5322 email. A plus sign is allowed when the service supports tags. For <code>satoshi@example.com</code> the wallet GETs:		The wallet splits the string on the last <code>@</code>. The local part is restricted to <code>a-z0-9-_.</code>, which is stricter than RFC 5322 email. A plus sign is allowed when the service supports tags. For <code>satoshi@example.com</code> the wallet GETs:

	<code>https://example.com/.well-known/lnurlp/satoshi</code>		<code>https://example.com/.well-known/lnurlp/satoshi</code>

			== Tags ==

	On an onion domain the scheme is HTTP rather than HTTPS. The JSON response is an LNURL-pay (LUD-06) document.		On an onion domain the scheme is HTTP rather than HTTPS. The JSON response is an LNURL-pay (LUD-06) document.

			== Availability ==

	The LUD-06 document includes a callback URL, min and max sendable amounts, and metadata. The metadata must include a <code>text/identifier</code> or <code>text/email</code> entry for the address. The wallet then requests an invoice from the callback with the chosen amount in millisatoshis, checks that the invoice amount matches, and pays it.		The LUD-06 document includes a callback URL, min and max sendable amounts, and metadata. The metadata must include a <code>text/identifier</code> or <code>text/email</code> entry for the address. The wallet then requests an invoice from the callback with the chosen amount in millisatoshis, checks that the invoice amount matches, and pays it.

	~~A <code>user+tag@domain</code> form lets a service offer several identifiers for one user. The wallet requests <code>/.~~well-known~~/lnurlp/user+tag</code>. The server may strip the tag for routing~~ and ~~may put the tag into metadata.~~		Services that publish Lightning addresses should keep the well-known path behind authenticated TLS and should not redirect payers to unrelated hosts. A hijacked DNS or certificate can replace the LNURL-pay document without touching the Lightning node.

	~~Lightning address inherits LNURL-pay's properties. The receiver's server must be online. The payer's IP is visible~~ to ~~that server~~. ~~Successive payments to the same address~~ can ~~be correlated by~~ the ~~server even though each invoice is unique. The address itself never appears on the Bitcoin chain.~~

	~~Later work such as [https://github.com/bitcoin/bips/blob/master/bip~~-0353.mediawiki BIP 353] encodes a payment URI in a DNS TXT record under <code><user>.user._bitcoin-payment.<domain></code>. That record can point to BOLT 12 offers, on-chain addresses, or Silent Payment codes, and is authenticated with DNSSEC rather than with an HTTPS server. BIP 353 addresses may be displayed with a bitcoin symbol prefix. They are a different resolution mechanism that happens to use a similar <code>user@domain</code> display format. BIP 353 is intended to extend and subsume Lightning address. Wallets may fall back to LUD-16 if DNS resolution fails.

	~~Servers may rate-limit invoice minting to reduce probing and denial-of-service load. Payers that fetch many quotes~~ without ~~paying can still learn the receiver's liquidity hints from returned invoices. Some deployments put~~ the Lightning node ~~behind a reverse proxy that only exposes the well-known LNURL paths~~.

	Unlike a static on-chain address, a Lightning address never receives coins by itself. Every successful pay path ends in a BOLT11 (or occasionally BOLT12) invoice settlement. If the HTTPS endpoint is unavailable, payers cannot resolve the address even when the Lightning node is online. Operators therefore treat web uptime as part of receive availability.

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

NotATether: Expand See also links

2026-09-13T07:23:35Z

Expand See also links

← Older revision		Revision as of 07:23, 13 September 2026
Line 25:		Line 25:
	* [[LNURL]]		* [[LNURL]]
	* [[Lightning Network]]		* [[Lightning Network]]
			* [[BOLT11]]
			* [[BOLT12]]
	* [[BIP 0021]]		* [[BIP 0021]]
	* [[Silent Payments]]		* [[Silent Payments]]

NotATether: Add dependency on HTTPS availability

2026-09-13T07:23:33Z

Add dependency on HTTPS availability

← Older revision		Revision as of 07:23, 13 September 2026
Line 18:		Line 18:

	Servers may rate-limit invoice minting to reduce probing and denial-of-service load. Payers that fetch many quotes without paying can still learn the receiver's liquidity hints from returned invoices. Some deployments put the Lightning node behind a reverse proxy that only exposes the well-known LNURL paths.		Servers may rate-limit invoice minting to reduce probing and denial-of-service load. Payers that fetch many quotes without paying can still learn the receiver's liquidity hints from returned invoices. Some deployments put the Lightning node behind a reverse proxy that only exposes the well-known LNURL paths.

			Unlike a static on-chain address, a Lightning address never receives coins by itself. Every successful pay path ends in a BOLT11 (or occasionally BOLT12) invoice settlement. If the HTTPS endpoint is unavailable, payers cannot resolve the address even when the Lightning node is online. Operators therefore treat web uptime as part of receive availability.

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

NotATether: Add rate limits and hosting pattern

2026-09-13T07:23:32Z

Add rate limits and hosting pattern

← Older revision		Revision as of 07:23, 13 September 2026
Line 16:		Line 16:

	Later work such as [https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki BIP 353] encodes a payment URI in a DNS TXT record under <code><user>.user._bitcoin-payment.<domain></code>. That record can point to BOLT 12 offers, on-chain addresses, or Silent Payment codes, and is authenticated with DNSSEC rather than with an HTTPS server. BIP 353 addresses may be displayed with a bitcoin symbol prefix. They are a different resolution mechanism that happens to use a similar <code>user@domain</code> display format. BIP 353 is intended to extend and subsume Lightning address. Wallets may fall back to LUD-16 if DNS resolution fails.		Later work such as [https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki BIP 353] encodes a payment URI in a DNS TXT record under <code><user>.user._bitcoin-payment.<domain></code>. That record can point to BOLT 12 offers, on-chain addresses, or Silent Payment codes, and is authenticated with DNSSEC rather than with an HTTPS server. BIP 353 addresses may be displayed with a bitcoin symbol prefix. They are a different resolution mechanism that happens to use a similar <code>user@domain</code> display format. BIP 353 is intended to extend and subsume Lightning address. Wallets may fall back to LUD-16 if DNS resolution fails.

			Servers may rate-limit invoice minting to reduce probing and denial-of-service load. Payers that fetch many quotes without paying can still learn the receiver's liquidity hints from returned invoices. Some deployments put the Lightning node behind a reverse proxy that only exposes the well-known LNURL paths.

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

NotATether: add well-known lnurlp, pay flow, properties, BIP 353; See also BIP 0021 + Silent Payments

2026-09-04T04:49:39Z

add well-known lnurlp, pay flow, properties, BIP 353; See also BIP 0021 + Silent Payments

@@ Line 2: / Line 2: @@
 Lightning invoices are long, usually single-use, and inconvenient to read aloud or print. LNURL-pay already allowed a reusable HTTPS URL. The mapping from that URL to an email-shaped string was published as LUD-16 in 2021 (authors akumaigorodski, André Neves, and fiatjaf). It requires a web server and a Lightning node that can mint invoices, not a change to Bitcoin or to the Lightning BOLTs.
 == See also ==
@@ Line 7: / Line 21: @@
 * [[LNURL]]
 * [[Lightning Network]]
 == External links ==

NotATether: add LUD-16 (2021) to the lead

2026-09-03T07:00:22Z

add LUD-16 (2021) to the lead

← Older revision		Revision as of 07:00, 3 September 2026
Line 1:		Line 1:
	A '''Lightning address''' is a static identifier of the form <code>user@domain</code> that a Lightning wallet resolves to an [[LNURL]]-pay endpoint. It is specified as LUD-16. The identifier is not a Bitcoin address and is not a BOLT 12 offer. Each payment still fetches a fresh BOLT 11 invoice over HTTPS.		A '''Lightning address''' is a static identifier of the form <code>user@domain</code> that a Lightning wallet resolves to an [[LNURL]]-pay endpoint. It is specified as LUD-16. The identifier is not a Bitcoin address and is not a BOLT 12 offer. Each payment still fetches a fresh BOLT 11 invoice over HTTPS.

			Lightning invoices are long, usually single-use, and inconvenient to read aloud or print. LNURL-pay already allowed a reusable HTTPS URL. The mapping from that URL to an email-shaped string was published as LUD-16 in 2021 (authors akumaigorodski, André Neves, and fiatjaf). It requires a web server and a Lightning node that can mint invoices, not a change to Bitcoin or to the Lightning BOLTs.

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

NotATether: stub: Lightning address (LUD-16) maps user@domain to LNURL-pay

2026-09-03T06:47:31Z

stub: Lightning address (LUD-16) maps user@domain to LNURL-pay

New page

A '''Lightning address''' is a static identifier of the form <code>user@domain</code> that a Lightning wallet resolves to an [[LNURL]]-pay endpoint. It is specified as LUD-16. The identifier is not a Bitcoin address and is not a BOLT 12 offer. Each payment still fetches a fresh BOLT 11 invoice over HTTPS.

== See also ==

* [[LNURL]]
* [[Lightning Network]]

== External links ==

* https://github.com/lnurl/luds/blob/luds/16.md — LUD-16: paying to static internet identifiers

[[Category:Technical]]