Silent Payments Make Bitcoin More Private
This is an opinion editorial by Seth For Privacy, a privacy advocate and host of the “Opt Out Podcast.”
One of the most basic keys to improving your privacy on Bitcoin has long been avoiding the re-use of addresses for multiple payments. But while doing so may seem simple these days, with most wallets automatically generating new addresses for each payment, what do you do when you need to simply accept payments repeatedly, from multiple people, or without complex infrastructure in place?
This is where the concept of a “reusable payment code,” sometimes called a “Stealth Address,” comes into play, enabling simple static addresses to be used for repeat payments while preserving on-chain privacy by making it harder to link payments together.
Why Does Bitcoin Need Reusable Payment Codes?
While it is currently possible to use more complex infrastructure, like the payment processing system offered by BTCPay Server, to accept donations or payments without re-using addresses, the need to set up an entirely separate server alongside a Bitcoin node makes the more simple use cases for receiving payments far too complex for most people.
If you simply want to be able to run a donation campaign, let friends send you bitcoin repeatedly, or let others tip you for your work, right now you generally either have to run complex infrastructure or have extremely poor privacy by using a static Bitcoin address.
Enter reusable payment codes, a concept that dates back to 2015 with the original stealth address BIP created by Peter Todd. While the original proposal never officially became a proposed BIP (despite being given the BIP number 63), a successor, BIP47, has started to see an increase of usage in recent years in wallets like Samourai Wallet and Sparrow Wallet, two excellent and privacy-centric Bitcoin wallets.
How Did We End Up With Silent Payments?
Unfortunately, BIP47 has one serious drawback: in order for the recipient to know they’re getting a transaction (and thus be able to spend it!), the sender has to create a special transaction — called a “notification transaction” — on-chain in order for the recipient to find their funds, in addition to sending their intended payment itself separately. While this only has to be done once per sender and is the core feature that enables light wallet usage for BIP47, this has serious fee, scaling and, most importantly for adversarial use cases for reusable payment codes, privacy implications.
Thankfully, Ruben Somsen dropped an extremely promising proposal in the form of a GitHub Gist on March 13, 2022, titled “Silent Payments,” where the key tradeoff is shifted from a notification transaction (with problematic results, as we’ll get into later) to a more involved scanning process on the recipients side. Silent Payments is another iteration on the original “Stealth Address” proposal, but takes advantage of many advances in Bitcoin scanning, script types (i.e., Taproot), and some nifty tricks.
If you want to dive more deeply into the origins and proposed function of Silent Payments, I’d highly recommend reading the excellent article by Shinobi, “Bitcoin Silent Payments And Secret Blinding Keys,” but we’ll walk through it in a very simplified way below as well.
How Silent Payments Work, Simplified
Before we dive too deeply into why I’m excited about Silent Payments, it is important that you understand at a very simplistic level how Silent Payments work for both the sender and recipient.
For The Sender
When someone wants to send funds to a Silent Payment address, in practice all they’ll need to do is scan or copy/paste the payment code into their favorite wallet (assuming it is supported), and send the payment as usual. But what exactly is happening behind the scenes?
When the sender enters the Silent Payment address into their wallet, their wallet will combine three keys to create a unique, one-time address that only the intended recipient can spend from. This unique address is created by combining the public key (or “address,” in layman’s terms) of one of the inputs that the sender wants to spend to the recipient, the public key of the recipient (contained in the Silent Payment address), and a “shared secret” key the sender generates that only the sender and recipient know. Thanks to something known as the “commutative” property in cryptography, the sender can combine these keys but cannot spend from the resulting address, as they don’t know the recipient’s private key (of course).
When the sender combines these three keys, they generate a new public key (or address) and send the intended funds to this new address that only the recipient controls. On chain, this transaction looks exactly like any other spend of a similar type and script, and there is no distinguishing factor that makes it apparent to outside observers that a Silent Payment was used, much less who owns the Silent Payment address.
For The Recipient
Once we get to the recipient, we see where the main trade off comes in for Silent Payments. If you recall that the sender uses the public key of an input being spent to generate the unique, one-time address, you may be asking yourself, “How does the recipient know they’ve been sent funds, and to what address?”
This question is at the heart of the Silent Payments proposal, and means that recipients have to do relatively-costly scanning of every transaction on the Bitcoin blockchain after they created their Silent Payment address. This scanning enables the recipient to see if an input public key plus a generated shared secret using their Silent Payment address and an output public key in any transaction properly matches their private keys, and add it to their wallet if so.
This scanning is quite costly compared to standard Bitcoin wallet scanning, as you can’t simply compare a list of derived addresses from your wallet with a list of transaction outputs to get your wallet balance. Instead, you have to go through every transaction, compute the shared secret for each input and compare to the outputs, something that Somsen compared to “checking every signature twice, instead of once” in “Bitcoin Explained.”
Ideally, this scanning will be done during the initial block download (the first time you sync the entire Bitcoin blockchain) or a standalone piece of software that offloads scanning from your wallet and Bitcoin node.
Optimizing Scan Time For The Recipient
While this scanning is quite computationally expensive, it can be made more efficient without sacrificing privacy or fungibility through three main optimizations:
- Create a “birthday” date when you create a Silent Payment address and save it, so that when you need to restore, you can start scanning only from that block forward on chain, instead of from the genesis block.
- Only check Taproot outputs, as very few outputs on chain are currently Pay-to-Taproot (“P2TR”) this will eliminate a large percentage of transactions and greatly reduce scanning time. Ideally this will become less useful as Taproot is used more, but will likely be an extremely effective optimization for some time.
- Only check the UTXO set instead of scanning every historical transaction, as you are only concerned with new, incoming, unspent outputs destined for your Silent Payment address. This does have the drawback of not providing transaction history, and would require an additional database over the normal methods.
Where Silent Payments Are A Better Fit Than PayNyms
Now onto the crux of the matter: If we already have PayNyms (BIP47) and they’re currently seeing growing adoption, why do we need something new? Unfortunately, the nagging issue with BIP47 remains the notification transaction for two main reasons, and it is this issue that makes Silent Payments superior for adversarial use cases in my opinion.
First off, requiring a notification transaction makes single payments extremely inefficient, as you have to send two transactions to send a single payment. For many of the common use cases of a reusable payment code, this is a prohibitive drawback as it incurs greatly increased on-chain fees and bloats the blockchain. Secondly, this notification transaction also has a massive privacy drawback, in that anyone in the world with an internet connection can look at the Bitcoin blockchain and ascertain which wallet clusters (and how many) have “connected” to a given PayNym.
Let’s take the “Freedom Convoy” trucker protest scenario that happened in Canada back in February as an example. If those who had collected and distributed bitcoin donations for the protesters had used a BIP47 PayNym to collect those donations, it would be blatantly apparent on chain what wallet clusters had connected to the PayNym, and thus highly likely that each of those wallets sent a donation to the “Freedom Convoy,” allowing governments and exchanges to crack down on those who donated.
While Bitcoin would prevent simple seizure of the donors funds (unlike GoFundMe), if these donors had ever connected their wallets on chain with a know-your-customer (KYC) exchange account or their identities, their local governments could come knocking for an explanation or even prosecute them directly.
With these critical issues, it is my opinion that BIP47 PayNyms are simply not sufficient for common adversarial use cases of reusable payment codes, which is why I’m so excited by this new proposal. While Silent Payments would increase the complexity of receiving funds to a reusable payment code over a PayNym, the resulting privacy, efficiency and non-interactivity gains are well worth it and make them the ideal step forward for reusable payment codes in Bitcoin for most use cases, something that is desperately needed.
That said, PayNyms do meet a very specific use-case — they allow reusable payment codes without running a Bitcoin full node. In situations where the extra transaction and privacy issues are less relevant than the cost of running a full node (as a recipient), PayNyms can still serve a useful purpose as an excellent method for reusable payment codes while retaining the user experience benefits of a light wallet. There is also the possibility of alternative future methods of handling the notification transaction that would offload the notification transaction to a third party, reducing some of the on-chain privacy concerns (but introducing a trusted third party) which are being explored here.
Samourai Wallet currently uses a variant of this in order to utilize PayNyms for collaborative transactions without needing a notification transaction first.
What Are The Next Steps?
While Silent Payments are extremely exciting, it is important to understand that these are still very much early days for the proposal. The proposal Gist on GitHub is undergoing broad review and comment, and a lot of the key approaches are being looked at by many people in the space to test, optimize and improve upon it along the way. The main ongoing items of exploration for Silent Payments are detailed benchmarks of various approaches and finding ways to better optimize scanning without privacy or fungibility loss.
If you’re a more technical user or developer: The more people we can get testing, benchmarking and reviewing the concepts earlier in the life cycle of this proposal, the better it will be long term, so be sure to give the Gist a look on GitHub if you have a more technical bent.
If you’re less technical, be sure to keep an eye out here on Bitcoin Magazine for future articles, and give the excellent explainer episode of “Bitcoin, Explained” on Silent Payments and the presentation by Ruben Somsen on Silent Payments watches or listens to get a more detailed understanding of how this all works and the approaches being taken.
And last of all, I just wanted to say that it is always exciting to see further development and research being done to help drive Bitcoin privacy forward, an area that is often not seen as “sexy” but is absolutely vital to enabling censorship resistance and making bitcoin truly “freedom money.”
A special thank you to Ruben Somsen and TdevD from Samourai Wallet for their time reviewing and giving feedback on the article.
This is a guest post by Seth For Privacy. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
