Free · no account · takes a minuteBIP 352 + BIP 353 + BOLT 12 · free · no accountBIP 352 v1.1.1 · BIP 353 · BOLT 12 · DNSSEC signed · self-hostable · no account · no logs
Get paid in bitcoin,
by a name.
- Handing out one address means everyone can see what you are paid.
- Hand out a name instead. Every payment still gets its own address.
- Lightning or on-chain: the sender's wallet picks, you do nothing.
- A new address per payment is settled practice, and your wallet already does it.
- Handing that address to a payer is the part that is not solved. BIP 352 puts it plainly: interaction “is often infeasible and in many cases undesirable”.
- The usual workarounds are reusing one address, or sharing an xpub (the worst option of all: it exposes every address and the balance, permanently).
- A silent payment address is a fixed string that never means a fixed address, and a payment name makes it readable.
- The same record can carry a BOLT 12 offer alongside it, so one name pays on Lightning or on-chain and the sender's wallet decides which. Both ride in one BIP 321 URI as
spandlno. An offer has no checksum, so it is optional and the address stays the leg that always works. - The cost is real and lands on you: your wallet has to scan rather than be told. A year of chain is three and a half minutes on a laptop and an open research problem on a phone.
- Nothing here needs us. Publish the same record on a domain you own and this site becomes a demo you looked at once.
The trade§ 01 · The trade you make today
Four ways to get paid twice by the same person
Nobody disagrees about the goal. A new address for every payment, which your wallet has done by default for years. The argument is only ever about what getting that address to the payer costs you.
The first row is what everyone agrees you should do. The middle two are what people actually do, because the first row is work. The last row is the first row without the work, and that is the entire pitch. The row below it is the same thing with us removed, which is strictly better and is what we would pick.
Craig Raw, who builds Sparrow Wallet, put the consequence in one line: “address reuse is currently near 70% because it’s difficult to share/validate a new address for every payment.” Read that as a measurement of how inconvenient the first row is, not as an accusation about wallets. Wallets rotate. It is the handing over that breaks down.
The second row§ 02 · The second row, in detail
What reusing one address actually looks like
This is not what your wallet does. It is what happens to the one address you put on a website and left there, once more than one person has paid it.
Every payer who saved that address can pull this up, and so can everyone else. A payment name gives them something to save that never resolves to the same place twice, so there is no single page like this to load.
The address is the example one from the bech32 specification and the figures are illustrative. Every row is a field a real explorer prints for a real reused address, which is the only claim being made.
And here is the same thing across a whole block
Every square is a bitcoin payment and seventeen of them are yours. Flip between one reused address and a payment name, and watch what a stranger can pick out.
One address, published and left up. Your wallet would have given each payer a different address. Nobody was there to hand one over, so they all paid the same string, and joining them up is now the easy part of chain analysis.
§ 03 · The two standards
Two bitcoin standards, no company in the middle of your money
Neither of these is ours. Both are published bitcoin improvement proposals with reference implementations and test vectors. We wrote the small boring bit that joins them.
BIP 352 · Silent Payments
The address that is never the same twice
Your wallet publishes one address built from two keys. When somebody pays it, their wallet combines it with the public keys of the coins they are spending and works out a fresh address that only you can spend from. No extra bytes on the chain, no message to you, no round trip.
BIP 353 · DNS Payment Instructions
The name that resolves to it
A signed DNS record, the same machinery that decides where your email goes, saying this name means that address. The signature chain runs to the DNS root key, and a wallet checks it itself rather than taking a resolver’s word for it.
How to do it§ 04 · How to do it
Three steps, once
Make the address
In your wallet, create a silent payment address. In Sparrow it is a wallet with policy
type Single Signature SP. Cake Wallet and Dana Wallet can do it too. It starts
with sp1q.
Claim a name
Paste that address into the form below and pick a name. No account, no email address, no confirmation link. You get a recovery secret, and you keep it.
Hand out the name
Put you@silentpayments.net on your site, your invoices, your profile.
Anyone with a wallet that supports it can pay you, over and over, and nothing adds up.
Which wallets can do this
You need one of these three to receive. They are free, and any of them can also pay someone else’s name.
Others can pay a name but cannot receive to one yet, among them BitBox02, Wasabi, Nunchuk and BlueWallet. No exchange supports it, so withdraw to your own wallet first.
Wallets that can do this today
No exchange supports this. Withdraw to your own wallet first.
That list is short and we are not going to dress it up. Full detail, with versions and dates, is on the how it works page.
§ 05 · State, right now
Do not take our word for any of this
Read live from the two endpoints below, on your request, not baked in when the page was written. If they disagree with what you fetch yourself, trust yours.
the same numbers, without our JavaScript:
curl -s https://silentpayments.net/api/health
curl -s https://silentpayments.net/api/log
curl -s https://silentpayments.net/api/log/verify
# and what DNS says, validated to the root, with nothing of ours involved
delv TXT <name>.user._bitcoin-payment.silentpayments.net
The chain check is computed by the same server that would be lying to you, which is why it is worth exactly as much as your own copy of the log and no more. Fetch it on a schedule and diff it. Four lines of cron, and you never have to trust the word above.
§ 06 · Before you use ours
Do not trust us. Run it yourself.
We run this domain, so we control what your name resolves to. A dishonest operator could aim it at their own address and every later payment would go there, with a perfectly valid signature, invisibly. That is not a hypothetical risk we are managing, it is a structural fact about naming things.
The version with nobody in the middle
Publish the same record on a domain you already control. Our StartOS package prints exactly what to add. That is strictly better than trusting us, it costs you one DNS record, and we would rather say so than sell you something.
# what you would publish, on your own domain you.user._bitcoin-payment.example.com. IN TXT "bitcoin:?sp=sp1q…" # then make sure the zone is DNSSEC signed, and you are done
If you use ours anyway
Every claim and every change goes into a public, append only change log, hash chained so an entry cannot be edited or removed without breaking every entry after it. Fetch it on a schedule, keep your own copy, and compare. You do not need our permission and you do not need our cooperation.
And because we run the server, we could in principle rebuild that whole log from scratch and it would still look perfect. So every six hours we publish its current fingerprint to nostr relays run by strangers. Once that has happened a few hundred times, a rewritten history no longer matches what those strangers already hold, and we cannot reach their copies.
Checkpoints are regular nostr events, deliberately not replaceable ones, signed by
npub1wc5were3y63h4nwcckdrw72gceh4kgz8eg7fz0zrk2xufr4dx9xqlvmcx8. Each
carries the chain head and the entry count in tags. The publisher refuses to sign a
chain that does not verify, so our signature can never land on a broken log. The list
at /api/log/checkpoints is ours and proves nothing: go and read the
events on a relay instead.
curl https://silentpayments.net/api/log
curl https://silentpayments.net/api/log/verify
# the fingerprints we published where we cannot reach them:
curl https://silentpayments.net/api/log/checkpoints
delv TXT you.user._bitcoin-payment.silentpayments.net
And the thing nobody else will tell you
This zone is DNSSEC signed by Cloudflare, and Cloudflare signs it with a key it does not
keep to us. Checked today: our delegation signer record is key tag 2371, and
so is twelve.cash, the other payment name service in this small field. Same key, two
different operators. Cloudflare, our registrar, the .net registry and ICANN each sit above
us in that chain. BIP 353 narrows who can lie to you. It does not get the number to zero,
and the full list is here.
Claim§ 07 · Claim
Claim a name
Free. No account, no email address, no confirmation link. Already have a name? Change what it pays.
Done
Your payment name is
Keep this recovery secret. It is the only way to change or remove your name later. We do not store a copy, so if you lose it we cannot help you, and neither can anyone who compels us.
Your card. Screenshot it, send it, print it.
This is your payment record itself, not a link to us. A wallet that scans it reads your silent payment address and, if you gave them, your Lightning offer and Cashu request, and picks. Nothing is looked up and nobody is asked.
A shared card is frozen at the moment you made it. Change your address later and old copies still point at the old one. The name printed under the code does not have that problem, which is the other reason it is there.
Or claim it without any of this
The form above is a convenience. The endpoint is the interface, it takes JSON, and it returns the secret exactly once.
curl -s https://silentpayments.net/api/check?name=alice
curl -s -X POST https://silentpayments.net/api/claim \
-H 'content-type: application/json' \
-d '{"username":"alice","address":"sp1q…"}'
# the record this creates, which you can verify a second later:
# alice.user._bitcoin-payment.silentpayments.net TXT "bitcoin:?sp=sp1q…"
Later, PUT the same path with the secret as a bearer token to move it, or
DELETE to give it up. We keep a hash of the secret and never the secret, so
losing it means nobody can help you, including anyone who compels us.
Or own it with a key instead of a secret
Sign the request and there is no secret to keep. Send a NIP-98 event, kind 27235, carrying
the exact URL, the method, and a hash of the body you actually send. We take the signer's
public key out of it and record that as the owner. A claim that arrives signed is never
issued a secret at all, and every later change has to be signed by the same key or it comes
back 403.
This is what the StartOS package does, and the reason is worth stating: a password would have to sit on the machine making the requests anyway, so it buys nothing over a key already sitting there, and it adds something to lose. The format is borrowed from nostr. Nothing about your name touches a relay.
One thing worth knowing
We run this domain, which means we could point your name somewhere else. Every change we make is written to a public log that cannot be quietly edited, and you can always read the honest version or run the whole thing yourself.
Keep reading
Why it is better
The old way and the new way, side by side, in pictures.
BIP 352How it works
The full derivation with real test vector numbers, drawn one step at a time.
BIP 353Payment names
The record, the signature chain to the root, and exactly what it does not prove.
FreeClaim a name
No account, no email address. One form and one signed record.
PublicChange log
Every name we issue or change, written where you can check it.