Those of you who have been in Bitcoin for a while may be used to the seed phrase shuffle involved in creating a new Bitcoin wallet, but that concept is one that is alien to the normal person’s experience in the digital world. As people have become more and more used to trusting a centralized entity with their data behind only a username and password, the idea of physically writing down 12 or 24 words as a way to store wealth is not necessarily the most approachable.
While the concept of encrypted backups to microSD isn’t a new one, we’ve taken the path of using microSD backups as the default on-boarding method when a user sets up their new Passport. This approach does introduce a new set of trade-offs, but we think that it is a simpler approach for most people and opens up new possibilities when it comes to storing the secrets required to restore your funds after you lose your Passport, break it, or suffer a physical theft. Our goal with encrypted microSD backups is to improve the user experience and peace of mind for new users without sacrificing security, and we think this approach does just that.
Why not just use seed phrases like everyone else?
Here at Foundation, we’re deeply passionate about not only helping to onboard the deeply technical users in the Bitcoin community, but also ensuring that those who are new to the space can more easily dive down the rabbit hole of Bitcoin. This means that we work hard to ensure that deeply technical and complex setups can work well with Passport + Envoy, as well as very simplistic and approachable setups that are more friendly to new users.
This is why we’ve chosen to support both seed phrases and microSD backups and leave the choice up to the user. While we’ve made the default flow follow the microSD backup path, we still expose the seed words to users in the settings menu, allowing the standard backup path to be chosen by those who understand the trade-offs inherent in it. Unfortunately a seed cannot be used to backup and restore device configuration, account names, transaction tags, etc., meaning that a seed phrase can never restore any off-chain data.
If you backup the seed phrase you can always restore funds like normal in the Bitcoin space – both with Passport or with any other Bitcoin wallet of your choosing.
How do encrypted microSD backups work?
When you create a backup of your passport to microSD (something that automatically happens when you first setup your Passport and anytime you make account changes to it), Passport creates an encrypted 7-zip file using a 20-digit passcode that is generated using Passport’s three forms of entropy:
The onboard CPU’s random number generator
The secure element’s true random number generator
The open source Avalanche noise entropy source
These three forms of entropy are used so that even if one was somehow compromised or vulnerable to attack, the passcode would still be cryptographically secure.
This standard form of 7-zip encryption uses AES-256 to encrypt the data, and then uses a form of SHA-256 to hash the 20-digit passcode into a 256-bit key. The combination of these techniques means that there are 100,000,000,000,000,000,000 possible combinations of passcodes, making it practically impossible to bruteforce the passcode if an attacker somehow obtained the backup file.
As long as a user has access to both the backup file and the 20-digit passcode, they can not only restore their funds, they can also restore all device settings, accounts, account names, multisig configurations, etc. in just a couple of minutes. As the encrypted backup file is a standard 7-zip format, even if Foundation disappeared and your Passport stopped working you could easily decrypt the file with your 20-digit passcode on a computer and import the seed into any of your favorite Bitcoin wallets.
To learn more about the backup functionality, you can read through our docs here.
What are the key advantages of encrypted backups?
Migrating from seed phrases to an encrypted microSD backup (or utilizing them alongside a standard seed phrase backup) provides a few key advantages for users:
All device configuration, accounts, account names, and multisig configurations are fully backed up and automatically restored when using microSD backups
If you merely backup the seed phrase all of this secondary data is not backed up, leading to a lot of initial headache and extra setup necessary when restoring onto another device in the future
You can safely make and distribute multiple copies of the backup file – even to family or friends you don’t fully trust – as they cannot view or move funds in any way with just the backup file
Just be sure not to also give them the passcode!
You can store the passcode safely in an end-to-end encrypted password manager like Bitwarden without risk of funds being stolen even if someone got access to your Bitwarden account
Just be sure not to also store the backup file there!
An attacker or thief finding either your backup file or passcode would not be able to easily tell that they are Bitcoin-related
There is no reason for an attacker to suspect that a microSD card or 20-digit passcode would be worth stealing
An attacker or thief finding either your backup file or passcode could not view or steal funds in any way without having both the backup file and passcode
What are the key disadvantages of encrypted backups?
While we think the overall trade-offs inherent in microSD backups are well worth it, there are some key drawbacks that you should be aware of if you choose to only use encrypted microSD backups:
You must have both the 20-digit passcode and encrypted backup file to restore funds
I.e. if you lose either one you will be unable to restore funds!
This means that microSD backups do introduce a second single point of failure
Advantage #3 above greatly reduces this disadvantages impact, practically
If you store both the encrypted backup and passcode together, it provides no added security over a plaintext seed phrase
MicroSD cards themselves have a limited lifecycle and can fail – it’s important to use high-quality industrial-grade microSD cards (like those we ship with Passport) to reduce this risk
You can also backup the file to another storage medium like a NAS or extra hard drive as another failsafe, and shouldn’t rely on a single microSD card alone!
This may be a short list, but the first point is extremely important to understand – losing either the passcode or the encrypted backup file would lead to loss of funds if you also lost or broke your Passport!
Which should I use?
The beauty of Bitcoin is that it enables you to choose your own path, and we certainly don’t want to inhibit that freedom. That’s why we leave the ultimate choice up to you and ensure that you aren’t locked into our ecosystem (or even our favorite approach). Whether you choose microSD backups or seed phrases (or both!) is up to you, but both can be easily imported into any standard Bitcoin wallet app. If you want added peace of mind, you can even use both and store the three pieces separately – encrypted backup file, 20-digit passcode, and seed phrase!
Ultimately the choice is yours, but we certainly love encrypted backups and how they’re helping onboard less technical users in a way that is approachable and secure.
In Part 1 of our series on making every spend a CoinJoin, “Why We Mix”, we walked through the philosophical and practical first steps behind the fight for privacy in Bitcoin. In Part 2 we’re digging into what information we share when we make a standard Bitcoin transaction, and what we want to (and can!) choose to protect to gain financial privacy.
Each transaction we send in Bitcoin contains information on all inputs used, all outputs sent, and the time when the transaction is published to the mempool and included in a block. This ultimately breaks down into 4 key pieces of information; the sender, the recipient, the amount sent, and the source node.
Why does Bitcoin reveal so much information in each transaction?
When you sit down and think about the amount of information contained in a Bitcoin transaction, you may begin to wonder why in the world all of this has to be shared with the world each time you send a Bitcoin transaction. One of the tradeoffs that comes with making Bitcoin a decentralized and distributed ledger is that each transaction must contain enough information for (1) miners and nodes to validate that transactions don’t double spend funds, (2) users to be able to find their own funds without hassle, and (3) for the supply of Bitcoin to be easily validated by network participants.
While novel approaches to leveraging more powerful (but more complex!) forms of cryptography to hide sender, recipient(s), and amounts have been developed and proposed over the years, none of these approaches existed in the early days of Bitcoin, and each comes with its own set of tradeoffs and risks. Instead of implementing protocol changes like ring signatures, confidential amounts, or stealth addresses at the base layer, the Bitcoin community and developers have opted to keep Bitcoin’s base layer transparent by design and rely on higher layers and application-level privacy tools to allow users to opt-in to better privacy in Bitcoin.
Because of this choice, the ability for each of us to gain privacy becomes a matter of personal responsibility and knowledge instead of a protocol-enforced default. For better or worse, we each get to choose our own preferences and path towards financial privacy when it comes to Bitcoin.
An example transaction
As we walk through these four key pieces of information about each Bitcoin transaction, having an example transaction to refer back to will be invaluable. This transaction has been chosen at random from the Bitcoin ledger, but illustrates quite a few key aspects of a lack of privacy being inherent in Bitcoin.
What can we learn from a simple look into the transaction? Let’s break it down into key findings from using simple, widely available blockchain exploration tools like mempool.space and oxt.me:
The sender consolidated multiple outputs to make the transaction, revealing all the inputs as almost certainly belonging to them
Going back one hop with the largest input shows us that some of the funds were withdrawn from Bitstamp (but not all)
The sent amount is almost certainly 0.011 BTC, as it is sent to a different type of address (“P2SH”, or wrapped/nested SegWit)
We can also confirm this analysis due to the rounded payment amount (0.011 BTC) which almost never happens with fees or change outputs
The recipient is still using a legacy Bitcoin wallet and has not upgraded to use Segwit
The change amount is almost certainly 0.00004088 BTC, as it is sent to the same type of address as the inputs (“P2WPKH”, or Segwit Bech32)
We’ll look more at these findings in each section below.
Protecting the sender
When we look at the different pieces of information revealed in a Bitcoin transaction, the information on funds being spent (and thus on the sender themselves) rightfully deserves the most focus when approaching transactional privacy. When you view any basic Bitcoin transaction in an explorer, you quickly realize that you can learn an immense amount of information about the sender by simply following the inputs backwards.
How do we see this play out in our example transaction? Let’s take a closer look:
The sender consolidated multiple outputs to make the transaction, revealing all the inputs as almost certainly belonging to them
Going back one hop with the largest input shows us that some of the funds were withdrawn from Bitstamp (but not all), tying multiple addresses together with funds connected to the sender’s identity known by Bitstamp
Inputs to a previous transaction sent from Bitstamp wallets
This simple analysis is primarily possible because in Bitcoin, almost all transactions are performed by a single entity; and if a single entity is performing a transaction, then all inputs to that transaction are necessarily owned by them. This heuristic is called the “common-input-ownership heuristic” and is one of the foundational building blocks for the majority of chain surveillance in Bitcoin today. When those wishing to surveil Bitcoin’s usage can safely assume that all inputs in a transaction are owned by the sender, they can build detailed and nearly complete pictures of a user’s spending habits past, present, and future.
This heuristic is also the core of what CoinJoin-style transactions attempt to confuse and break by coordinating a single transaction between many different participants. If enough Bitcoin users started to make CoinJoin transactions regularly, we could even go so far as to break this heuristic and make it inaccurate for chain surveillance companies, severely limiting their visibility into our financial activity on Bitcoin.
While hiding the input addresses and amounts is strictly not possible in Bitcoin today, we do have a few options for obfuscating and confusing chain surveillance, making their lives as difficult as possible.
What can we do today?
While we’ll keep things short and sweet in this section, here are a few ways you can better protect your financial privacy when sending Bitcoin transactions:
Always use a new receive address
If your current Bitcoin wallet doesn’t do this automatically, it’s far past time to switch!
Don’t consolidate funds in your wallet (a commonly recommended way to save on fees down the line) by sending all of your Bitcoin back to yourself in a single transaction
Use as few inputs as possible (only one, if possible!) when sending a transaction
Thankfully most good Bitcoin wallets will do this for you by default!
Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can easily enable this if they’re using a hot wallet!)
Use wallets like Samourai Wallet and Sparrow Wallet to CoinJoin your funds, ensuring that even when you spend funds the prior history of each input isn’t able to be traced
Protecting the sender is the core focus for many of the privacy tools built on Bitcoin, but protecting the amount sent in each transaction is also an important piece of a holistic approach to privacy on-chain. If we’re not careful about how amounts are handled, we can make it easier to undo our privacy and link transactions and addresses to each other. The most common ways to use amounts to reveal information in a transaction are to look for rounded payment amounts (i.e., 0.001 BTC exactly) or to look for exactly matching amounts (minus normal fees) going into and out of exchanges, instant exchangers, or decentralized exchanges.
How do we see this play out in our example transaction? Let’s take a closer look:
The sent amount is almost certainly 0.011 BTC, as it is sent to a different type of address (“P2SH”, or legacy SegWit)
We can also confirm this analysis due to the rounded payment amount (0.011 BTC) which almost never happens with fees or change outputs
The change amount is almost certainly 0.00004088 BTC, as it is sent to the same type of address as the inputs (“P2WPKH”, or Segwit Bech32)
Amount-based heuristics are a common tool used by chain surveillance companies to confirm other heuristics (like the “common-input-ownership heuristic” we’ve already discussed) or to make educated guesses in the absence of clearer signs on-chain. The ability to use amounts to tie transactions and inputs together is one of the main reasons that most of the most battle-tested CoinJoin protocols use common denominations for inputs (i.e., 0.05 BTC) instead of allowing arbitrary amounts. Using these common denominations prevents trivial linkage of inputs and outputs down the line.
What can we do today?
Avoid using rounded amounts (i.e,. 0.01 BTC) when sending funds unless necessary
Avoid using specific fee amounts (outside of 1sat/vbyte, of course) and allow your wallet to calculate fees appropriately
Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can easily enable this if they’re using a hot wallet!)
Now that we’ve taken a look at protecting both the sender and amount in a transaction, how do we go about protecting the recipient’s privacy? Thankfully, many of the same principles apply here as well, especially avoiding address re-use. As every transaction in Bitcoin necessarily has a recipient with address and amount being visible on-chain, it can be quite difficult to actually preserve the privacy of the recipient, both from the sender and from outside observers.
How do we see this play out in our example transaction? Let’s take a closer look:
The sent amount is almost certainly 0.011 BTC, as it is sent to a different type of address (“P2SH”, or legacy SegWit)
We can also confirm this analysis due to the rounded payment amount (0.011 BTC) which almost never happens with fees or change outputs
The recipient is still using a legacy Bitcoin wallet and has not upgraded to use Segwit
The recipient sweeps this output along with many others in a later transaction, linking their other receive history together
Chain surveillance companies leverage many of the same techniques to identify recipients as they do with senders, including wallet fingerprinting by fees, script types, output consolidation, and address re-use. When these types of heuristics are used, it can lead to “wallet clustering”, where those performing surveillance can tie together transactions under a single entity, even if there is no direct identification attached. As always with privacy, it’s important to blend in with the crowd and avoid any mistakes that can make it easier to separate and cluster transactions under a single entity.
What can we do today?
Avoid re-using addresses when receiving funds
If you’re the sender and a recipient is re-using an address or has a static Bitcoin address posted for donations or payments, pressure them to either use a PayNym or a solution like SatSale or BTCPay Server to provide a new address with every payment
Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can enable this, if it’s not enabled ask your merchant to enable it!)
Last but not least comes an aspect of Bitcoin privacy that is often forgotten – protecting the IP address of the Bitcoin node that broadcasts the transaction in question. While the IP address and information about the originating node isn’t stored on the blockchain directly, it can be relatively easily seen by anyone operating a few nodes on the network and desiring to gather that type of information.
Because Bitcoin Core uses a very simplistic transaction broadcast protocol, an adversary seeking to surveil the network can run many nodes in many different geographic locations to try and be at least one connection of most nodes in the network. Once they have these broadly distributed nodes (a “Sybil attack”, something that is very cheap and easy to do in a permissionless and decentralized network like Bitcoin), they can then watch for where in the network they see transactions first broadcast. If they notice that a transaction they’re interested in was first broadcast from one node and propagated from there, they can make a very well educated guess that it was the source node for the transaction.
While this doesn’t guarantee that their guess is correct, it does help them narrow down the potential source node of a transaction and more actively Sybil attack that specific node to look for further transactions of interest. This can be combined with on-chain heuristics to try and find the source node being used by a specific entity and gain vast insight into their spending habits, their geographic location, and even their home address (if they reveal their true IP address to the Bitcoin network).
It’s important to remember that a peer-to-peer network like that used in Bitcoin is designed to be censorship-resistant and permissionless, not private. This approach works extremely well at ensuring that in most censorship scenarios a transaction can still be broadcast to the whole network, but also ensures that a motivated adversary can quite easily follow the flow of transaction propagation and block propagation across the network.
If you’d like to learn more about the issues inherent in this approach, there is an excellent article on the topic titled “Bitcoin’s P2P Network” at nakamoto.com.
What can we do today?
If you run your own Bitcoin node, set it to only use the Tor network for communication
This option is controlled by `onlynet=onion` in the config file, read more on the topic here
Broadcast transactions manually via the Tor Browser and a service like mempool.space
Only do this over Tor, never via clearnet!
The current Onion address of the mempool.space broadcast tool is here
Run your own Samourai Wallet “Dojo” node stack, which is Tor-only by default
Conclusion
After reading this I hope you come away with the conclusion that while Bitcoin’s on-chain privacy is imperfect by default, there are solutions available to each of these problems today. It may seem daunting to have to consider each of these aspects of information when sending or receiving a Bitcoin transaction, but as the issues around privacy within Bitcoin are clarified and made known, the wallets and apps we use to interact with Bitcoin can grow to better handle all of these potential issues for a user automatically.
Over the long-term it’s extremely important that wallet developers and node developers work hard to build in sane and private defaults to their apps, as most users have neither the knowledge nor expertise to properly handle every core piece of Bitcoin privacy. The more we as developers can improve users’ privacy without them even thinking actively about it, the better off our users will be and the better off the Bitcoin network and ecosystem will be.
In part 3 of this series we’ll take a closer look at protecting the sender via CoinJoin, including a sneak peak at what we’re working on to help make Bitcoin privacy more approachable for every Bitcoin user.
Stay tuned, and thanks for diving into the deep end of Bitcoin privacy with us today!
