In a BitcoinTalk thread, participants discussed the idea of Silent Payments. It addresses a familiar problem: if you post a single Bitcoin address for donations or payments, anyone can look up the blockchain and see which payments were sent to that address.
Silent Payments let you publish a special code instead of a regular receiving address. The sender uses it to create a separate address for their payment. The recipient doesn’t need to contact the sender in advance, and it becomes harder for outside observers to link different payments to the same person. Ruben Somsen proposed the idea in 2022.
How it works—with no formulas
Imagine Alice wants to accept Bitcoin, perhaps for donations. She publishes her Silent Payments code. Bob uses that code together with information from his coins to create a new, one-time address. He sends bitcoin to that address.
The key feature is that a new receiving address is generated for every payment. Alice’s wallet can detect the transfer and spend the funds, while Bob doesn’t need to ask her for a separate address. The protocol uses two keys: one helps the wallet find payments, and the other lets it spend the funds it receives.
To an outside observer, the payment looks like an ordinary Taproot output. There’s no special marker in the transaction saying, “This is a Silent Payment,” or directly pointing to Alice’s published code. That makes it harder to link payments to her, but the transaction itself is not invisible.
What is hidden—and what isn’t
Silent Payments help obscure the obvious connection between a recipient’s shared code and the individual addresses used for incoming payments. For example, visitors to a website can’t simply look up one public address and see every payment sent to it.
But the blockchain remains public. Transactions and their outputs are still visible. So it would be wrong to say that nobody except the sender and recipient can know a payment took place. More precisely, it becomes harder for an observer to tell which output belongs to a Silent Payments recipient, or whether different payments are connected.
This is not universal protection against identification. If someone links their payments to their name, shares other identifying information, or uses a service that knows their identity, this technology alone won’t prevent those disclosures.
The trade-off: finding payments
A regular wallet has a list of addresses it generated in advance and can check. With Silent Payments, the recipient’s wallet must scan eligible transactions and check whether any of their outputs were created for it. Finding incoming payments is therefore more complicated than with a regular, known-in-advance address. In the BitcoinTalk discussion, participants specifically asked how much load this puts on a wallet and whether you have to run your own node.
The technical details matter: a wallet doesn’t have to recalculate every operation on the network indiscriminately. The specification defines conditions for selecting transactions to check. Still, scanning remains one of the main trade-offs of Silent Payments.
What the forum discussion brought up
The original thread mixed several different questions: whether this scheme improves privacy, how difficult it is to implement, and whether it’s fair to call it an improvement in Bitcoin’s fungibility. The last point prompted debate, but for explaining the idea, it’s simpler to talk about privacy and making links harder to analyze.
The main takeaway is that Silent Payments let you use one public code to receive payments while creating separate addresses for each one. This can make it harder for observers to link incoming payments, but the recipient’s wallet has to search for them on the blockchain. The technology doesn’t hide the existence of transactions and doesn’t guarantee complete anonymity. That balance between added privacy and more complicated payment discovery is what makes the idea interesting to discuss.
Silent Payments let you publish a special code instead of a regular receiving address. The sender uses it to create a separate address for their payment. The recipient doesn’t need to contact the sender in advance, and it becomes harder for outside observers to link different payments to the same person. Ruben Somsen proposed the idea in 2022.
How it works—with no formulas
Imagine Alice wants to accept Bitcoin, perhaps for donations. She publishes her Silent Payments code. Bob uses that code together with information from his coins to create a new, one-time address. He sends bitcoin to that address.
The key feature is that a new receiving address is generated for every payment. Alice’s wallet can detect the transfer and spend the funds, while Bob doesn’t need to ask her for a separate address. The protocol uses two keys: one helps the wallet find payments, and the other lets it spend the funds it receives.
To an outside observer, the payment looks like an ordinary Taproot output. There’s no special marker in the transaction saying, “This is a Silent Payment,” or directly pointing to Alice’s published code. That makes it harder to link payments to her, but the transaction itself is not invisible.
What is hidden—and what isn’t
Silent Payments help obscure the obvious connection between a recipient’s shared code and the individual addresses used for incoming payments. For example, visitors to a website can’t simply look up one public address and see every payment sent to it.
But the blockchain remains public. Transactions and their outputs are still visible. So it would be wrong to say that nobody except the sender and recipient can know a payment took place. More precisely, it becomes harder for an observer to tell which output belongs to a Silent Payments recipient, or whether different payments are connected.
This is not universal protection against identification. If someone links their payments to their name, shares other identifying information, or uses a service that knows their identity, this technology alone won’t prevent those disclosures.
The trade-off: finding payments
A regular wallet has a list of addresses it generated in advance and can check. With Silent Payments, the recipient’s wallet must scan eligible transactions and check whether any of their outputs were created for it. Finding incoming payments is therefore more complicated than with a regular, known-in-advance address. In the BitcoinTalk discussion, participants specifically asked how much load this puts on a wallet and whether you have to run your own node.
The technical details matter: a wallet doesn’t have to recalculate every operation on the network indiscriminately. The specification defines conditions for selecting transactions to check. Still, scanning remains one of the main trade-offs of Silent Payments.
What the forum discussion brought up
The original thread mixed several different questions: whether this scheme improves privacy, how difficult it is to implement, and whether it’s fair to call it an improvement in Bitcoin’s fungibility. The last point prompted debate, but for explaining the idea, it’s simpler to talk about privacy and making links harder to analyze.
The main takeaway is that Silent Payments let you use one public code to receive payments while creating separate addresses for each one. This can make it harder for observers to link incoming payments, but the recipient’s wallet has to search for them on the blockchain. The technology doesn’t hide the existence of transactions and doesn’t guarantee complete anonymity. That balance between added privacy and more complicated payment discovery is what makes the idea interesting to discuss.