How Passport protects your Bitcoin

Take a minute and ask yourself two simple questions: who or what are you trying to protect your Bitcoin from? How far are you willing to go to protect it?

These two questions are the root of a concept called “threat modeling”, and should be the basis for deciding what steps you take to secure your Bitcoin. Answering these two questions properly requires an understanding of what threats are out there to your Bitcoin and how they can be prevented.

In today’s blog post we’re going to walk through the most common threats to a Bitcoiner’s sats and break down how Passport helps to keep your savings safe.

Loss of funds

The threat: While this isn’t an intentional attack by a bad actor, it’s by far the most common way that people lose their Bitcoin. If proper backups aren’t kept, frequently tested, and broadly distributed, loss of funds is an ever present risk.

Losing your Bitcoin can certainly happen due to unforeseen events like house fires and floods, but it most often comes as a result of over-complicated setups and unplanned inheritance. It’s easy to want to always be on the cutting edge of security and wallet setups in the Bitcoin space, but it often pays to follow the old “KISS” (”keep it simple, stupid!”) adage when it comes to storing your Bitcoin!

Be sure that you thoroughly test the recovery process of whatever setup you do decide, and ensure that those you want to pass your Bitcoin on to can follow the recovery process without any additional help or input from you. It pays (in sats!) to be thorough and diligent when it comes to storing your Bitcoin.

An example: Lost Passwords Lock Millionaires Out of Their Bitcoin Fortunes | NY Times

How Passport protects you: Passport takes two major approaches to helping you preserve access to your Bitcoin: (1) providing users the necessary tools to write down their seed phrase and/or backup PIN code safely, and (2) providing encrypted microSD backups as the default option. Our goal with Passport backups is to prevent losing Passport from being a life altering event, instead equipping you to easily and safely restore funds anytime.

Encrypted backups in particular provide a uniquely powerful backup method, as you can easily distribute encrypted backup files broadly, be it your favorite cloud service, your password manager, or many different microSD cards or USB flash drives. As the backup file itself is encrypted, even if an attacker stumbles upon it they won’t be able to tell what it is, much less access the seed phrase within it without the associated backup PIN code. Then simply make multiple, geographically distributed copies of your backup PIN code (never together with your encrypted backup file!) and you’ll always have the ability to recover funds.

For the more traditional Bitcoiner, you can choose any number of backup methods for the seed phrase itself, including steel backups to ensure that fire and weather can’t harm your backups.

Learn more: Why we love encrypted microSD backups

Social engineering

The attack: The idea of social engineering is as old as time, but has become even more rampant in the digital age. When it comes to Bitcoin, often the largest risk to a user’s funds is someone online tricking them to install malicious firmware or enter their seed phrase directly into malicious software.

How Passport protects you: Passport prevents the installation of any firmware that is not signed by Foundation’s developer keys, ensuring that even if you get a malicious firmware file from an impostor site or fake support agent, there is no way for you to install the firmware onto your Passport.

When it comes to scams centered on tricking users to enter their seed phrase, while there is no technical way to prevent this (a user always needs to be able to access their seed phrase for backup purposes), Passport forces a user to go through several prompts warning them not to share or reveal their seed phrase to anyone else.

Malware on your computer or phone

The attack: Malicious software wallets are a constant, ongoing battle in the Bitcoin space and have claimed many sats from good Bitcoiners over the years. The common attack is to use advertisements on Google Search or use similar names on platforms like the Google Play Store to trick users into installing malicious versions of popular wallets.

An example: Electrum Bitcoin wallets under siege | Malwarebytes

How Passport protects you: One of the biggest benefits to a hardware wallet that utilizes an air-gapped design like Passport is that it is practically impossible for malware to steal funds in any way if the user is observant. Passport’s air-gapped design means that no matter what software wallet you’re using, you always have to scan in the transaction and verify the transaction details on Passport’s large, color screen before signing.

Even if the wallet attempts to provide Passport with a fake change address, a common and stealthy attack, Passport will check the change address and warn if it does not belong to your wallet. As the malware on your computer has no way to access Passport via USB or Bluetooth, it cannot infect Passport and make Passport display false transaction details, either. This is an immensely powerful defense and one that protects you against many different threats!

The next time you send a transaction, take a bit of extra time and be sure that you’re verifying the address and amount properly to protect your sats. In addition, make sure to bookmark the legitimate sites for your favorite Bitcoin wallets, never trust a random DM on Telegram, and verify software that you download whenever possible.

“Evil maid” attacks

The attack: An “evil maid” attack is a category of attacks encompassing any time an attacker gains physical access to a device that’s off. This can happen when you’re at home (i.e. someone you trust), when you’re traveling (i.e. an actual maid at a hotel), or when the device is in transit (i.e. checked baggage while flying). A whole new world of risk opens up as soon as an attacker has physical access to your Bitcoin wallet as they can perform a host of attacks.

The most common evil maid attack is to swap your Bitcoin wallet with a malicious wallet that records your PIN code and then recover the malicious device and use the captured PIN code to steal funds from your wallet.

How Passport protects you: Passport provides two main mechanisms to help protect yourself against a malicious device swap attack. Security words are easily enabled in Passport’s settings and make Passport show you two unique security words that can not be seen or replicated without knowledge of your PIN. You can learn more on how to use this feature in our documentation here.

The second defense is to check the boot count under Firmware in settings and compare with what you’d expect. While it’s a simple and less fool-proof check, it does add an additional layer of difficulty for any device swap.

Learn more: Security Code & Security Words

Physical theft

The attack: This one is quite straight forward, and involves an attacker simply stealing your Bitcoin wallet. Stealing your hardware wallet gives the attacker more time to attempt physical attacks or a PIN brute-force attack, though the fact that your wallet is missing can give you a chance to move funds if you have proper backups available.

An example: Kraken Identifies Critical Flaw in Trezor Hardware Wallets | Kraken

How Passport protects you: Passport has been built from the ground up to provide an extremely strong defense in the case of a stolen device. Passport’s security architecture leverages a secure element to best protect against physical attacks, making successful physical attacks that steal funds infeasible.

Passport’s secure element provides a strong hardware-based PIN code rate limiting, allowing only 21 attempts to enter the correct PIN before the device is intentionally bricked and no seed is able to be recovered from the device. The secure element also prevents an attacker with strong electronics expertise from being able to extract the seed from the processor or memory, as the secure element would also have to be compromised to retrieve a working private key.

Learn more: Maximum PIN Attempts

Supply chain attacks

The attack: Last but not least, we have supply chain attacks where an attacker intercepts the device before you receive it. The attacker could tamper with the hardware of the device and re-assemble it with some form of backdoor or transmission of the private key built in.

An example: Case study: fake hardware cryptowallet | Kaspersky

How Passport protects you: With Passport we’ve engineered a novel supply chain verification system that leverages the secure element on Passport. Every Passport device has a secret key locked away in the secure element that is used when you setup your Passport to perform a challenge-response check with our servers that will only be valid on devices we have provisioned directly at the factory that have not been tampered with.

If the secure element is tampered with in any way, or if a malicious device was swapped out for a legitimate one it would be unable to pass supply chain verification.

Learn more: Passport Supply Chain Validation

Conclusion

While seeing many of the potential threats to your Bitcoin can feel overwhelming, note that the vast majority of these threats are mitigated by simply using Passport as intended. Secure self-custody doesn’t have to be complex and daunting, though we do have to be vigilant and responsible when taking back control of our money via Bitcoin.

Why reproducibility matters

The ability to reproduce and verify firmware for Passport has always existed, but in recent weeks we’ve ramped up our efforts to make it easier for anyone to be sure that the code running on their Passport exactly matches what is on Github. That culminated last month in the release of a new step-by-step guide to reproducing Passport firmware, making it easier than ever for you to verify firmware yourself, along with updates to the validation of our firmware’s reproducibility on Wallet Scrutiny.

While those resources are more of the “how” for reproducing firmware, we wanted a place to walk through the “what” and the “why” as well.

What are “reproducible builds?”

While there are many open-source projects out there today, the ability for you to validate that the binary (the actual piece that you install or run) is actually a bit-for-bit match with the code on Github is quite rare. The main reason for this is that ensuring binaries for a given project are reproducible requires a massive amount of work up front for the developers and maintainers, as well as additional documentation, maintenance, and customer support. Here at Foundation we view the trust minimization that reproducible builds bring as vital, so we’ve put in the hours to enable easy reproducible builds for everyone.

Reproducible builds allow you, the user, to build the binaries for Passport directly from the source code in a repeatable, “reproducible” way and validate the results match exactly what we ourselves publish. The way these builds actually function under the hood can differ widely from project to project, but always rely on building the binaries in exactly the same way no matter the users operating system, computer, etc. The rough process for Passport’s firmware looks like this:

  1. Download the source code from Github that corresponds to a specific version of firmware (i.e. v2.1.2)
  2. Create a build environment that is exactly the same as ours at Foundation, using Docker
  3. Build the binaries directly from the source code you just downloaded from Github
  4. Compute a cryptographic hash for your newly built binaries and compare it to the released binaries, proving that they match exactly

Thanks to the magic of cryptography, we can compare the binaries we build with those Foundation releases by computing a hash of the binary, something that will change completely if even one bit of data is different in our binaries versus Foundation’s. This makes it trivial to compare and verify binaries, the ultimate goal of reproducible builds.

You can get a quick walk-through of what to expect in this short video of the entire process, start to finish:

Why does this matter?

The ability to not only see, read, and verify the open-source code published for Passport, but also to take it one step further and ensure that the firmware you run exactly matches that code provides the highest level of trust minimization possible. When you can be sure that the code actively running on Passport matches exactly what you would expect, it reduces the potential threat of Foundation releasing malicious firmware as there is no way for us to include code in the firmware that isn’t publicly visible and scrutinized on Github.

We don’t want you to have to trust us at all, and reproducible builds are the full embodiment of the phrase “don’t trust, verify.”

Try reproducible builds today

If this piqued your interest, you can dive in and reproduce Passport firmware yourself today! Following the guide below will take you through every step of the process:

While the guide is focused on Linux, the commands and steps will be very similar on operating systems like Windows and MacOS, and we’ve linked out to the relevant guides for dependencies on those respective operating systems.

If you do try out reproducible builds, we’d love it if you’d share your results publicly! Post the output of the process to Twitter or your favorite social media platform, tag us @FOUNDATIONdvcs, and we’d love to share your post out ourselves.

Make 12 Words the Standard

As we expand our audience to more Bitcoin beginners, we’re constantly on the lookout for ways that we can simplify and improve the user experience for those using Envoy and Passport. We’ve focused on efforts that help to abstract away the difficulties that come with the concept of seed words for new users through implementing Magic Backups in Envoy and encrypted microSD backups for Passport, but for our users to retain full sovereignty the option of using basic seed words has and always will be a core feature of our products.

One of the longest held beliefs in the Bitcoin space is that using a longer seed phrase (i.e. 24 words instead of 12) is a way to future-proof the security of your funds. Because of this belief, most hardware and software wallets default to using 24 word seeds, something that adds additional friction to users as they need to store a very large secret and verify it properly. Unfortunately, this belief is based upon a narrow view of private key security, and forces unnecessary burden on users with little to no real-world benefits.

In this blog post we’ll walk through how private key security works in Bitcoin, how seed phrases are only one piece of that security, and why we think we should make 12 word seed phrases the standard moving forward.

Don’t have time for the full post? The tl;dr is that the lowest hanging fruit for an attacker is always reverse engineering a private key from a Bitcoin address known to contain funds, even when using “only” a 12 word seed phrase. However, this is a complex and nuanced topic, so keep reading below to get a better understanding of why this is true!

What is a private key?

In Bitcoin, a private key is created through simply choosing a random number between 1 just under 2256 (that’s over 115 quattuorvigintillion for those of you keeping score). This number must be chosen in a truly random and unrepeatable way, so we rely on things called “random number generators” or “true random number generators” in computers and hardware wallets to ensure that the source of entropy (read: randomness) is good enough to produce truly random results. To get a better idea of what the chances of randomly guessing the same number as someone else are, here is a great and brief video on the topic:

The reason this number must be between 1 just under 2256 is that Bitcoin uses a 256-bit elliptic curve called secp256k1, so the most secure random number for your private key will be in that range. When you choose a number, this is translated to points on this elliptic curve (a type of graph, in essence), giving you a fully functional public key from that one number. This operation is something that is very quick to generate a private key, but practically impossible to reverse engineer a private key from a given public key (i.e. a Bitcoin address).

When you generate a private key in Bitcoin it looks something like this:

1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD

Note how hard it would be to properly write down or memorize a private key in this format. Enter BIP 39, a proposal that allowed us to use a list of words to securely and deterministically (read: repeatably) generate a private key from that list of words.

Private keys made human

Seed phrases as we know and love them were introduced way back in 2013, and quickly gained adoption as they greatly simplified the process of setting up or restoring wallets in Bitcoin. As a set of words in the same order will always generate the same private keys, we can simply save these words and be sure that we can always recover funds properly. Seed words must be a minimum of 12 words in length, but can be as long as 24 words if desired.

When you generate a seed phrase, it will look something like this:

fit hen toward recycle detail raise glare gate diagram room vendor lesson

As Bitcoiners have a penchant for maxing out security and always keep a long-term view when approaching their money, most jumped directly into using the maximum length seed phrase of 24 words from the get-go, as it theoretically provided more entropy (which people viewed as more security) than smaller seed phrases. But how secure really is a seed phrase, and how does it compare to the security of a private key itself? How can an attacker actually attempt to steal funds from a given Bitcoin wallet?

Attacking your private keys

To better understand how secure private keys and seed phrases are, we first need to look at what an attacker can do to try and steal Bitcoin from your wallet through cryptography alone. There are two basic attacks that can happen against your private keys in Bitcoin:

  1. An attacker can attempt to guess the words and order of your seed phrase in its entirety
  2. An attacker can attempt to reverse engineer a private key from a given public key (Bitcoin address)

The first attack is often called a “brute-force attack,” as it involves an attacker trying over and over again to guess the correct secret – in this case a seed phrase. When using a 12 word seed phrase there are 204812 possible word combinations, of which some are able to be immediately discarded due to a failing checksum, meaning the number of valid seed phrases is actually 2128 (or 340,282,366,920,938,463,463,374,607,431,768,211,456). Yes, you read that right. In order for an attacker to correctly guess your 12 word seed phrase would require billions of years using modern supercomputers. In essence, there is no real-world possibility of an attacker correctly guessing your 12 word seed phrase.

The second attack is also known as solving the Elliptic Curve Discrete Logarithm Problem (ECDLP). While it is trivial to generate a private key and derive public keys from it, there is no efficient way to recover a private key from a given public key. The asymmetry of this aspect of elliptic curve cryptography is at the core of securing Bitcoin (along with many other tools for freedom, including HTTPS security for websites, the Tor network, Signal messenger, and more). As Bitcoin reveals all public keys and amounts publicly, an attacker could choose a given public key with a large amount of Bitcoin (i.e. Satoshi’s known addresses) and attempt to solve the ECDLP for that public key.

Bitcoin uses the secp256k1 elliptic curve, a 256-bit curve that is well understood and vetted in the cryptography space. An attacker would need to leverage the best known attack, Pollard’s rho algorithm, which takes a number of operations equal to about half the curve size. This means that an attacker attempting to solve the ECDLP for a given Bitcoin address would need to perform 2128 operations (or 340,282,366,920,938,463,463,374,607,431,768,211,456) in order to guess the private key correctly. Performing that many operations on modern computers would take in the billions of years. In essence, there is no real-world possibility of an attacker solving the ECDLP for a given public key.

To put those numbers in perspective, solving the ECDLP for your public key or guessing your seed phrase randomly is less likely than picking the same atom out of the universe. The security provided by the unimaginably large numbers we’re discussing here securing your Bitcoin keys is hard to fathom, but comparing it to more tangible numbers like these can help. This security means that attacking a 12 word Bitcoin seed or solving the ECDLP for a given Bitcoin address are both considered infeasible with modern computers.

12 words is the sweet spot

So how does this all add up to a 12 word seed phrase being the ideal length? A 12 word seed phrase contains 128 bits of entropy, allowing it to be used to generate private keys with the full 128 bits of security provided by secp256k1. We broke down the rough estimates for solving the ECDLP or guessing a given 12 word seed phrase previously, but this means that a 12 word seed phrase is the minimum length to not hamper the security of the underlying private keys. If we shortened the seed to, say, 10 words, we would be reducing the security of the private keys and making both the underlying private keys more insecure and providing an easier brute-force attack against the seed words.

If you were to use a 24 word seed phrase, even though it would provide additional entropy when generating private keys, the underlying private key would still be broken in 2^128 operations — exactly the same as a 12 word seed. This means that longer seed phrases will not add additional security to the underlying private keys themselves, and only increase the difficulty of brute-forcing a given seed phrase (something that is already statistically impossible for a 12 word seed phrase).

While we can increase the protection against brute-force attacks of a seed phrase by increasing the number of words, the core security of your funds in Bitcoin remain the security of the underlying private key itself — even when using a longer seed phrase. The lowest hanging fruit for an attacker is always to attack the cryptographic security of a Bitcoin address they know contains Bitcoin, rather than attempt to guess a seed phrase with funds.

Bringing things back to reality

In summary, the security of a 12 word seed phrase is roughly equivalent to that of the underlying security of a private key in Bitcoin, and any additional theoretical security gained through using a larger seed phrase has no impact on real-world attacks. 12 words provide the required amount of entropy to generate a secure private key and more than enough security against a brute-force attack at the same time.

It’s important to note that far and away the largest cause of lost Bitcoin is not theft, but rather a user failing to properly secure their seed phrase. Any reduction in the barrier of entry to proper backup, storage, and recovery of a seed phrase will lead to a real reduction in the amount of Bitcoin lost forever. In addition, the other major ways to lose funds are to have them stolen by an attacker finding a seed phrase or socially engineering a user into giving up their seed phrase. Both of these attacks do not gain any protection or resilience through using a longer seed phrase.

If no additional security is gained in the real world by doubling the length of the secret we need people to store from 12 words to 24, doubling the amount of words to enter when restoring, and doubling the amount of words to verify on initial setup, we can further lower the barrier of entry to Bitcoin by leveraging the immense security provided by “only” a 12 word seed phrase for all new users.

We do still think it’s important to abstract away the foreign concept of seed words whenever possible, but we will always want our users to be able to easily move to other wallets, be protected if we disappear one day, and have full sovereignty when it comes to their private keys. As a result we will always build in strong and seamless support for seed words in our products, and starting soon we will default to 12 words when creating a new wallet in Passport.

Let’s make 12 words the standard.

Dive deeper

If this intro to private key security piqued your interest, we’ve collected our favorite resources on the topic below for you to learn more about how the cryptography and security behind Bitcoin’s immensely powerful design:

A special thank you to Luke Parker, a brilliant developer and cryptographer in the space who helped to review and give detailed feedback in the process of writing this post.

All your wallets, one backup

With the release of our latest update for Passport, we’ve empowered you to leverage your Passport for far more than just a cold storage wallet. The introduction of a new “Key Manager” extension enables two powerful new tools in child seeds and Nostr keys, both of which are derived directly from your Bitcoin seed on Passport and automatically backed up to microSD. All of your wallets under one backup.

As both of these features are entirely new to our products, we’ve set out in this blog post to explain how you can use them, detail some real world use-cases, and walk through how all of this is possible from a simple Bitcoin seed phrase.

BIP 85 done right

While the ability to create nearly infinite child wallets from a single master seed phrase has been around for a few years in BIP 85, the complicating factor has always been how to implement in a way that is intuitive and easy to use. In previous attempts at allowing users to generate child keys they’ve required manual index backups, had no ability to name the keys themselves to differentiate them, and have pushed the feature to only the most advanced Bitcoin users.

As one of our goals at Foundation is to bring Bitcoin self-custody down into the real-world and make it more approachable, we spent many hours working with our design team to make Key Manager accessible for even the least technical users. That work has culminated in an extension that takes one click to enable and then guides you through every aspect of key management, regardless of background or expertise.

Key Manager at a glance

Let’s get to the fun stuff — how does all of this actually play out when using Passport? All you have to do to unlock all of this new functionality in Passport is to enable the Key Manager extension from the settings menu. Just a few presses and you have a new card on your home screen that lets you create and manage BIP 85 child seeds and Nostr keys with a few clicks! View all your keys, distinguish them quickly by unique icons, and manage their names in seconds.

Once you have enabled Key Manager, creating a new key is incredibly straight forward. Simply navigate to the new Key Manager card on your home screen and select “New Key.” Choose how many words you want the seed to be and the new key is automatically saved via encrypted microSD backups. When you need to use the new child seed in another wallet, simply select “Export,” choose whichever format your favorite wallet supports, and import it. It’s that easy.

Using Key Manager in the real world

Still wondering how all of this can help you? Let’s walk through some real-world examples of ways that you can leverage child seeds to simplify and safeguard your Bitcoin journey. Once you’ve secured your Passport backup properly — either by encrypted microSD backups or manual seed backup — you can start creating child seeds for all kinds of uses without the additional headache of needing to back each of them up separately.

One of the most common and immediately useful ways to leverage child seeds is by using a child seed from Passport for your mobile wallet of choice. Simply turn on your Passport, navigate to the Key Manager page, create and name a new key, and then export as a QR or seed words and setup your mobile wallet. In just a few minutes you have a highly secure backup already in place for your new mobile wallet, but can spend easily and freely on the go. This makes pairing Passport with Envoy as a mobile wallet the best of both worlds.

Another common use-case for our more privacy-minded community is to use a child seed from Passport to create a hot wallet for mixing in Samourai Wallet or Sparrow Wallet. You can now easily keep those funds in your mixing wallet while you’re reclaiming your privacy without an additional seed to back up (or potentially lose). You can even leverage Sparrow Wallet to mix from that new child seed directly to Passport using our Postmix extension, bringing privacy to your cold storage without all of the normal headaches. Privacy meets peace of mind.

Lastly, child seeds present an incredible way for those who are more knowledgeable and further along in their Bitcoin journey to help back up funds of close family and friends while they’re learning the ropes. You can generate child seeds for your parents, your kids, or your friends who are new to Bitcoin to help get them started while reducing the risk of them losing precious sats. While this does give you access to their bitcoin, it’s a great temporary tool while they get comfortable using Bitcoin.

But wait, there’s more!

That’s not all that the Key Manager extension enables, though! We’ve also been building out full Nostr key support as a part of the extension, allowing you to leverage the power of child keys to create Nostr keys directly from your Bitcoin seed on Passport. One master backup with Passport and all your Nostr keys are safe and secure.

When you want to create that new Nostr key, it’s as easy as navigating to the new Key Manager card, selecting “New Key,” choosing the “Nostr” option, and then naming it as you see fit. Whenever you want to login to a Nostr client, simply export the new key to QR and scan it from your favorite client (Amethyst currently supports this) or export to microSD as a text file and copy paste if necessary. No more worrying about losing your Nostr key.

While it’s not live in this release, we’ve also been hard at work implementing delegated key signing a la NIP-26 into Passport. This new approach to key management means that you can leverage a child key to sign-in and use Nostr without ever exposing your master Nostr key to the world. This standard and implementation are still in their infancy, but we’re excited to help grow the ways that our users can leverage Passport to empower their freedom in areas outside of Bitcoin alone. We’re thankful for all those working on freedom tech more broadly and we can’t wait to get delegated key signing in your hands shortly.

Driving Nostr forward

Nostr key management is one of the areas where Nostr is very early in development today, so we’ve been working hard as a team to find ways that we can give back to the Nostr ecosystem and help to drive forward mature standards. One of the ways we have worked to improve the ecosystem is by helping expand the standard for Nostr key derivation in NIP-06 to include generating multiple keys properly. We helped to develop and test a derivation method that would allow you to generate practically infinite usable Nostr keys from a single Bitcoin seed and contributed that tested definition to the official repository on Github.

Another key way we have worked to help grow the Nostr key management ecosystem is through funding bounties to implement Nostr key QR login and delegated key use in Amethyst, one of our favorite Nostr clients today. Taking the time to create issues for features you love and drive open bounties incentivizes developers to implement these features and rewards them for their incredible contributions to free and open-source code, something that is absolutely vital to continuing to grow the FOSS movement!

If you’re on Nostr today, be sure to follow us below to keep up with the latest things we’re building, writing, and sharing:

What’s next

We’re also working on expanding the Taproot payments support added in this version into full Taproot support to both send and receive, implementing NIP 26 support as mentioned above, and much more. We hope you enjoy the new features in Passport’s latest firmware as much as we do, and we can’t wait to hear your feedback on what uses you find for child seeds, Nostr keys, and so much more!

If you’d like to learn more about the technical details and usage of Key Manager, you can jump right into our detailed support docs below:

Purchase PASSPORT

In stock and shipping now!

$199.00Add to cart

Bitcoin doesn’t need banks

As governments attempt to stanch the bleeding of citizens waking up to the need for freedom and fleeing the dollar for harder money, they are rapidly shutting down the centralized, surveilled, and regulated on and off-ramps that the Bitcoin ecosystem has relied on for so many years. The resulting tightening of regulation and control should be a helpful push for each of us to explore the tools available for buying and selling Bitcoin as we need without trusting third parties, giving up Personally Identifiable Information (PII), or giving up custody of our Bitcoin.

The search for a powerful and yet easy-to-use peer-to-peer (P2P) platform for buying and selling Bitcoin has been a complicated road, but the last few years have seen rapid growth, added liquidity, and improvements in the tools we have at our disposal. In this post we’ll break down what a P2P exchange is, why we need them, and how you can approach using some of the best out there today.

Why we need P2P exchanges

When Satoshi set out to create Bitcoin, he envisioned a world where Bitcoin freed us from the control and surveillance of third parties, banks, or custodians. A world where we have ultimate control of our money, we contribute to network security through mining, running a node, and paying network fees, and where we can carve out the middle-man we’ve had to endure in the modern financial system. Instead, much of the Bitcoin ecosystem today centers around custodial exchanges that charge fees, collect sensitive information about Bitcoiners and their on-chain activity, and constantly rug pull users intentionally or due to hacks and theft.

What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.

Satoshi Nakamoto

Thankfully, even though these exchanges have dominated the Bitcoin space so far, developers and Bitcoiners have been working tirelessly to build tools that keep the middle-man out of our fiat <> Bitcoin trades and allows us to embrace the intended form of Bitcoin – one that is censorship-resistant, non-custodial, and P2P in nature. Bitcoiners trading with other Bitcoiners is the path towards making Bitcoin much more resilient to attacks by nation states and regulators, and is key for us to be able to continue using Bitcoin with or without the State’s approval. No banks required.

What is a P2P exchange?

Though most of us are familiar with the flow of using a centralized exchange, few Bitcoiners have ventured into the waters of P2P exchanges yet. As a result, the thought of breaking the centralized paradigm and trading directly with other people can be daunting, but thankfully the reality is far more approachable! In a P2P exchange, you’re no longer trading with a faceless corporation or trading desk, but instead you’re working directly with other Bitcoiner’s like you to buy and sell Bitcoin as you need.

While the exact approach to using these tools can differ, the core principle is the same. For this scenario, let’s assume you want to buy Bitcoin:

  1. The platform hosts an “order book,” letting you easily see what amounts are available at what prices.
  2. You select an offer you want to take, and a trade is created between you and the “maker” of the offer.
  3. The maker deposits Bitcoin into a multisig wallet you share to ensure that he can’t run off with your fiat.
  4. You coordinate fiat payment with the maker, usually something like Zelle, Cash App, Revolut, or cash face-to-face or by mail.
  5. Once fiat payment is completed, the maker confirms he received the fiat and releases the Bitcoin to be sent directly to your wallet.

And that’s it! In reality it’s a simple and uncomplicated process, but does differ from the flow we’ve all become accustomed to with centralized exchanges. You just traded fiat for Bitcoin directly with another human without involving any intermediaries, without sacrificing your personal privacy, and without giving up custody of funds to an exchange for a prolonged period of time. P2P exchanges are the future.

Our best options today

So what are you waiting for? Let’s dive into our favorite options out there today, learn a bit about them, and go over some resources that are helpful when getting started. The beauty of a free and open ecosystem driven by people like you is that there is a broad range of tools available, each with a unique set of benefits and tradeoffs.

A quick note: though it might be confusing, most of the P2P options that are widely used still rely on a centralized website in order to find buyers and sellers. However, even though there is a centralized website or platform in most of these tools, they don’t hold your Bitcoin, don’t collect personal information, and merely serve as a gateway to trading safely and securely with other Bitcoiners. Also, the list below is in no particular order, we love all these P2P exchanges equally.

AgoraDesk

AgoraDesk is a platform in the vein of LocalBitcoins (RIP), providing a simple and intuitive platform for buying and selling Bitcoin P2P. When you trade on AgoraDesk, you create a simple profile (no PII involved!), select an offer according to the payment method you prefer, and trade directly with other humans. AgoraDesk also recently launched an excellent open-source mobile app, making it far easier to buy and sell Bitcoin on the go.

How it works

AgoraDesk is a centralized platform with a company behind it that acts as an arbitrator for trades in case of any dispute. When a seller creates an offer, the seller has to lock Bitcoin (equal to the trade amount) in an “arbitration bond,” providing funds that will be used if the seller attempts to back out of the trade or run off with your fiat. If the seller follows through, the appropriate amount of Bitcoin gets sent to you after the seller confirms receipt of your fiat, and all is well. If the seller attempts to steal your fiat or fails to follow through on the trade, an arbitrator gets involved and their arbitration bond (equal to the amount owed to you) is sent to you as compensation.

As long as you read carefully along the way and be sure to follow all steps properly, there is no way that a malicious seller can scam you out of your funds.

More here: FAQ — AgoraDesk

Learn more

  • AgoraDesk’s website
  • AgoraDesk’s Android app

Hodl Hodl

Hodl Hodl is a very similar platform to AgoraDesk, focusing on buying and selling Bitcoin P2P. They never custody your Bitcoin, never hold your fiat, and seek to protect your privacy from the moment you start using their platform. Simply sign up with an email and password, pick (or make) an offer for the payment method you want to use, and get Bitcoin directly to your wallet. No KYC. No middle-man. No custodians.

How it works

Hodl Hodl is also a centralized platform with a company that acts as an arbitrator in the case of a dispute. When you accept an offer, the seller and you create a 2-of-3 multisig escrow along with Hodl Hodl. This multisig ensures that if the trade goes well you and the seller can collaborate to send the Bitcoin to your wallet properly, but if the seller is malicious or fails to follow through on the trade an arbitrator can step in and assist. If the seller fails to follow through, an arbitrator can review the trade and send the Bitcoin to the harmed party (whether buyer or seller), ensuring that good actors don’t lose any funds.

As long as you read carefully along the way and be sure to follow all steps properly, there is no way that a malicious seller can scam you out of your funds.

More here: Hodl Hodl – Why is trading on Hodl Hodl secure?

Learn more

Hodl Hodl’s website

Peach Bitcoin

Peach Bitcoin is one of the newest P2P exchanges to leap onto the scene over the last year, and has become a favorite of many in our community even while it remains in beta. Peach Bitcoin is a simple app that connects you with sellers directly, facilitating trades in a very similar fashion to AgoraDesk and Hodl Hodl but with a focus on mobile, intuitive user experience, speed, and a modern UI.

Peach also helps you backup your app in a self-sovereign way, save fiat payment methods for easier trades, and much more.

How it works

Peach Bitcoin is a centralized platform that acts as the arbitrator in trades. When a seller creates an offer, the seller sends Bitcoin to a 2-of-2 “decaying” (more on that later) multisig wallet that he shares with Peach, ensuring that he can’t send funds without Peach’s approval and Peach can’t steal funds themselves. If the trade goes properly, the seller and Peach will work together to send funds to your wallet directly. If the seller is malicious or fails to follow through, after 30 days the multisig will decay to a 1-of-2 and Peach will control the funds, sending them to the buyer appropriately. This approach allows trades to proceed much more quickly as the seller’s Bitcoin are already locked in the multisig escrow and confirmed on-chain before a buyer even accepts the trade.

As long as you read carefully along the way and be sure to follow all steps properly, there is no way that a malicious seller can scam you out of your funds.

More here: Trading FAQ · Peach Bitcoin

Learn more

Peach Bitcoin’s Android app

Robosats

Robosats is an incredibly innovative P2P exchange built around the Lightning Network, enabling you to buy and sell Bitcoin directly on Lightning from other people across the globe. Robosats can only be used over Tor, ensuring that you have strong privacy from both Robosats themselves and the peers you trade with. 

Not only that, but each time you use Robosats you quickly generate an entirely new “Robot,” giving you a new pseudonym and account to transact under. You should always backup the token Robosats gives you to recover your active trades if you delete the app or close the website while an offer or trade is active. If you’re an active Lightning user, Robosats is an important tool in your toolkit and an awesome P2P exchange.

How it works

Robosats is a centralized platform where they act as an arbitrator in the case of a dispute like the other options, but as it’s a Lightning-centric platform the methods differ. When a seller opens a trade, the seller locks a “fidelity bond” of a small percentage of the total trade amount. When a buyer takes the trade, the buyer also locks a small fidelity bond of the same percentage, and if either buyer or seller fails to follow through in a timely manner their bond is forfeit to the honest party. Once the trade is in-progress, the Bitcoin seller locks funds in an escrow “hold invoice” to Robosats wallet and the buyer provides an invoice of the same amount to Robosats.

If the trade is successful, the fidelity bonds are returned to the buyer and seller appropriately, and the locked hold invoice pays out to Robosats, who then pay out the full amount to the buyer’s provided invoice. If the trade is unsuccessful and one party is malicious and tries to game the system, a dispute can be opened where an arbitrator steps in and determines the honest party, rewarding them the fidelity bond of the malicious party and sending the sellers Bitcoin to the buyer if fiat has already changed hands.

As long as you read carefully along the way and be sure to follow all steps properly, there is no way that a malicious seller can scam you out of your funds. Note that in order to make your first trade on Robosats you do need to already have Bitcoin in order to lock the fidelity bond upon making or taking a trade.

More here: 

Learn more

  • Robosat’s website
  • Robosat’s Android app
  • Robosat’s rapid volume growth, image by Kevin Rooke

Bisq

Bisq is the only P2P exchange for Bitcoin that is truly decentralized in nature and does not rely on a single website or entity for its functionality. This makes Bisq an extremely resilient platform for buying and selling Bitcoin, even in the harshest adversarial environments around the world. Bisq operates as a standalone desktop app that natively integrates the Tor network for preserving your privacy when communicating with the Bitcoin network, the Bisq network, and your trading peers.

While Bisq doesn’t have the more familiar UX of other options we’ve given, it provides an option that is viable in almost any scenario and should be much more resistant to pressure over the long run.

How it works

Bisq stands apart from the other options on this list due to its true decentralization, and as a result has a slightly different model for security. When a seller creates an offer and when a buyer takes an offer, both buyer and seller lock security deposits (with the amount being set by the seller). When the trade begins, the Bitcoin being sold is sent to a shared 2-of-2 multisig wallet between the buyer and seller, ensuring that neither party can steal funds from the other. If the trade is successful, the buyer and seller both sign to send the funds to the buyer’s wallet directly. 

If either party is malicious, a dispute can be opened where arbitrators from the community are engaged to help decide the honest and malicious parties and properly award the security deposits. If no resolution can be reached between both parties, the funds can be sent to a Bisq community donation address by either party and the arbitrator can reimburse the honest party from the Bisq DAO.

As long as you read carefully along the way and be sure to follow all steps properly, there is no way that a malicious seller can scam you out of your funds or prevent you from being reimbursed by an arbitrator. Note that in order to make your first trade on Bisq you do need to already own Bitcoin, as you must lock a security deposit when making or taking offers.

More here: Frequently asked questions – Bisq Wiki

Learn more

Bisq’s desktop app

Azteco Vouchers

Azteco is an entirely different beast, and actually not a P2P exchange at all so we’ve added it as a bonus! Azteco is on this list still as it provides a powerful way to buy Bitcoin directly from corner shops and retailers in many countries without providing ID or even creating an account anywhere. Azteco does this by creating Bitcoin vouchers (just like those “top up” SIM cards) that you can buy for cash or with a credit card in person. Simply buy a voucher in person, go to azte.co, and redeem the voucher directly to your Bitcoin wallet. Azteco has many of the same benefits as normal P2P exchanges, and is a great option if you want to buy in person but don’t have any P2P sellers in your area on something like AgoraDesk or Hodl Hodl.

How it works

Azteco is obviously very different from the other options listed here, and is entirely custodial until you redeem the voucher given to you when you purchase. As such there is no risk of a malicious peer stealing your Bitcoin, but of course you are trusting Azteco to properly send the Bitcoin when you go to redeem the voucher!

The only key thing to watch out for is to be sure the Azteco vendor you choose is properly listed on their site before buying a voucher to prevent unknowingly buying counterfeit vouchers.

More here: Azte.co

Learn more

Azteco’s website

What to look forward to

We’ve only scratched the surface of what can be built for empowering use of Bitcoin without needing banks, and the recent explosion is strong evidence that the concept of P2P exchanges is taking off. We’ve been thrilled to see new apps like Peach Bitcoin and Robosats rapidly growing in volume and usage, and can’t wait to see what ingenious tools get built in the coming years. As more and more Bitcoiner’s start to use P2P exchanges to buy and sell Bitcoin, the future becomes brighter for how easy these tools are to use, how much liquidity is available, and how much funding goes to building them out.

We hope that this list gives you practical ways that you can start to use Bitcoin without involving the traditional banking system, enabling you to access Bitcoin without permission and without surveillance. Now let’s get out there and build a better world with Bitcoin at its core.

Privacy on Nostr

Nostr has been taking the Bitcoin world by storm over the past few months, and with it comes a chance to correct the mistakes of the current social media paradigm. While the actual use-cases for Nostr are practically limitless, the overwhelming majority of usage today has come in the form of a censorship-resistant and Lightning-centric social media platform built around user choice. Nostr takes a novel approach to its network design, and we want to be sure that Nostr users like yourself are well-equipped to use Nostr in a way that preserves your privacy and security from the start.

What is Nostr?

Nostr is a new protocol (think TCP/IP or HTTP, like what your browser uses) that focuses on the very simple goal of publishing and reading events in a distributed way. It does this by allowing anyone to run a client (how you read or write events) and/or a relay (how you share events with others). Each relay communicates only with users who choose to send or receive events using it and not with other relays, a significant departure from Bitcoin’s model – called a “gossip” model, where all servers share events with all other servers they know – and the approach taken by the Fediverse, where servers that can communicate and share events but do not have to.

This new protocol is extremely simple and diverse by design, allowing a plethora of apps and services to be built on top of it, but the most traction so far has come from its use as a social media platform. Nostr provides a strong base for a user-centric social media platform, as you, the user, have complete control over where your posts are shared (which relays), which users you see or don’t see in your feed (by following specific users or only reading from specific relays), and what client you choose to use to post or consume content.

When you post to Nostr, your client simply translates the content you write into a format called JSON, signs it with your private key to prove it’s from you and cannot be tampered with, and publishes it to relays you’ve selected. Everyone who follows you and connects with relays you publish to will see your content in their timeline exactly as intended. When you browse Nostr, you see only content from people you choose to follow, in chronological order, without advertisements or algorithmic wizardry causing issues. Simple. Clear. Social media as it should be.

If you want to learn more about Nostr, you can read some excellent resources below:

Nostr’s privacy tradeoffs

The proxied-relay approach that Nostr takes is excellent at decentralization and censorship-resistance, but one thing it doesn’t do well is protect a user’s privacy by default. Because you need to connect to many different relays to communicate with most people using Nostr today, you’ll be exposing your IP address (your unique identifier on the internet) to every relay you connect to, directly associating your IP address to your digital identity on Nostr. This could be used to connect your Nostr identity with other online activity, connect multiple Nostr identities you control together without your consent, and even give the relay operators a rough idea of where you live.

Another key issue with the approach taken by Nostr is that there is no central server used for hosting media like pictures and videos, so users have to upload media to a server of their choice to share it. As a result, your Nostr client will have to connect to any number of untrusted servers hosting media to properly show you pictures and videos in your feed. While this does remove trust in a centralized server, it also exposes you to tracking or malicious content from third parties that you may or may not want to connect to. Thankfully, most Nostr clients are starting to prevent loading of content from untrusted sources, but this still poses a broad risk to your privacy and security.

Lastly, there are two more minor privacy caveats with Nostr that are important to know, but don’t necessarily present a problem for the average user. The first is that direct messages in Nostr use public events where the message content is encrypted to the recipient’s private key, meaning that while all message content is private by design, the metadata about who you talk to, when, is completely public information. The second minor privacy issue in Nostr is that Zaps, a Lightning tip sent for a specific note on Nostr to show that you loved the post, are public by default and reveal the amount, timing, and any comment included to the entire Nostr network. While this is the default, clients like Damus and Amethyst are working on ways to allow you to send “private Zaps” which encrypt all information except time and amount to the recipient, hiding the sender and any comments from everyone else on Nostr.

Protecting your keys

One of the foundational ways to preserve your privacy involves making sure that no one else ever gets access to your private keys. In Nostr, in order to access your account, post notes, and respond to others, you have to be able to sign events on the Nostr network with the correlated private key for your account. That means that every Nostr app requires a way to sign using your private key, leading to less than ideal security with many of the current approaches. 

When approaching Nostr, you should aim to minimize how often you expose your private key to apps and restrict access as much as possible to your private key. In order to limit how often you expose your private key to apps, the best way on mobile is to choose a client, sign in with your private key, and stick with it if at all possible. Unfortunately, you’ll currently have to copy and paste (or manually type out) your private key (the key starting with ‘nsec’) to sign into mobile apps, but won’t need access to your private key on mobile after the initial sign-in.

When you’re using desktop apps, particularly web apps like iris.to or nostr.social, you can limit exposure of your private keys by using a browser extension to store your private key in an encrypted manner and authorize access to it. That way, you can paste your private key into a trusted extension once and use any web app you like after that without directly exposing your private key to each app. We recommend the most popular and trusted extensions below:

  • Nos2x (Chrome/Brave-only)
    • Nos2x is an extremely simple extension for key management without any bells or whistles
    • If you’re on Firefox, you can use this fork
  • Alby
    • The popular Alby extension added native Nostr key support, and pairs well with it’s Lightning functionality for Nostr Zaps
  • Flamingo (Chrome/Brave-only)
    • Flamingo is another simple Nostr extension with a beautiful UI
Logging into nostr.social with the Alby extension

While we’re working on some unique ways to leverage Passport for Nostr key management, the best way to store your private key for Nostr will be to treat it like a sensitive password and store it in an end-to-end encrypted password manager like Bitwarden. Bitwarden is an amazing tool for managing your online life through storing usernames, passwords, and email addresses for all of your accounts and auto-filling them via their browser extension, and Nostr private keys are a great fit. Bitwarden is free and open-source, and uses strong end-to-end encryption to ensure that even if Bitwarden was malicious they couldn’t view what sites you access or any of your login information. You can easily store your Nostr private key as an item in Bitwarden, allowing you to enter it as needed on desktop or mobile easily.

Protecting your IP address

The next key step to take is to prevent relays and media hosting servers from learning your true IP address, and the easiest way to do that is to use a trustworthy and dependable VPN provider. While a VPN provider isn’t a perfect solution to network privacy issues, it does allow you to shift the trust from your network provider (home ISP, mobile carrier, etc.) to a 3rd-party you trust more than them (and that don’t have your personal information or address). Once you’re using a VPN, you’re actively preventing the sites, apps, and tools you interact with online from learning your home IP address and connecting all of your activities back to you.

Our team is a big fan and many of us are users of two well-known VPN providers in the space which we’ve linked below for easy reference. Both IVPN and Mullvad accept Bitcoin (on-chain and Lightning) for subscriptions and require no information from you to create an account, not even an email address!

Using IVPN on desktop via their native app

Please note that we have no direct affiliation with either provider and don’t profit off of your use of either, we just love their approaches and use them ourselves.

Choosing the right relays

Nostr takes the idea of self-sovereignty and personal responsibility as a core ethos, as you are in complete control of your data and your usage of the protocol. As each Nostr relay you connect with gets information about your IP address (hopefully just a VPN address if you followed the above recommendation), when you’re using Nostr, when you publish events, and who you interact with. While much of this information is public – and has to be so for a useful social media platform – being able to selectively reveal this information is an important benefit of Nostr.

While relay selection is certainly a personal preference as it changes what notes you can view and who can see your notes, limiting it to the bare minimum provides better privacy and generally better performance in your Nostr clients at the same time. The use of paid relays can also be helpful, as they limit spam and access to your public data behind a paywall. The list of relays and their usefulness changes frequently at this early stage in the network’s development, but we’ll provide a few recommendations below that are widely recommended:

  • nostr.wine
    • Nostr.wine is a paid relay that has a stellar reputation and a unique additional service that paid users can leverage
    • Their filter/broadcast service allows you to publish events to the most popular relays through their relay
      • More on their filter/broadcast service here
  • nostr.mutinywallet.com
    • This relay is actually just a proxy that publishes events for you to all known relays using a tool called Blastr
    • This can be a great single write-only relay, ensuring your notes make it to pretty much the entire Nostrverse
    • Note that if you do use only this relay proxy to write to, you do open up censorship as they could choose not to relay your events for some reason! If that’s a concern for you, consider writing to multiple relays.
  • relay.nostr.band
    • This relay applies a trust-based spam filter to all events, providing a much better global feed than most and serves as a good read-only relay

Adding these relays to your client will vary depending on which client you choose, so please check out the documentation of your favorite client or check in the settings! You usually will have to add a ‘wss://’ before the relay address as well.

Getting started with Nostr

If you’ve read through this post and want to jump into using Nostr, we’ve learned a few things as team members have jumped onto the Nostr train. We’ll drop recommendations based on this below in a rapid-fire style, but feel free to reach out with questions and we’d be happy to help point you in the right direction!

Choosing a client

Choosing a client is ultimately down to personal preference and depends on what platform you use (Android, iOS, Windows, etc.), but some of our favorites are:

  • Amethyst (Android-only)
    • Vitor Pamplona, the lead dev, has done a fantastic job building out Amethyst and it feels like he releases a new major improvement every day. Amethyst is a fantastic client top-to-bottom, and is what both Seth For Privacy and Bitcoin QnA use on our team.
  • Damus (iOS-only)
    • Damus has become a huge part of Nostr adoption, driving new features and bringing a snazzy Nostr experience to the Apple crowd.
  • snort.social (web client)
    • snort.social is a great client for using on desktop or on mobile as a progressive web app, and is quickly improving and innovating as well.
  • Iris.to (web client)
    • Iris.to is another great web client and is quickly becoming the go-to for web.
Amethyst on Android’s UI as of v0.24.0

Verifying your Nostr account

Nostr takes a very different approach to Twitter, allowing all users to be “verified” through the use of DNS and a simple web server. While we definitely recommend pursuing the fully self-sovereign approach to verifying your account on Nostr and hosting it yourself, we recognize that not everyone can do that so we’ve included some trusted Nostr verification services as well below:

  • For more info on verification, you can read more here
  • NIP-05 Simple Guide (self-hosted)
    • This guide walks you through the process of setting up verification start to finish, and is recommended widely.
  • Easy-nip5 (self-hosted)
    • Our very own Seth For Privacy has created an easy-to-use way to do your own self-hosted verification using Docker, allowing you to quickly set up the full verification on a VPS with your own domain name
  • Bitcoiner.chat (trusted)
    • Bitcoin QnA has set up an easy to use tool to get a verified account using his domain, bitcoiner.chat, for free! This is an excellent solution for those of you who can’t self-host your own verification, and is provided by one of the most trustworthy people in the space, if we do say so ourselves.
  • Nostr Plebs! (trusted)
    • Nostr Plebs is one of the original NIP-05 verifiers, and is run by a fantastic Nostrich named Derek Ross.
A NIP-05 verified account, see the purple check-mark

Conclusion

We’re thrilled to watch the progress being made in a Bitcoin-centric social media platform that puts the user first, as it embodies so much of what Foundation is all about. We hope that this short guide helps you get started with Nostr in a way that allows you to preserve your privacy and security from the start, and we look forward to seeing you all over there.

If you’d like to follow us on Nostr you can find our official company account along with a few of our team members below!

  • Foundation
    • foundationdevices.com
    • npub1s0vtkgej33n7ec4d7ycxmwt78up8hpfa30d0yfksrshq7t82mchqynpq6j
  • Seth for Privacy
    • seth@sethforprivacy.com
    • npub1tr4dstaptd2sp98h7hlysp8qle6mw7wmauhfkgz3rmxdd8ndprusnw2y5g
  • BitcoinQnA
    • qna@bitcoiner.chat
    • npub15c88nc8d44gsp4658dnfu5fahswzzu8gaxm5lkuwjud068swdqfspxssvx
  • nickmonad
    • nickmonad.blog
    • npub1tln5mjd8xjd7rqnfqp7cu77lwkvcd89kwllr7fu5a0vzru2xl6qssuq0v6
  • Jack Smith
    • npub1d8mwl982z209f3zf856t87z36gmavgctw59r30pxr880emxmjy6sq4qtwj

Making sense of stealth addresses

In our previous blog post we briefly touched on how important it is to protect the privacy of the recipient in a transaction. Today we’re going to take a closer look at a specific way to preserve privacy – “reusable payment codes”, otherwise known as “stealth addresses.” While the concept of the reusable payment code is not a new one – a form of them was officially proposed as a Bitcoin Improvement Proposal (“BIP”) in 2015 by Peter Todd – they’ve become a popular topic again after two recent proposals on new ways to implement them.

Today we’ll walk through why we need reusable payment codes, how the current approaches differ, and how you can start using them today.

Why do we need reusable payment codes?

If you’ve ever had to receive Bitcoin multiple times from the same person before, you’ll know that there is a seemingly simple choice to make – do you generate a new address for them each time (and communicate it somehow), or do you tell them to re-use the same address? If you choose to generate a new address each time, you have to actively communicate somehow, send them the address, and hope they copy and paste it correctly each time. If you instead choose for them to reuse a single address, you harm the privacy of both participants in order to simplify repeat payments.

For a real-world example, consider the case of wanting to accept donations as a political dissident. If you choose to post a single static Bitcoin address, you put every donor (and yourself) at risk of trivial surveillance in order to simplify the process for you and your donors. If you choose to generate a new address for each donor, you have to run extra infrastructure like BTCPay Server or SatSale, increasing the difficulty exponentially and requiring some technical know-how. We’ve even seen a recent example of this in donations raised by Russian opposition leader Alexey Navalny, easily visible to anyone with a blockchain explorer and actively surveilled by the Russian pro-Putin government.

The dilemma in both of these simple cases is exactly what reusable payment codes seek to solve, allowing you to provide a single static string of characters (a “code”) that can be reused as many times as necessary – even by multiple senders – without sacrificing privacy or requiring online communication with the recipient. To better understand how this type of tool presents a solution, we need to dig into each of the current proposals, including the only current live implementation of reusable payment codes, PayNyms (or BIP 47).

Where did the idea of reusable payment codes come from?

The original idea for reusable payment codes (originally called “stealth addresses”) is over a decade old at this point, originally being proposed in 2011 on the Bitcoin Talk forums and then unofficially given a BIP number (63) in 2015 after a proposal by Peter Todd in early 2014. This proposal never gained traction and was abandoned by the author when a change to Bitcoin’s OP_RETURN field broke his approach.

This original proposal shares many similarities to PayNyms, Silent Payments, and Private Payments, using a set of keys combined into one long payment code to allow senders to generate unique addresses for the recipient and leveraging the OP_RETURN. This approach is simple and relatively easy to implement, but relied on a large OP_RETURN field (something that was reduced shortly after it was proposed) and made every payment utilizing stealth addresses stand out on-chain. Even with its drawbacks, this was a major step forward and would form the foundation for future proposals.

Reusable payment codes become a reality

The next proposal to build on the work of Peter Todd was presented in BIP 47 and ultimately became what we know today as “PayNyms.” BIP 47 iterated on the stealth address proposal by utilizing a single notification transaction to signal to the recipient to watch for payments to a specific public key (and thus set of addresses) instead of including payment code signaling in every payment. While there are multiple versions of BIP 47, as the only one in use is version 1 we will focus on that in this post. For simplicity’s sake, for the rest of this post let’s have “Alice” represent the sender in a transaction, and “Bob” represent the recipient who is using a reusable payment code.

How it works

When Alice goes to send funds to Bob, her wallet uses the reusable payment code she got from Bob to generate a unique shared secret by combining (1) a private key from an output she owns, (2) the public key in Bob’s reusable payment code, and (3) a 64-byte blinding factor so that only Bob can interpret the shared secret. Alice’s wallet then converts this payment code to binary and inserts it into this notification transaction’s OP_RETURN field in order to let Bob know where to expect future payments from her. 

Both Alice and Bob have to be extremely careful not to link this notification transaction (or the inputs or outputs) with other transactions, as that could provide an on-chain link between their wallets and undo privacy gained from using BIP 47 reusable payment codes. Thankfully, current implementations in Samourai and Sparrow Wallet hide this “toxic” output associated with the notification transaction by default to protect both sender and recipient.

When Bob wants to check for received funds, he monitors his notification address, and when a transaction is received to it he (1) validates that it includes a BIP 47 payment code, (2) decrypts it with his private key, and then (3) stores the information on the set of addresses Alice can send to and watches them like any normal Bitcoin wallet. Even though this notification code is publicly visible on the blockchain, it is encrypted in such a way that only Bob can deduce the addresses it is used to generate, and thus all of Alice’s future payments are known only to Bob. Alice can now send as many payments as she would like to a unique address every time, and Bob can easily watch for new payments with both “light” wallets and “full” wallets.

A example BIP 47 notification transaction, note the OP_RETURN output

Advantages and trade-offs

BIP 47 holds the unique status of being the only form of reusable payment code to actually be implemented and widely used thanks to the efforts of the Samourai Wallet team, who have implemented BIP 47 as “PayNyms.” PayNyms are leveraged in Samourai Wallet, Sparrow Wallet, and Stack Wallet, allowing any user to easily share a reusable payment code or register their PayNym with Samourai Wallet’s servers to get a short version of their reusable payment code like “+shrillsurf491.” This short form of their reusable payment code can then be looked up by any PayNym user on Samourai’s servers and resolved to the full payment code, allowing them to then send payments in a privacy-preserving way.

While BIP 47 does have the major drawback of requiring a notification transaction for funds to be easily recovered, this is outweighed by the ability for light wallets to utilize reusable payment codes and the simplicity of implementation, making it very easy for wallet developers to add support for BIP 47 reusable payment codes to their wallets.

While BIP 47 does have the major drawback of requiring a notification transaction for funds to be easily recovered, this is outweighed by the ability for light wallets to utilize reusable payment codes and the simplicity of implementation, making it very easy for wallet developers to add support for BIP 47 reusable payment codes to their wallets. This has led to rapid growth and adoption of BIP 47 and PayNyms in a way that no other proposal has seen so far.

Doing away with the notification transaction via Silent Payments

Some Bitcoin developers consider the trade-offs inherent in BIP 47 too harmful, and have sought ways to implement reusable payment codes without needing an on-chain notification transaction, but no other proposals gained interest until 2022. However, in March of 2022 Ruben Somsen proposed “Silent Payments,” a new approach to reusable payment codes that removes the need for a notification transaction entirely by leveraging the outputs in a transaction to signal to the recipient when funds are intended for them. Silent Payments makes use of advances in Bitcoin scanning to remove the need for a notification transaction, thereby improving scaling and privacy associated with reusable payment codes (with a key trade-off we’ll address later).

How it works

When Alice goes to send funds to Bob, she takes three keys and creates a unique one-time address that only Bob controls the keys to. These three keys are the (1) public key of the output(s) Alice wants to send to Bob, (2) Bob’s public key in his reusable payment code, and (3) a shared secret (generated using the same cryptography as stealth addresses and BIP 47, “ECDH“) that only Alice and Bob know. These three keys combine into a unique one-time address that Bob can then validate and spend from, allowing Alice to generate practically infinite addresses without any communication with Bob. This payment appears exactly like any other payment using the same script type (i.e. Taproot), thereby preventing an outside observer from even knowing Silent Payments were used at all, much less link payments to a Silent Payment address together.

When Bob wants to check for received funds, he takes (1) the private key from his payment code and (2) the aggregated key across the inputs of every transaction on-chain and checks to see if the combination matches an output in a transaction. If it matches, that output is owned by his private key and he can spend it at will, and if it doesn’t match he simply ignores that transaction and continues scanning. This process of checking every input in transactions is relatively costly and requires a full node, but does preserve privacy and remove the need for problematic notification transactions entirely. 

An example testnet SIlent Payment transaction, note that it looks like any other standard Taproot transaction

Advantages and trade-offs

[This] brings us to the significant trade-off of Silent Payments: because this scanning is relatively costly and can only be performed with a full Bitcoin node, Silent Payments necessarily do not work on light wallets, limiting their usage in practice.

Because with Silent Payments Bob must scan all transactions on the blockchain from the point that he generated the payment code, it brings us to the significant tradeoff of Silent Payments: because this scanning is relatively costly and can only be performed with a full Bitcoin node, Silent Payments necessarily do not work on light wallets, limiting their usage in practice.

While Silent Payments present a unique and useful set of trade-offs in comparison to BIP 47, they have not yet been implemented in any wallet and thus cannot be used by the average person. Silent Payments are particularly useful when you only want to send a single payment or donation to a given reusable payment code, as they do not require a separate notification transaction and so are cheaper and more efficient than the alternatives available today. It will be interesting to see if Silent Payments catch on, but for now you can follow the conversation on the topic on Github for future developments.

BIP 47 with a twist: Private Payments

Last but not least, the newest kid on the block is BIP 351, or “Private Payments.” Private Payments strikes a middle ground in trade-offs between BIP 47 and Silent Payments, minimizing the potential impact and issues of a notification transaction (while still requiring one) and reducing the scanning requirements to only scanning OP_RETURNs (while still requiring a full node). Private Payments was proposed in July of 2022 by Alfred Hodler and Clark Moody, and is the latest approach to reusable payment codes.

How it works

When Alice goes to send funds to Bob, she takes (1) Bob’s public key encoded in his payment code and combines it with (2) a shared secret she generates to create a unique one-time address to use for a notification transaction. She then generates a unique notification code to include in the OP_RETURN of the notification transaction, creating a transaction that does not re-use a notification address (unlike BIP 47), but does stand out on-chain (unlike Silent Payments). Once she has sent this notification transaction, she can then generate a new, unique address for each subsequent payment to Bob without any links on-chain, and no direct link between any of her UTXOs and Bob’s notification address.

When Bob wants to check for received funds, he checks the OP_RETURN on every transaction since he generated his payment code for those with OP_RETURNs including a notification code that matches his private key. When he finds one that matches, he can then add all derived addresses to a watch list and monitor them for transactions just like a normal Bitcoin wallet. As this only requires checking the OP_RETURN field in each transaction instead of performing validation of every input and output, it’s necessarily much lighter on requirements than that of Silent Payments. While this still precludes the simple usage of light wallets (similar to Silent Payments), it would be easier to off-load the validation of OP_RETURNs to an external (trusted) service.

Advantages and trade-offs

As Private Payments requires both a notification transaction and a full node for proper scanning, it strikes something of a balance between the two other proposals without fully gaining the benefits of BIP 47’s notification transactions and the ability to use light wallets, or the scaling and privacy improvements from the omission of a notification transaction in Silent Payments. It could still pose an interesting approach for light wallets that are willing to trust an external OP_RETURN validation service, however, and gives us a great example of the continuing innovation and exploration around how we can best approach reusable payment codes.

Using reusable payment codes today

If you’ve read through this and are wondering how you can actually use this fascinating technology today, I’ve got great news for you – BIP 47, or PayNyms, are extremely easy to use today with both Samourai Wallet and Sparrow Wallet. Both have well-implemented native support for reusable payment codes, making it extremely easy to create one (all hot wallets have one by default) and to send to a reusable payment code. For the relevant documentation on using PayNyms in both wallets, you can jump in below:

If you’re not currently using one of these wallets, using reusable payment codes is unfortunately often not supported as it does require a bit of work for wallet developers to implement. There is, however, ongoing work by an independent developer to implement BIP 47 PayNyms in Blue Wallet, and we at Foundation are eager to implement PayNyms into Envoy in the future. Outside of using Samourai Wallet. Sparrow Wallet, or Stack Wallet, you can help along the growth of reusable payment codes by talking about the need on social media, following the relevant conversations and BIPs, and donating to developers and projects working on innovation and implementations along the way.

Why we love encrypted microSD backups

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:

  1. The onboard CPU’s random number generator
  2. The secure element’s true random number generator
  3. 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:

  1. All device configuration, accounts, account names, and multisig configurations are fully backed up and automatically restored when using microSD backups
    1. 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
  2. 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
    1. Just be sure not to also give them the passcode!
  3. 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
    1. Just be sure not to also store the backup file there!
  4. An attacker or thief finding either your backup file or passcode would not be able to easily tell that they are Bitcoin-related
    1. There is no reason for an attacker to suspect that a microSD card or 20-digit passcode would be worth stealing
  5. 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:

  1. You must have both the 20-digit passcode and encrypted backup file to restore funds
    1. I.e. if you lose either one you will be unable to restore funds!
    2. This means that microSD backups do introduce a second single point of failure
    3. Advantage #3 above greatly reduces this disadvantages impact, practically
  2. If you store both the encrypted backup and passcode together, it provides no added security over a plaintext seed phrase
  3. 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
    1. 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.

What We Protect

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.

Transaction ID: 01b668043b819fd812dd861c2d28deba04136751af087386dc5b991beb73493a

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:

  1. Always use a new receive address
    1. If your current Bitcoin wallet doesn’t do this automatically, it’s far past time to switch!
  2. 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
  3. Use as few inputs as possible (only one, if possible!) when sending a transaction
    1. Thankfully most good Bitcoin wallets will do this for you by default!
  4. Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can easily enable this if they’re using a hot wallet!)
    1. Read our guide on doing just that when buying a Passport: Buying Passport Privately Using CoinJoin
  5. 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
  6. Use wallets like Samourai Wallet and Sparrow Wallet which automatically create dummy CoinJoin transactions whenever possible to obscure the sender (often called a “STONEWALL” transaction)
  7. Use wallets like Samourai Wallet and Sparrow Wallet to create collaborative transactions that obfuscate the true sender and input (often called a “STONEWALLx2” transaction)
Graphics explaining STONEWALL and STONEWALLx2 transactions

Protecting the amount sent

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?

  1. Avoid using rounded amounts (i.e,. 0.01 BTC) when sending funds unless necessary
  2. Avoid using specific fee amounts (outside of 1sat/vbyte, of course) and allow your wallet to calculate fees appropriately
  3. Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can easily enable this if they’re using a hot wallet!)
  4. Use wallets like Samourai Wallet and Sparrow Wallet and create a “STOWAWAY” transaction with other Samourai and Sparrow users to hide the amount being sent and true input

Protecting the recipient

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?

  1. Avoid re-using addresses when receiving funds
  2. 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
  3. 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!)
  4. Use wallets like Samourai Wallet and Sparrow Wallet to create collaborative transactions that obfuscate the true sender, receiver and input (often called a “STONEWALLx2” transaction)
  5. Use wallets like Samourai Wallet and Sparrow Wallet and create a “STOWAWAY” transaction with other Samourai and Sparrow users to hide the amount being sent and true received output
Graphic explaining a STOWAWAY transaction

Protecting the source node

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?

  1. If you run your own Bitcoin node, set it to only use the Tor network for communication
    1. This option is controlled by `onlynet=onion` in the config file, read more on the topic here
  2. Broadcast transactions manually via the Tor Browser and a service like mempool.space
    1. Only do this over Tor, never via clearnet!
    2. The current Onion address of the mempool.space broadcast tool is here
  3. 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!

Becoming a Bitcoiner of Action

Can we all just “hodl” for a better future, or is there more to changing the world around us than passively collecting more Bitcoin? We at Foundation saw that we could do more than just “hodl,” so we started this company out of a desire to help empower more people to reclaim their digital sovereignty. What else can each of us do to help drive Bitcoin and the world around us towards a better future?

While simply “hodling” is a unique approach that is only possible because of Bitcoin, we who understand the impact Bitcoin brings, the need for financial sovereignty, and the weight of issues in society have a responsibility to find ways to help others along the path as well. Once we’ve learned about Bitcoin for ourselves and benefited from it, we have powerful knowledge and experience that we can use to bring about a better world far more quickly.

In this blog post we wanted to lay out some actionable steps that the average Bitcoiner can take to find how they can best impact those around them, improve Bitcoin, bring widespread adoption, and empower others to become sovereign individuals as well. While this is by no means an exhaustive list, we think this is a great place to start.

Join a local Bitcoin meetup

It may seem incredibly simple, but one of the most profound ways each of us can help to spread adoption and help others (and ourselves!) is to get plugged into our local community of Bitcoiners. Meetups allow us to build relationships with other Bitcoiners while contributing thoughts, ideas, and time to educating others. Joining a meetup also helps grow the circular and parallel economies forming around Bitcoin and gives us a local lifeline in case things quickly go downhill. It’s impossible to overstate the importance of having a strong community around you, and a local Bitcoin meetup is the best place to find that.

“Meetups are one of the most high-signal places to learn about Bitcoin and self-sovereignty. I’ve met so many great friends from our local meetup – if you don’t have one in your area, consider starting one!”

Mitch, Co-organizer of KC Bitcoiners meetup

Finding a meetup can be as simple as asking around on Twitter, searching Meetup.com, browsing Bitcoin-Only.com’s list, or if there aren’t any around you – kicking one off yourself! These meetups don’t have to be highly organized and technical, they can be as simple as meeting at a bar or restaurant once a month to chat about all things Bitcoin. Don’t overthink the details, just start gathering Bitcoiners together and watch amazing things happen.

Educate others around you

You may not consider yourself an educator, but even someone relatively new to Bitcoin has a wealth of knowledge that the vast majority of people in the world simply do not. Even the “simple” things like setting up a mobile wallet, storing a seed phrase, or using a hardware wallet like Passport can be immensely helpful to newcomers in the space. Not only that, but having a friendly face or nym that new Bitcoiners can go to with questions or concerns eases the incredibly daunting early days in the Bitcoin rabbit hole. We can help more Bitcoiners stay the path towards self-custody without losing sats along the way by easing the barrier of entry through education and community.

“We all stand on the shoulders of giants. As Bitcoiners we have an obligation to pass on learned knowledge to those around us. This is how we continue to spread the mind virus. This is how we win.”

BitcoinQnA, Head of Customer Experience at Foundation

Educating others also has a powerful personal benefit – when you learn something well enough to teach others, you ingrain a deep and lasting knowledge for yourself that further empowers you towards digital sovereignty.

You know best what communities could benefit from your experience and expertise, but some potential places to contribute could be Twitter (even if you have a small account, it makes a difference!), the Telegram group for your favorite Bitcoin wallet or project, a local Bitcoin meetup, your friends or family, etc.

Contribute and donate to Bitcoin FOSS projects

Want a way to benefit Bitcoin as a project along with a burgeoning free and open-source (FOSS) ecosystem? There are many projects in the broader Bitcoin and sovereignty space that could use your help, starting with simple contributions that don’t even require technical expertise. Taking the time to give back to one of your favorite projects by helping out newcomers in their Telegram or chat rooms, opening issues on Github when you find bugs or want to recommend features, writing or translating documentation, or simply promoting the project on social media can be a huge boost as well.

One of the easiest ways to give back to these projects is to actually use Bitcoin as money and press send. The FOSS space has notorious issues with invaluable projects not getting enough funding to be sustainable, causing us to lose amazing contributors, important apps and tools, and for the spread of Bitcoin and freedom to be slowed.

Bitcoin has uniquely enabled FOSS projects to get funding directly to their wallets without any custodian, middle-man fees, or payment processor. Let’s find ways to leverage this new-found wealth and electronic cash to help fund the next generation of FOSS projects and bring digital sovereignty to more individuals around the world.

“Seeing a donation (especially in the beginning) means the world to a FOSS team like us [RoninDojo], it’s validation that what we are doing matters and keeps us moving forward.”

BTCxZelko, Co-founder of RoninDojo

We don’t want to play favorites, but some excellent FOSS projects in the space that can be funded by Bitcoiners like you and me can be found below (with links directly to their donations pages):

And if none of the above projects strike your fancy or you aren’t sure how to pick one, an easy way is to donate to OpenSats general fund (more on that next).

Donate to OpenSats

Do you find it too difficult to select a contributor, FOSS project, wallet, or educator in the space to donate to? Then OpenSats has you covered. OpenSats is a registered charity in the US, allowing US citizens to count donations as tax-deductible, allowing you to grow the ecosystem while saving some fiat from the tax man. OpenSats allows you to contribute to individual vetted projects and contributors, or to simply donate to the General Fund and trust OpenSats to distribute the funds in a way that aligns with your ethos.

“Thousands of open source contributors make this movement possible. We created Open Sats to support them without relying on corporate sponsors. No strings attached, 100% pass through, tax deductible or anonymous.”

Matt Odell, Co-founder of OpenSats

OpenSats even allows you to donate fiat if you can’t bear to part with your Bitcoin, an invaluable on-ramp for fiat-to-FOSS. If you want to learn more about OpenSats, be sure to check out their website or follow them on Twitter.

Find your niche

If we haven’t hit on a particular passion or area of interest for you in this post, don’t worry! We all have unique talents, passions, and expertise that enable us to be Bitcoiner’s of action. There is a place for each and every one of us to take actionable steps towards bringing digital sovereignty to more people around us, and you know best what that role could be for you. 

Take a few minutes today to pause and think on how you could give back to the projects and communities that have impacted you in your journey down the Bitcoin and sovereignty rabbit holes.

Security

Resellers

Podcast

Jobs

Privacy

Warranty

Terms

PGP


© 2023 Foundation Devices, Inc.

Questions? hello@foundationdevices.com