A Name Is a Pointer, Not a Key: What Lightning Addresses and ₿-Names Actually Trust

A string like alice@example.org is the friendliest thing in Lightning. You can say it out loud, print it on a sticker, put it in a profile bio. It is also the least self-verifying thing in the stack. A Bitcoin address or a BOLT-12 offer is the destination: it carries the key. A human-readable name carries no key at all. It is a question your wallet asks someone else, and the answer is only as good as whoever answers.

Thesis, stated once: a human-readable payment name is a pointer, and the security question is not "is this name correct?" but "who can change what the pointer resolves to, and can my wallet check their answer?" Two live specifications answer that very differently. The Lightning Address (LUD-16) asks a live web server every time. BIP 353 asks the DNS for a signed record that can be checked against a single root. For receive-only tip jars, the difference decides who can quietly redirect a thank-you, and who learns that someone sent one.

This follows the receive-only primer, the BOLT-12 offers note, and what a preimage proves. Those covered the payment objects. This one covers the name in front of them.

Mechanism one: the Lightning Address is a live HTTPS conversation

LUD-16 is short and blunt. On seeing username@domain, the wallet "makes a GET request to https://<domain>/.well-known/lnurlp/<username>" (plain http:// for an onion domain), and the response "MUST be the same as in LUD-06, step 3, and the flow is the same."

LUD-06 then runs a two-step dialogue. The server returns a callback URL, minimum and maximum amounts, and a metadata string. The payer picks an amount, the wallet calls the callback, and the server hands back pr, a freshly minted BOLT-11 invoice. The wallet's mandated check is narrow: it "verifies that amount in provided invoice equals the amount previously specified by user," then pays the invoice: "no additional user confirmation is required at this point."

Read what is not in that list. Nothing ties the invoice's signing node to the name. Nothing in LUD-16 says the node must belong to alice. The TLS certificate proves you reached the server for example.org. It does not prove that server is honest about who alice is, and it does not survive a compromised host, a hijacked domain, a misissued certificate, or an operator who simply decides to answer differently. Whoever controls that web server at the moment of payment chooses which node gets paid, on every single payment.

There is a second cost. Each lookup is an HTTP request from the payer's device (or its proxy) to the recipient's host. The host learns an IP address, a timestamp, and an amount request tied to a name, before a single satoshi moves.

Mechanism two: BIP 353 puts a signed record in the DNS

BIP 353, "DNS Payment Instructions," stores a bitcoin: URI (BIP 21 style) in a TXT record at user.user._bitcoin-payment.domain. Its rules are strict on purpose:

• "All payment instructions MUST be DNSSEC-signed."
• Clients "MUST fully validate DNSSEC signatures leading to the DNS root" and "MUST NOT trust a remote resolver to validate DNSSEC records on their behalf."
• Weak signatures (SHA-1, RSA under 1024 bits) are refused, and two competing bitcoin: records at one label make the whole answer invalid.
• Caching may not outlast the signed TTLs in the chain.

The record usually holds an offer (bitcoin:?lno=…), so the name resolves to something that does carry a key. The BOLT-12 spec then closes the loop: a payer who got the offer through BIP 353 "MUST include invreq_bip_353_name" in its invoice request, so one wildcard offer can serve many users while the receiving node still knows which name was meant.

The proof is portable. BIP 353 adopts the serialized DNSSEC authentication chain from RFC 9102 and defines a PSBT field (PSBT_OUT_DNSSEC_PROOF) so a hardware signer can check the chain itself and display ₿alice@example.org only "if verification succeeds." The ₿ prefix is a display convention for "verified name," and the spec tells wallets to copy the underlying URI rather than the name, so the next app doesn't have to look it up again.

And the lookup can be private. bLIP-32 defines dnssec_query and dnssec_proof onion messages: the payer asks a resolver node over Lightning's onion routing, gets back a proof, and "MUST validate all DNSSEC signatures" itself. The resolver can be lazy or hostile; it cannot forge the chain. Neither the recipient's host nor the resolver learns the payer's IP from the lookup.

What changed, and what didn't

Line the two up by trust, not by convenience.

Who can redirect payment. With LUD-16, the web server operator, any attacker who owns it, or anyone who can obtain a certificate for the domain, live and per payment. With BIP 353, someone who controls the domain's DNS signing keys or a parent zone's. That is still a real authority: registrars, registries, and the root sit above you. But the attack now has to produce a signature, and that signature is checkable evidence, not a server's word.

Who learns about the payment. LUD-16 tells the recipient's host about every lookup. BIP 353 with bLIP-32 can route the lookup through onion messages so nobody in the middle sees the whole picture. BIP 353 even says wallets "SHOULD NOT" fall back to Lightning Address resolution once the DNS scheme is broadly deployed, "to avoid leaking sender IP address information."

What a name never fixes. A name is still a name. Look-alike domains and Unicode homographs still work against tired eyes (BIP 353 requires precautions or raw punycode display for non-ASCII names). A domain you rent can be suspended. BIP 353 itself notes that user enumeration gets "marginally more practical" when valid users live in public DNS. And none of this touches the earlier notes: the offer still needs inbound liquidity, and the preimage still proves settlement, not identity.

Why the pointer question travels

Human-readable names are where payment systems quietly re-centralize. A tip jar that depends on one web host inherits that host's jurisdiction, uptime, and willingness to keep answering. That is a dependency worth naming anywhere a platform, a payment processor, or a government has ever leaned on an intermediary to stop money reaching a journalist, an organizer, or an open-source maintainer. Moving the name into signed DNS doesn't remove authority, since ICANN-rooted DNS is a hierarchy with its own pressure points. It changes the shape: fewer live chokepoints per payment, and a redirect that leaves cryptographic evidence instead of a silent swap.

The practical habit is simple and global. When a wallet shows you a name, ask whether it is showing you something it verified (₿ and a checked chain), something it fetched (an HTTPS answer), or something it assumed. When you publish a name, know which of those your payers' wallets will do.

What this is not

This note does not rank wallets, Lightning service providers, domain registrars, or hosts, and it does not recommend running any particular service. It is not custody advice, and it does not discuss prices, yields, swaps, or trading. It does not claim BIP 353 or bLIP-32 are supported everywhere; check what the software in front of you actually validates. It does not call DNSSEC censorship-proof or the Lightning Address worthless. LUD-16 is widely deployed and fine for many low-stakes uses, and DNSSEC has its own operators and failure modes. And it does not cover on-chain addresses in BIP 353 records, which the spec asks to be rotated often or left out.

Related on CryptoDecentral

• Self-custody & wallets pillar
• Privacy pillar
• Receive-Only Lightning Is Not a Merchant Stack
• A BOLT-12 Offer Is Not a Reusable Invoice
• A Preimage Is Not a Receipt

Further reading (primary)

• LUD-16 — Paying to static internet identifiers
• LUD-06 — payRequest base spec
• BIP 353 — DNS Payment Instructions
• bLIP-32 — Onion Message DNS Resolution
• BOLT #12 — Offers (invreq_bip_353_name)
• RFC 9102 — TLS DNSSEC Chain Extension (serialized authentication chains)