--- title: "silentpayments.net · one name, a new bitcoin address every payment" description: "Your wallet already makes a new address for every payment. A payment name lets you publish something once and keep it, without handing out a fresh address every time. Built on BIP 352 and BIP 353." url: "https://silentpayments.net/" language: "en" --- > Your wallet already makes a new address for every payment. A payment name lets you publish something once and keep it, without handing out a fresh address every time. Built on BIP 352 and BIP 353. _This page has three detail levels in HTML: Easy, Advanced and Cypherpunk._ _This twin carries the Advanced and Cypherpunk text, which is the complete version._ BIP 352 + BIP 353 · free · no account BIP 352 v1.1.1 · BIP 353 · self-hostable · no account · no logs # Replace your bitcoin address with a name. - 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. Claim your name [See the cryptography](https://silentpayments.net/how) what you hand out today bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh - Impossible to read out, or write on anything - Only rotates if you are there to hand out a new one ↓ what you could hand out alice@silentpayments.net - You can say it down a phone, and put it on a card - Still a brand new address for every single payment § 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 wayprivacywhat it costs you A fresh address each timemessage them, or show a QR code good you, every single time Reuse one addressa donate link, an invoice footer, a profile gone, and permanently nothing, which is exactly why it happens Hand over an xpub (the worst of the three)so they can generate their own they see every address and balance, forever nothing after setup A payment namepublish it once and forget it a new address every payment nothing Your own domain, your own scannerthe same two standards, nobody in the middle a new address every payment one DNS record, and a node you already run 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. § 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. any block explorer · no login · no permission ⚲bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh Holding right now2.41983047 BTC Paid to them, ever11.90420000 BTC Payments received147 First one2 April 2019 Most recent19 August 2026 Who paid them147 counterparties, clusterable Where it went afterwardsfollowable 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. Published addressPayment name linkable to you: 17 of 17 Show what only your wallet sees **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 > **Diagram.** A silent payment address plus the sender's own transaction inputs derive a fresh output key for every payment 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. [Read the derivation, with real numbers](https://silentpayments.net/how) #### BIP 353 · DNS Payment Instructions ### The name that resolves to it > **Diagram.** A human readable name resolves through a DNSSEC signed TXT record to a silent payment address 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. [Read how the signature chain works](https://silentpayments.net/names) § 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 Sparrow receivesend Desktop. Also resolves payment names and checks the signature itself. Cake Wallet receivesend Phone. The only one doing full signature checking on names. Dana Wallet receivesend Still experimental. Built specifically for this. BitBox02 sendno receive Hardware. Can pay one, cannot receive to one yet. Wasabi sendno receive Desktop. Nunchuk · BlueWallet sendno receive Phone. Both can pay one. Bitcoin Core neither Nothing shipped to users yet. Three pull requests still open. Your exchange neither 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](https://silentpayments.net/how#wallets). § 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. names issuedreading… records in the zonereading… log entriesreading… hash chainreading… 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 .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](https://github.com/bitsagarob/payment-name-startos) 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](https://silentpayments.net/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](https://silentpayments.net/better#trust). § 07 · Claim ## Claim a name Free. No account, no email address, no confirmation link. Name you want @silentpayments.net Lowercase letters, digits, dot, dash, underscore. Five characters or more for now, because short names are the squattable ones and there is no way to un-give a name. Your silent payment address The one from your wallet, starting `sp1q`. We cannot work it out for you, and that is the point. In Sparrow, make a wallet with policy type _Single Signature SP_ and copy it from the Receive tab. Check if it is freeClaim it ### 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. `` [See it in the public change log](https://silentpayments.net/log) #### 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. Keep reading The short version ### Why it is better The old way and the new way, side by side, in pictures. BIP 352 ### How it works The full derivation with real test vector numbers, drawn one step at a time. BIP 353 ### Payment names The record, the signature chain to the root, and exactly what it does not prove.