Free · no account · takes a minuteBIP 352 + BIP 353 · free · no accountBIP 352 v1.1.1 · BIP 353 · self-hostable · no account · no logs
Replace your bitcoin address
with a name.
- Your wallet already makes a fresh address for every payment.
- Getting one to whoever is paying you means being there, every single time.
- So people reuse one address, or hand over an xpub (the worst option of all).
- A payment name is published once, and still gives every payment its own address.
- 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 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.
Wallets that can do this today
Desktop. Also resolves payment names and checks the signature itself.
Phone. The only one doing full signature checking on names.
Still experimental. Built specifically for this.
Hardware. Can pay one, cannot receive to one yet.
Desktop.
Phone. Both can pay one.
Nothing shipped to users yet. Three pull requests still open.
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.
curl https://silentpayments.net/api/log curl https://silentpayments.net/api/log/verify 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.
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.
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.
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.