LNURL - Revision history

NotATether: Add Encoding section and expand LUDs Security Status from LUD sources

2026-09-13T07:38:51Z

Add Encoding section and expand LUDs Security Status from LUD sources

← Older revision		Revision as of 07:38, 13 September 2026
Line 1:		Line 1:
	'''LNURL''' is a family of HTTP protocols that let a Lightning wallet talk to a service without embedding a full BOLT 11 invoice in every QR code. A Bech32 string starting with <code>lnurl1</code> decodes to an HTTPS (or onion) endpoint. The wallet GETs that endpoint, receives JSON, and then pays an invoice, withdraws, authenticates, or requests a channel. The documents are LNURL specifications (LUDs), not BIPs. [[Lightning address]] (LUD-16) is a human-readable alias for LNURL-pay.		'''LNURL''' is a family of HTTP protocols that let a Lightning wallet talk to a service without embedding a full BOLT 11 invoice in every QR code. A Bech32 string starting with <code>lnurl1</code> decodes to an HTTPS (or onion) endpoint. The wallet GETs that endpoint, receives JSON, and then pays an invoice, withdraws, authenticates, or requests a channel. The documents are LNURL specifications (LUDs), not BIPs. [[Lightning address]] (LUD-16) is a human-readable alias for LNURL-pay.

			== Encoding ==

			LUD-01 defines the Bech32 encoding. The human-readable part is <code>lnurl</code>. The data part is the UTF-8 URL as 5-bit groups. Mixed case is forbidden. QR codes should use uppercase. After decoding, if the URL already carries a <code>tag</code> query parameter the wallet uses that tag. Otherwise it GETs the URL and reads a JSON <code>tag</code> field.

			Clearnet endpoints must be <code>https://</code> with a publicly trusted certificate. Onion endpoints use <code>http://</code> for Tor v2 or v3 addresses. LUD-01 tells clients to ignore HTTP status codes and headers for protocol meaning and to parse the body as JSON. Services that want browser wallets should send <code>Access-Control-Allow-Origin: *</code> on LNURL GETs.

			An LNURL may appear as a <code>lightning=</code> parameter inside another URI so a webpage can offer both an ordinary link and a scannable LNURL fallback.

	== Common LUDs ==		== Common LUDs ==

	Common LUDs include pay request (LUD-06), withdraw request, channel request, and authentication flows. The wallet presents a Bech32 <code>lnurl1...</code> string or a clear HTTPS URL. After decoding, it follows HTTP redirects only within limits defined by the LUD and expects JSON error objects when the service rejects the request~~. Services must use TLS on clearnet hosts. Tor onion endpoints are allowed where the LUD permits them~~.		Common LUDs include pay request (LUD-06), withdraw request (LUD-03), channel request, and authentication flows. The wallet presents a Bech32 <code>lnurl1...</code> string or a clear HTTPS URL. After decoding, it follows HTTP redirects only within limits defined by the LUD and expects JSON error objects when the service rejects the request.

	LNURL-pay returns a callback that mints a fresh [[BOLT11]] invoice for the chosen amount. That keeps QR codes short while still settling with ordinary Lightning HTLCs. [[BOLT12]] offers pursue a similar reusable-receive goal over onion messages instead of HTTPS. Wallets may support both. A Lightning address is only a LUD-16 alias that resolves to LNURL-pay.		LNURL-pay returns a callback that mints a fresh [[BOLT11]] invoice for the chosen amount. That keeps QR codes short while still settling with ordinary Lightning HTLCs. The pay response advertises min and max sendable amounts in millisatoshis plus metadata the wallet must hash into the invoice description where the LUD requires it. [[BOLT12]] offers pursue a similar reusable-receive goal over onion messages instead of HTTPS. Wallets may support both. A Lightning address is only a LUD-16 alias that resolves to LNURL-pay via <code>/.well-known/lnurlp/<user></code>.

	Withdraw flows (LUD-03 and related) ~~let~~ a ~~service push~~ a ~~spendable~~ invoice ~~request to a wallet that scans an lnurl-withdraw QR~~. Channel-request LUDs ask a node to open inbound capacity toward the wallet, which overlaps operationally with LSP tooling even when the wire format differs. Authentication LUDs prove control of a Lightning node key over HTTPS without creating a long-lived account password on the service.		Withdraw flows (LUD-03 and related) return a callback, a one-time <code>k1</code> challenge, and min/max withdrawable amounts. The wallet creates a BOLT11 invoice and returns it on the callback so the service can pay. Channel-request LUDs ask a node to open inbound capacity toward the wallet, which overlaps operationally with LSP tooling even when the wire format differs. Authentication LUDs prove control of a Lightning node key over HTTPS without creating a long-lived account password on the service.

	== Security ==		== Security ==

	Because LNURL is HTTP, operators must protect endpoints against SSRF-style callback abuse, open redirects, and invoice substitution. Wallets should pin expected domains when following Lightning address well-known paths and should reject cleartext HTTP on non-onion hosts. A compromised web server can steal withdrawals or issue unpaid invoices even if the Lightning node itself remains honest. Withdraw endpoints should rate-limit k1 challenges and bind them to short lifetimes so stolen QR codes cannot drain funds indefinitely.		Because LNURL is HTTP, operators must protect endpoints against SSRF-style callback abuse, open redirects, and invoice substitution. Wallets should pin expected domains when following Lightning address well-known paths and should reject cleartext HTTP on non-onion hosts. A compromised web server can steal withdrawals or issue unpaid invoices even if the Lightning node itself remains honest. Withdraw endpoints should rate-limit <code>k1</code> challenges and bind them to short lifetimes so stolen QR codes cannot drain funds indefinitely.

	Services that mint invoices on behalf of users should authenticate callbacks and bind amounts so a malicious webpage cannot substitute a higher invoice after the wallet has shown a quote.		Services that mint invoices on behalf of users should authenticate callbacks and bind amounts so a malicious webpage cannot substitute a higher invoice after the wallet has shown a quote. Metadata in LNURL-pay must match what the wallet embeds when it verifies the returned invoice. Mismatched description hashes are a common phishing signal.

	== Status ==		== Status ==

	LNURL remains widely deployed for Lightning addresses and withdraw kiosks even as [[BOLT12]] offers spread. Many wallets implement a subset of LUDs. Operators should publish which LUDs they support and keep TLS certificates current, because expired HTTPS breaks receives independently of Lightning channel health.		LNURL remains widely deployed for Lightning addresses and withdraw kiosks even as [[BOLT12]] offers spread. Many wallets implement a subset of LUDs rather than the full catalog. Operators should publish which LUDs they support and keep TLS certificates current, because expired HTTPS breaks receives independently of Lightning channel health.

			BOLT12 does not obsolete LNURL overnight. HTTPS-based pay links remain useful where the receiver already runs a web server and the payer has no onion-message path. New deployments often expose both a Lightning address and a BOLT12 offer so payers can choose.

	== See also ==		== See also ==
Line 27:		Line 36:
	* [[BOLT12]]		* [[BOLT12]]
	* [[Lightning service provider]]		* [[Lightning service provider]]
			* [[Bech32]]

	== External links ==		== External links ==

	* https://github.com/lnurl/luds — LNURL specifications (LUDs)		* [https://github.com/lnurl/luds LNURL specifications (LUDs)]
	* https://github.com/lnurl/luds/blob/luds/06.md — LUD-06: pay request		* [https://github.com/lnurl/luds/blob/luds/01.md LUD-01: base LNURL encoding and decoding]
			* [https://github.com/lnurl/luds/blob/luds/03.md LUD-03: withdrawRequest]
			* [https://github.com/lnurl/luds/blob/luds/06.md LUD-06: pay request]
			* [https://github.com/lnurl/luds/blob/luds/16.md LUD-16: Lightning address]
			* [https://bolt12.org/ bolt12.org (offers compared with LNURL-style receives)]

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

NotATether: Add Status section and Security densify

2026-09-13T07:33:00Z

Add Status section and Security densify

← Older revision		Revision as of 07:33, 13 September 2026
Line 11:		Line 11:
	== Security ==		== Security ==

	Because LNURL is HTTP, operators must protect endpoints against SSRF-style callback abuse, open redirects, and invoice substitution. Wallets should pin expected domains when following Lightning address well-known paths and should reject cleartext HTTP on non-onion hosts. A compromised web server can steal withdrawals or issue unpaid invoices even if the Lightning node itself remains honest.		Because LNURL is HTTP, operators must protect endpoints against SSRF-style callback abuse, open redirects, and invoice substitution. Wallets should pin expected domains when following Lightning address well-known paths and should reject cleartext HTTP on non-onion hosts. A compromised web server can steal withdrawals or issue unpaid invoices even if the Lightning node itself remains honest. Withdraw endpoints should rate-limit k1 challenges and bind them to short lifetimes so stolen QR codes cannot drain funds indefinitely.

	Services that mint invoices on behalf of users should authenticate callbacks and bind amounts so a malicious webpage cannot substitute a higher invoice after the wallet has shown a quote.		Services that mint invoices on behalf of users should authenticate callbacks and bind amounts so a malicious webpage cannot substitute a higher invoice after the wallet has shown a quote.

			== Status ==

			LNURL remains widely deployed for Lightning addresses and withdraw kiosks even as [[BOLT12]] offers spread. Many wallets implement a subset of LUDs. Operators should publish which LUDs they support and keep TLS certificates current, because expired HTTPS breaks receives independently of Lightning channel health.

NotATether: Add Common LUDs and Security sections

2026-09-13T07:30:16Z

Add Common LUDs and Security sections

← Older revision		Revision as of 07:30, 13 September 2026
Line 1:		Line 1:
	'''LNURL''' is a family of HTTP protocols that let a Lightning wallet talk to a service without embedding a full BOLT 11 invoice in every QR code. A Bech32 string starting with <code>lnurl1</code> decodes to an HTTPS (or onion) endpoint. The wallet GETs that endpoint, receives JSON, and then pays an invoice, withdraws, authenticates, or requests a channel. The documents are LNURL specifications (LUDs), not BIPs. [[Lightning address]] (LUD-16) is a human-readable alias for LNURL-pay.		'''LNURL''' is a family of HTTP protocols that let a Lightning wallet talk to a service without embedding a full BOLT 11 invoice in every QR code. A Bech32 string starting with <code>lnurl1</code> decodes to an HTTPS (or onion) endpoint. The wallet GETs that endpoint, receives JSON, and then pays an invoice, withdraws, authenticates, or requests a channel. The documents are LNURL specifications (LUDs), not BIPs. [[Lightning address]] (LUD-16) is a human-readable alias for LNURL-pay.

			== Common LUDs ==

	Common LUDs include pay request (LUD-06), withdraw request, channel request, and authentication flows. The wallet presents a Bech32 <code>lnurl1...</code> string or a clear HTTPS URL. After decoding, it follows HTTP redirects only within limits defined by the LUD and expects JSON error objects when the service rejects the request. Services must use TLS on clearnet hosts. Tor onion endpoints are allowed where the LUD permits them.		Common LUDs include pay request (LUD-06), withdraw request, channel request, and authentication flows. The wallet presents a Bech32 <code>lnurl1...</code> string or a clear HTTPS URL. After decoding, it follows HTTP redirects only within limits defined by the LUD and expects JSON error objects when the service rejects the request. Services must use TLS on clearnet hosts. Tor onion endpoints are allowed where the LUD permits them.
Line 6:		Line 8:

	Withdraw flows (LUD-03 and related) let a service push a spendable invoice request to a wallet that scans an lnurl-withdraw QR. Channel-request LUDs ask a node to open inbound capacity toward the wallet, which overlaps operationally with LSP tooling even when the wire format differs. Authentication LUDs prove control of a Lightning node key over HTTPS without creating a long-lived account password on the service.		Withdraw flows (LUD-03 and related) let a service push a spendable invoice request to a wallet that scans an lnurl-withdraw QR. Channel-request LUDs ask a node to open inbound capacity toward the wallet, which overlaps operationally with LSP tooling even when the wire format differs. Authentication LUDs prove control of a Lightning node key over HTTPS without creating a long-lived account password on the service.

			== Security ==

	Because LNURL is HTTP, operators must protect endpoints against SSRF-style callback abuse, open redirects, and invoice substitution. Wallets should pin expected domains when following Lightning address well-known paths and should reject cleartext HTTP on non-onion hosts. A compromised web server can steal withdrawals or issue unpaid invoices even if the Lightning node itself remains honest.		Because LNURL is HTTP, operators must protect endpoints against SSRF-style callback abuse, open redirects, and invoice substitution. Wallets should pin expected domains when following Lightning address well-known paths and should reject cleartext HTTP on non-onion hosts. A compromised web server can steal withdrawals or issue unpaid invoices even if the Lightning node itself remains honest.

			Services that mint invoices on behalf of users should authenticate callbacks and bind amounts so a malicious webpage cannot substitute a higher invoice after the wallet has shown a quote.


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

NotATether: Expand See also links

2026-09-13T07:27:04Z

Expand See also links

← Older revision		Revision as of 07:27, 13 September 2026
Line 15:		Line 15:
	* [[BOLT11]]		* [[BOLT11]]
	* [[BOLT12]]		* [[BOLT12]]
			* [[Lightning service provider]]

	== External links ==		== External links ==

NotATether: Add deployment security caveats

2026-09-13T07:27:02Z

Add deployment security caveats

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

	Withdraw flows (LUD-03 and related) let a service push a spendable invoice request to a wallet that scans an lnurl-withdraw QR. Channel-request LUDs ask a node to open inbound capacity toward the wallet, which overlaps operationally with LSP tooling even when the wire format differs. Authentication LUDs prove control of a Lightning node key over HTTPS without creating a long-lived account password on the service.		Withdraw flows (LUD-03 and related) let a service push a spendable invoice request to a wallet that scans an lnurl-withdraw QR. Channel-request LUDs ask a node to open inbound capacity toward the wallet, which overlaps operationally with LSP tooling even when the wire format differs. Authentication LUDs prove control of a Lightning node key over HTTPS without creating a long-lived account password on the service.

			Because LNURL is HTTP, operators must protect endpoints against SSRF-style callback abuse, open redirects, and invoice substitution. Wallets should pin expected domains when following Lightning address well-known paths and should reject cleartext HTTP on non-onion hosts. A compromised web server can steal withdrawals or issue unpaid invoices even if the Lightning node itself remains honest.

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

NotATether: Add withdraw, channel-request, and auth LUDs

2026-09-13T07:27:01Z

Add withdraw, channel-request, and auth LUDs

← Older revision		Revision as of 07:27, 13 September 2026
Line 4:		Line 4:

	LNURL-pay returns a callback that mints a fresh [[BOLT11]] invoice for the chosen amount. That keeps QR codes short while still settling with ordinary Lightning HTLCs. [[BOLT12]] offers pursue a similar reusable-receive goal over onion messages instead of HTTPS. Wallets may support both. A Lightning address is only a LUD-16 alias that resolves to LNURL-pay.		LNURL-pay returns a callback that mints a fresh [[BOLT11]] invoice for the chosen amount. That keeps QR codes short while still settling with ordinary Lightning HTLCs. [[BOLT12]] offers pursue a similar reusable-receive goal over onion messages instead of HTTPS. Wallets may support both. A Lightning address is only a LUD-16 alias that resolves to LNURL-pay.

			Withdraw flows (LUD-03 and related) let a service push a spendable invoice request to a wallet that scans an lnurl-withdraw QR. Channel-request LUDs ask a node to open inbound capacity toward the wallet, which overlaps operationally with LSP tooling even when the wire format differs. Authentication LUDs prove control of a Lightning node key over HTTPS without creating a long-lived account password on the service.

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

NotATether: Expand See also links

2026-09-13T07:22:35Z

Expand See also links

← Older revision		Revision as of 07:22, 13 September 2026
Line 9:		Line 9:
	* [[Lightning address]]		* [[Lightning address]]
	* [[Lightning Network]]		* [[Lightning Network]]
			* [[BOLT11]]
			* [[BOLT12]]

	== External links ==		== External links ==

NotATether: Add BOLT11 settlement and BOLT12 contrast

2026-09-13T07:22:34Z

Add BOLT11 settlement and BOLT12 contrast

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

	Common LUDs include pay request (LUD-06), withdraw request, channel request, and authentication flows. The wallet presents a Bech32 <code>lnurl1...</code> string or a clear HTTPS URL. After decoding, it follows HTTP redirects only within limits defined by the LUD and expects JSON error objects when the service rejects the request. Services must use TLS on clearnet hosts. Tor onion endpoints are allowed where the LUD permits them.		Common LUDs include pay request (LUD-06), withdraw request, channel request, and authentication flows. The wallet presents a Bech32 <code>lnurl1...</code> string or a clear HTTPS URL. After decoding, it follows HTTP redirects only within limits defined by the LUD and expects JSON error objects when the service rejects the request. Services must use TLS on clearnet hosts. Tor onion endpoints are allowed where the LUD permits them.

			LNURL-pay returns a callback that mints a fresh [[BOLT11]] invoice for the chosen amount. That keeps QR codes short while still settling with ordinary Lightning HTLCs. [[BOLT12]] offers pursue a similar reusable-receive goal over onion messages instead of HTTPS. Wallets may support both. A Lightning address is only a LUD-16 alias that resolves to LNURL-pay.

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

NotATether: Add LUD flows and transport rules

2026-09-13T07:22:32Z

Add LUD flows and transport rules

← Older revision		Revision as of 07:22, 13 September 2026
Line 1:		Line 1:
	'''LNURL''' is a family of HTTP protocols that let a Lightning wallet talk to a service without embedding a full BOLT 11 invoice in every QR code. A Bech32 string starting with <code>lnurl1</code> decodes to an HTTPS (or onion) endpoint. The wallet GETs that endpoint, receives JSON, and then pays an invoice, withdraws, authenticates, or requests a channel. The documents are LNURL specifications (LUDs), not BIPs. [[Lightning address]] (LUD-16) is a human-readable alias for LNURL-pay.		'''LNURL''' is a family of HTTP protocols that let a Lightning wallet talk to a service without embedding a full BOLT 11 invoice in every QR code. A Bech32 string starting with <code>lnurl1</code> decodes to an HTTPS (or onion) endpoint. The wallet GETs that endpoint, receives JSON, and then pays an invoice, withdraws, authenticates, or requests a channel. The documents are LNURL specifications (LUDs), not BIPs. [[Lightning address]] (LUD-16) is a human-readable alias for LNURL-pay.

			Common LUDs include pay request (LUD-06), withdraw request, channel request, and authentication flows. The wallet presents a Bech32 <code>lnurl1...</code> string or a clear HTTPS URL. After decoding, it follows HTTP redirects only within limits defined by the LUD and expects JSON error objects when the service rejects the request. Services must use TLS on clearnet hosts. Tor onion endpoints are allowed where the LUD permits them.

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

NotATether: stub: LNURL HTTP layer over Lightning invoices (LUDs, not BIPs)

2026-09-03T06:44:18Z

stub: LNURL HTTP layer over Lightning invoices (LUDs, not BIPs)

New page

'''LNURL''' is a family of HTTP protocols that let a Lightning wallet talk to a service without embedding a full BOLT 11 invoice in every QR code. A Bech32 string starting with <code>lnurl1</code> decodes to an HTTPS (or onion) endpoint. The wallet GETs that endpoint, receives JSON, and then pays an invoice, withdraws, authenticates, or requests a channel. The documents are LNURL specifications (LUDs), not BIPs. [[Lightning address]] (LUD-16) is a human-readable alias for LNURL-pay.

== See also ==

* [[Lightning address]]
* [[Lightning Network]]

== External links ==

* https://github.com/lnurl/luds — LNURL specifications (LUDs)
* https://github.com/lnurl/luds/blob/luds/06.md — LUD-06: pay request

[[Category:Technical]]