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.