Wallet privacy
It’s a common misconception that bitcoin payments are anonymous. Rather, bitcoin payments are pseudonymous, meaning no identifiable information is tied to transactions. Unless ownership is revealed, whether by the parties involved or some third-party, payments remain anonymous.
It is important to differentiate between bitcoin and Lightning network privacy. Their differences in technical architecture result in different privacy considerations.
Transactions, their signatures, and addresses added to the bitcoin blockchain remain public forever. This means that looking up any address or transaction is trivial, as demonstrated by going back to the very first block mined on January 3, 2009. The key to keeping your transactions private is to prevent others from determining which addresses you own1. Since Satoshi let others know that they had mined the first block, which contained a single transaction, one can deduce that both the address that received the block reward and the sender address in the transaction belongs to Satoshi. This illustrates the permanence of associations between addresses and identity. While it’s possible to break assumptions of ownership going forward, the challenge is to recover privacy once an association is made public. That being said, in this case the pseudonym “Satoshi Nakamoto” has yet to be associated with any personal identity.
Each bitcoin transaction contains at least one input and at least one output. This means that once a single address is known, there is a trail to follow the bitcoin.
As documented by Wasabi Wallet
On the Lightning network, a payment is only stored by the respective sender and receiver, and only as long as the channel in which the payment was made is open. However, opening and closing channels requires entries on the bitcoin blockchain, and those are also publicly stored forever. Additionally, Lightning nodes are always online and usually directly tied to a single wallet, providing another data point. For a detailed analysis of privacy on Lighting, see the Security and privacy chapter in the Mastering the Lightning Network book.
These are just some of the interactions through which we leave traces of data that diligent observers can connect and build user profiles around. For the rest of this page, we focus on what product builders and users can do to improve their payment privacy.
Methods to preserve privacy #
There are many ways your identity might get connected to your wallet2 and payments, so keeping bitcoin payments private takes diligent work, but is not impossible. Let’s explore some practices that help preserve privacy of bitcoin payments.
Use multiple wallets or applications #
A simple way to avoid data points from being connected is for users to set up and use multiple wallets or accounts for different purposes. For example, if a user wants to set up a page to collect tips on their website, they can set up a dedicated wallet. Anyone analyzing the activity around the wallet would only see incoming tips and none of the other activity that happens in other wallets the user controls. Users just need to be careful with cross-wallet transfers, as those can allow observers to connect the activity again.
Be intentional when sharing static Lightning identifiers #
Lighting node Ids, Lightning addresses, and LNURL-Pay invoices (see Payment request formats) are examples of endpoints that can be used to generate many Lightning invoices. While this is convenient for users, it is bad for privacy. For example, placing a Lightning address on a website or social media profile makes it trivial to create a direct connection between the Lightning node and the owner of the website or profile.
Generate a new address for each on-chain payment #
A new address should be generated by the wallet application any time the user wants to receive bitcoin on-chain. This is achieved by using HD Wallets, a standard in modern bitcoin applications that can generate and manage an infinite number of addresses without revealing their common root. This allows each incoming transaction to use a new address that is unconnected to any other in the wallet, making it difficult to associate with the owner.
Address re-use degrades the privacy of both the sending and receiving parties. Re-using an address on the receiver’s side means that anyone with whom that address is shared can see previous payments and the amount of bitcoin controlled by that address.
If bad actors can see your income, holdings, and spending, they can use this information to target and exploit you
By sending to an address that is being reused, the sender is now traceable and connected to any previous transactions the receiver has made with that address. This increases the risk of exposure to an adversary.
Do's
- Generate a new address any time the user wants to receive bitcoin
- Make it easy to generate as many addresses as the receiver needs
- Warn the user if an address has already been used before broadcasting a transaction
Don'ts
- Make it easy to reuse an address.
Keep track of who knows about on-chain addresses #
If the application supports it, the user can add additional details to a payment when receiving bitcoin. This practice is often called address labeling. Not only does this help to remember what payments were for, it also enables preventative measures for preserving privacy. Labeling receiving addresses(UTXOs) with the sender’s name can inform decisions for which UTXOs are selected as inputs in future transactions, this is often referred to as coin control.
Some applications make it possible to filter UTXOs by label to make such selections easier.
Increase anonymity through obfuscation #
A CoinJoin is an advanced technique where multiple participants collaborate on a transaction to break the “common input ownership” heuristic3, which assumes that all inputs in a transaction likely belong to the same owner. In a CoinJoin transaction all the outputs tend to be of the same amount. This makes it harder to define which input paid which output, somewhat breaking the absolute traceability of bitcoin transactions. As with any other anonymity network, a large and diverse group of participants will be more effective in disassociating the connections. CoinJoin transactions are not yet widely supported by bitcoin applications.
Users still have to be mindful of how the UTXOs they received from the CoinJoin are spent. For instance, spending them together in a single transaction would unravel the anonymity gains from participating in the CoinJoin.
Hiding Sensitive Information #
Imagine this scenario. The user is in a public place, and they need to make a payment using their bitcoin wallet. They open the wallet on their phone, but they don’t feel comfortable having their address and balance information clearly visible to strangers who may be looking over their shoulder, persons lurking, or video surveillance. Hence by giving users the ability to hide sensitive information in their wallet, but only when desired, they gain an added sense of physical privacy and security when using the app in public.
What information is considered sensitive? #
Sensitive information in wallet applications include the wallet balance, addresses, private keys and previous transactions information.
- Wallet Balance - shows how much is owned
- Addresses - can be used to track on-chain transaction history
- Invoices - can be used to track Lightning payment history
- Private keys - can be used to access and transfer bitcoins
It’s more common for wallets to protect private keys, but not much is done for other sensitive information like the balance, addresses, and previous transactions. A few wallets like Bitcoin Core, Wasabi, Muun, and others have made it work, though. Below are patterns and considerations for hiding and revealing sensitive information.
Quickly hiding balances #
The hide icon/button, which is usually displayed within close reach of the balance itself, is used to quickly and easily hide wallet information by tapping, and revealing it again by tapping and holding.
This is an easy and convenient way to switch between revealed and hidden states, but still makes it relatively easy for anyone else to reveal user information if they have access to the device.
Entering a PIN to reveal information #
With this method, it’s as easy to reverse the hidden state as enabling it. This is good for convenience’s sake. However, for protection against unauthorized access, perhaps the user should only be able to unhide their information if a PIN or password has been entered. This could therefore reaffirm the identity of the wallet owner for extra security.
In this example the risk of an unauthorized person revealing their information is minimal due to the PIN required. However, it might not be convenient for the users to repeatedly put in their PIN when ever they want to reveal their information especially if they do so often.
Hiding when inactive #
Another solution is to invoke the wallet’s hidden state as a default when the app is opened, to protect against prying eyes during initial display. The pre-hidden state can be unveiled after a tap, PIN entry, or perhaps a short 5-second timer.
This gives users some time to assess their environment before their info is displayed but could leave them frustrated, having to wait for their information to be revealed especially in an urgent situation.
An application-wide setting #
Having the show/hide button right on the main screen makes things quite obvious for someone who has access to a user’s device to press unhide. A solution would be to move the hide toggle away from the home screen and into the app settings. This way, if someone has access to their device and opens the app, they may not immediately know how to reveal the balance, transaction, or addresses as it is not made obvious as the previous solutions.
An advantage here is the risk of an unauthorized person revealing their information is minimal due to the fact that the toggle isn’t immediately visible on the home screen. The downside is that a user cannot quickly hide their information if the need arises.
Design with privacy in mind #
Thinking about privacy is critical during the design process. Your users will not have the same level of knowledge of how to use bitcoin privately. The privacy by design framework states that privacy should be incorporated and built into products by default. This way, whether or not the user is concerned with their data privacy, they would always be protected through good UX and UI.
However, it still is important to help users understand any actions that might impact their privacy. Most of the risks occur at the point of creating a transaction or requesting a payment, and we should try to design solutions that reduce the risk of unknowingly degrading privacy.
While there is no perfect solution that will guarantee 100% privacy, try to minimize how much information gets shared to the most essential. Consider ways to inform and prevent user actions that negatively impact their privacy as they use your product.
Next, let’s dive into the savings wallet reference design.