What are Silent Payments<\/h2>\n
The concept of Silent Payments was described<\/a> by developer Ruben Somsen in March 2022. A year later he standardised it in Bitcoin improvement proposal BIP-352<\/a> together with Josie Bake.<\/p>\n The main goal of Silent Payments is to avoid address reuse. The protocol allows new public keys to be generated for each transaction, improving UX<\/span> while maintaining a high level of privacy.<\/p>\n \n“Generating a new address is a crucial aspect of maintaining privacy. However, this requires secure communication between the sender and the receiver, so that the receiver can provide an unused address, multiple addresses, or a method that allows the sender to generate addresses, e.g. xpub,” BIP-352 says.<\/cite><\/p><\/blockquote>\n Silent Payments solve this: they provide static addresses that can be reused. Only senders and recipients can identify the transactions.<\/p>\n If an organisation collects funds on a website, nobody can determine who donated or how much bitcoin they contributed. Support for the protocol will also improve the privacy of crypto-exchange customers: platforms typically assign a single deposit address.<\/p>\n \n“If you have had to receive bitcoin several times from the same person, you face a simple choice: generate a new address every time (and somehow communicate it) or ask the sender to reuse the same address? If you generate a new address each time, you will have to pass it to the sender and hope they copy it correctly. If you decide that they should reuse one address, you will compromise the privacy of both participants in the transaction,” says the Silent Payments<\/a> website.<\/cite><\/p><\/blockquote>\n Implementing BIP-352 requires no consensus changes, so any Bitcoin wallet can adopt it. Silent-payment addresses have the sp1 <\/strong>prefix and look like this:<\/p>\n The recipient publishes such an address without interacting with the sender, who then selects one or more UTXOs. At that point the protocol generates a new Taproot address to receive the funds. It uses the sender\u2019s private key, the recipient\u2019s sp1 address and a shared secret created via ECDH<\/a> (Elliptic Curve Diffie\u2013Hellman).<\/p>\n The recipient has two key pairs:<\/p>\n The main drawback is the need for continuous network scanning. It demands more computation and bandwidth than, say, using an Electrum Server.<\/p>\n \n“You can have a full node at home; in that case the UX of silent payments will be no different\u2014there are no compromises here, since roughly as many resources will be spent on ECDH computation as on signature verification. Your node is already tracking all transactions, and now the protocol will require one more signature verification to check for a silent payment,” said<\/a> Josie Bake.<\/cite><\/p><\/blockquote>\n A Blue Wallet mobile user (or any client that can connect to their own node) can provide the node with the scan key.<\/p>\n \n“That is the ideal option. If you cannot run a full node, then in my opinion you still cannot use mobile wallets privately, although there are proposals like BIP-158<\/a>, but they have not reached mass adoption. Nevertheless, the Cake Wallet developers proposed an interesting solution, essentially a fork of electrs<\/span>, which scans the blockchain for silent payments. When the mobile wallet connects to the server, it simply returns all unspent SP in the blocks since the last scan. In this case the server knows only about the data request,” he concluded.<\/cite><\/p><\/blockquote>\n A key advantage of Silent Payments is that such transactions are indistinguishable on-chain. A third party cannot link them to a specific sp1 address or even tell that the protocol was used.<\/p>\n As of October 2024 the developers of Silent Payments highlight<\/a> two competing approaches:<\/p>\n Example for BIP-47<\/strong>. Bob gives Alice a reusable payment code, and she sends him bitcoin. Alice\u2019s wallet generates a unique shared secret by combining:<\/p>\n The wallet encrypts this data and inserts it into the OP_RETURN field of a notification transaction. The code is visible on the blockchain, but only Bob can compute the addresses used for its generation. All subsequent payments by Alice will be known only to him.<\/p>\n This approach eases scanning but also reveals the use of PayNym.<\/p>\n Example for BIP-351<\/strong>. Each time Alice sends funds to Bob, her wallet combines the public key from Bob\u2019s payment code with a shared secret. The protocol generates a unique notification code for OP_RETURN, used once.<\/p>\n An outside observer will not see links between transactions, but will note the use of the protocol.<\/p>\n Silent Payments improve UX and privacy on the Bitcoin network by removing the need to pass new addresses for each transaction.<\/p>\n In the view of the Mixer.Money<\/a> team, they can increase the anonymity of Bitcoin users, but will require broader community adoption:<\/p>\nHow they work<\/h2>\n
sp1qqvvnsd3xnjpmx8hnn2ua0e9sllm34t9jydf8qfesgc7nhdxgzksjwqlrxx37nfzsg6rure5vwa92fksd6f5a6rk05kr07twhd55u3ahquy2v7t6s<\/em>\n<\/code><\/pre>\n\n
![\"image1-601\"](\"https:\/\/forklog.com\/wp-content\/uploads\/image1-601.webp\")
Comparison with other approaches<\/h2>\n
\n
\n
Conclusions<\/h2>\n