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:
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:
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:
The platform hosts an “order book,” letting you easily see what amounts are available at what prices.
You select an offer you want to take, and a trade is created between you and the “maker” of the offer.
The maker deposits Bitcoin into a multisig wallet you share to ensure that he can’t run off with your fiat.
You coordinate fiat payment with the maker, usually something like Zelle, Cash App, Revolut, or cash face-to-face or by mail.
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.
This step-by-step guide created by an awesome member of our community is a go-to resource for anyone new to AgoraDesk.
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.
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.
A step-by-step guide to setting up your account, making and taking offers, and using Peach from start to finish.
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.
Learn which Lightning wallets work best with Robosats, as they use a unique approach to Lightning invoices that doesn’t always play nicely with Lightning wallets.
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.
Another great guide by BitcoinQnA, this walks you through the process of using Bisq from start to finish.
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.
Quickly find a vendor near you with an interactive map.
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:
Awesome-nostr, a curated list of Nostr projects and resources
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:
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!
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
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:
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.
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
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
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 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!
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.
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.
[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:
The onboard CPU’s random number generator
The secure element’s true random number generator
The open source Avalanche noise entropy source
These three forms of entropy are used so that even if one was somehow compromised or vulnerable to attack, the passcode would still be cryptographically secure.
This standard form of 7-zip encryption uses AES-256 to encrypt the data, and then uses a form of SHA-256 to hash the 20-digit passcode into a 256-bit key. The combination of these techniques means that there are 100,000,000,000,000,000,000 possible combinations of passcodes, making it practically impossible to bruteforce the passcode if an attacker somehow obtained the backup file.
As long as a user has access to both the backup file and the 20-digit passcode, they can not only restore their funds, they can also restore all device settings, accounts, account names, multisig configurations, etc. in just a couple of minutes. As the encrypted backup file is a standard 7-zip format, even if Foundation disappeared and your Passport stopped working you could easily decrypt the file with your 20-digit passcode on a computer and import the seed into any of your favorite Bitcoin wallets.
To learn more about the backup functionality, you can read through our docs here.
What are the key advantages of encrypted backups?
Migrating from seed phrases to an encrypted microSD backup (or utilizing them alongside a standard seed phrase backup) provides a few key advantages for users:
All device configuration, accounts, account names, and multisig configurations are fully backed up and automatically restored when using microSD backups
If you merely backup the seed phrase all of this secondary data is not backed up, leading to a lot of initial headache and extra setup necessary when restoring onto another device in the future
You can safely make and distribute multiple copies of the backup file – even to family or friends you don’t fully trust – as they cannot view or move funds in any way with just the backup file
Just be sure not to also give them the passcode!
You can store the passcode safely in an end-to-end encrypted password manager like Bitwarden without risk of funds being stolen even if someone got access to your Bitwarden account
Just be sure not to also store the backup file there!
An attacker or thief finding either your backup file or passcode would not be able to easily tell that they are Bitcoin-related
There is no reason for an attacker to suspect that a microSD card or 20-digit passcode would be worth stealing
An attacker or thief finding either your backup file or passcode could not view or steal funds in any way without having both the backup file and passcode
What are the key disadvantages of encrypted backups?
While we think the overall trade-offs inherent in microSD backups are well worth it, there are some key drawbacks that you should be aware of if you choose to only use encrypted microSD backups:
You must have both the 20-digit passcode and encrypted backup file to restore funds
I.e. if you lose either one you will be unable to restore funds!
This means that microSD backups do introduce a second single point of failure
Advantage #3 above greatly reduces this disadvantages impact, practically
If you store both the encrypted backup and passcode together, it provides no added security over a plaintext seed phrase
MicroSD cards themselves have a limited lifecycle and can fail – it’s important to use high-quality industrial-grade microSD cards (like those we ship with Passport) to reduce this risk
You can also backup the file to another storage medium like a NAS or extra hard drive as another failsafe, and shouldn’t rely on a single microSD card alone!
This may be a short list, but the first point is extremely important to understand – losing either the passcode or the encrypted backup file would lead to loss of funds if you also lost or broke your Passport!
Which should I use?
The beauty of Bitcoin is that it enables you to choose your own path, and we certainly don’t want to inhibit that freedom. That’s why we leave the ultimate choice up to you and ensure that you aren’t locked into our ecosystem (or even our favorite approach). Whether you choose microSD backups or seed phrases (or both!) is up to you, but both can be easily imported into any standard Bitcoin wallet app. If you want added peace of mind, you can even use both and store the three pieces separately – encrypted backup file, 20-digit passcode, and seed phrase!
Ultimately the choice is yours, but we certainly love encrypted backups and how they’re helping onboard less technical users in a way that is approachable and secure.
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.
What can we learn from a simple look into the transaction? Let’s break it down into key findings from using simple, widely available blockchain exploration tools like mempool.space and oxt.me:
The sender consolidated multiple outputs to make the transaction, revealing all the inputs as almost certainly belonging to them
Going back one hop with the largest input shows us that some of the funds were withdrawn from Bitstamp (but not all)
The sent amount is almost certainly 0.011 BTC, as it is sent to a different type of address (“P2SH”, or wrapped/nested SegWit)
We can also confirm this analysis due to the rounded payment amount (0.011 BTC) which almost never happens with fees or change outputs
The recipient is still using a legacy Bitcoin wallet and has not upgraded to use Segwit
The change amount is almost certainly 0.00004088 BTC, as it is sent to the same type of address as the inputs (“P2WPKH”, or Segwit Bech32)
We’ll look more at these findings in each section below.
Protecting the sender
When we look at the different pieces of information revealed in a Bitcoin transaction, the information on funds being spent (and thus on the sender themselves) rightfully deserves the most focus when approaching transactional privacy. When you view any basic Bitcoin transaction in an explorer, you quickly realize that you can learn an immense amount of information about the sender by simply following the inputs backwards.
How do we see this play out in our example transaction? Let’s take a closer look:
The sender consolidated multiple outputs to make the transaction, revealing all the inputs as almost certainly belonging to them
Going back one hop with the largest input shows us that some of the funds were withdrawn from Bitstamp (but not all), tying multiple addresses together with funds connected to the sender’s identity known by Bitstamp
Inputs to a previous transaction sent from Bitstamp wallets
This simple analysis is primarily possible because in Bitcoin, almost all transactions are performed by a single entity; and if a single entity is performing a transaction, then all inputs to that transaction are necessarily owned by them. This heuristic is called the “common-input-ownership heuristic” and is one of the foundational building blocks for the majority of chain surveillance in Bitcoin today. When those wishing to surveil Bitcoin’s usage can safely assume that all inputs in a transaction are owned by the sender, they can build detailed and nearly complete pictures of a user’s spending habits past, present, and future.
This heuristic is also the core of what CoinJoin-style transactions attempt to confuse and break by coordinating a single transaction between many different participants. If enough Bitcoin users started to make CoinJoin transactions regularly, we could even go so far as to break this heuristic and make it inaccurate for chain surveillance companies, severely limiting their visibility into our financial activity on Bitcoin.
While hiding the input addresses and amounts is strictly not possible in Bitcoin today, we do have a few options for obfuscating and confusing chain surveillance, making their lives as difficult as possible.
What can we do today?
While we’ll keep things short and sweet in this section, here are a few ways you can better protect your financial privacy when sending Bitcoin transactions:
Always use a new receive address
If your current Bitcoin wallet doesn’t do this automatically, it’s far past time to switch!
Don’t consolidate funds in your wallet (a commonly recommended way to save on fees down the line) by sending all of your Bitcoin back to yourself in a single transaction
Use as few inputs as possible (only one, if possible!) when sending a transaction
Thankfully most good Bitcoin wallets will do this for you by default!
Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can easily enable this if they’re using a hot wallet!)
Use wallets like Samourai Wallet and Sparrow Wallet to CoinJoin your funds, ensuring that even when you spend funds the prior history of each input isn’t able to be traced
Protecting the sender is the core focus for many of the privacy tools built on Bitcoin, but protecting the amount sent in each transaction is also an important piece of a holistic approach to privacy on-chain. If we’re not careful about how amounts are handled, we can make it easier to undo our privacy and link transactions and addresses to each other. The most common ways to use amounts to reveal information in a transaction are to look for rounded payment amounts (i.e., 0.001 BTC exactly) or to look for exactly matching amounts (minus normal fees) going into and out of exchanges, instant exchangers, or decentralized exchanges.
How do we see this play out in our example transaction? Let’s take a closer look:
The sent amount is almost certainly 0.011 BTC, as it is sent to a different type of address (“P2SH”, or legacy SegWit)
We can also confirm this analysis due to the rounded payment amount (0.011 BTC) which almost never happens with fees or change outputs
The change amount is almost certainly 0.00004088 BTC, as it is sent to the same type of address as the inputs (“P2WPKH”, or Segwit Bech32)
Amount-based heuristics are a common tool used by chain surveillance companies to confirm other heuristics (like the “common-input-ownership heuristic” we’ve already discussed) or to make educated guesses in the absence of clearer signs on-chain. The ability to use amounts to tie transactions and inputs together is one of the main reasons that most of the most battle-tested CoinJoin protocols use common denominations for inputs (i.e., 0.05 BTC) instead of allowing arbitrary amounts. Using these common denominations prevents trivial linkage of inputs and outputs down the line.
What can we do today?
Avoid using rounded amounts (i.e,. 0.01 BTC) when sending funds unless necessary
Avoid using specific fee amounts (outside of 1sat/vbyte, of course) and allow your wallet to calculate fees appropriately
Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can easily enable this if they’re using a hot wallet!)
Now that we’ve taken a look at protecting both the sender and amount in a transaction, how do we go about protecting the recipient’s privacy? Thankfully, many of the same principles apply here as well, especially avoiding address re-use. As every transaction in Bitcoin necessarily has a recipient with address and amount being visible on-chain, it can be quite difficult to actually preserve the privacy of the recipient, both from the sender and from outside observers.
How do we see this play out in our example transaction? Let’s take a closer look:
The sent amount is almost certainly 0.011 BTC, as it is sent to a different type of address (“P2SH”, or legacy SegWit)
We can also confirm this analysis due to the rounded payment amount (0.011 BTC) which almost never happens with fees or change outputs
The recipient is still using a legacy Bitcoin wallet and has not upgraded to use Segwit
The recipient sweeps this output along with many others in a later transaction, linking their other receive history together
Chain surveillance companies leverage many of the same techniques to identify recipients as they do with senders, including wallet fingerprinting by fees, script types, output consolidation, and address re-use. When these types of heuristics are used, it can lead to “wallet clustering”, where those performing surveillance can tie together transactions under a single entity, even if there is no direct identification attached. As always with privacy, it’s important to blend in with the crowd and avoid any mistakes that can make it easier to separate and cluster transactions under a single entity.
What can we do today?
Avoid re-using addresses when receiving funds
If you’re the sender and a recipient is re-using an address or has a static Bitcoin address posted for donations or payments, pressure them to either use a PayNym or a solution like SatSale or BTCPay Server to provide a new address with every payment
Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can enable this, if it’s not enabled ask your merchant to enable it!)
Last but not least comes an aspect of Bitcoin privacy that is often forgotten – protecting the IP address of the Bitcoin node that broadcasts the transaction in question. While the IP address and information about the originating node isn’t stored on the blockchain directly, it can be relatively easily seen by anyone operating a few nodes on the network and desiring to gather that type of information.
Because Bitcoin Core uses a very simplistic transaction broadcast protocol, an adversary seeking to surveil the network can run many nodes in many different geographic locations to try and be at least one connection of most nodes in the network. Once they have these broadly distributed nodes (a “Sybil attack”, something that is very cheap and easy to do in a permissionless and decentralized network like Bitcoin), they can then watch for where in the network they see transactions first broadcast. If they notice that a transaction they’re interested in was first broadcast from one node and propagated from there, they can make a very well educated guess that it was the source node for the transaction.
While this doesn’t guarantee that their guess is correct, it does help them narrow down the potential source node of a transaction and more actively Sybil attack that specific node to look for further transactions of interest. This can be combined with on-chain heuristics to try and find the source node being used by a specific entity and gain vast insight into their spending habits, their geographic location, and even their home address (if they reveal their true IP address to the Bitcoin network).
It’s important to remember that a peer-to-peer network like that used in Bitcoin is designed to be censorship-resistant and permissionless, not private. This approach works extremely well at ensuring that in most censorship scenarios a transaction can still be broadcast to the whole network, but also ensures that a motivated adversary can quite easily follow the flow of transaction propagation and block propagation across the network.
If you’d like to learn more about the issues inherent in this approach, there is an excellent article on the topic titled “Bitcoin’s P2P Network” at nakamoto.com.
What can we do today?
If you run your own Bitcoin node, set it to only use the Tor network for communication
This option is controlled by `onlynet=onion` in the config file, read more on the topic here
Broadcast transactions manually via the Tor Browser and a service like mempool.space
Only do this over Tor, never via clearnet!
The current Onion address of the mempool.space broadcast tool is here
Run your own Samourai Wallet “Dojo” node stack, which is Tor-only by default
Conclusion
After reading this I hope you come away with the conclusion that while Bitcoin’s on-chain privacy is imperfect by default, there are solutions available to each of these problems today. It may seem daunting to have to consider each of these aspects of information when sending or receiving a Bitcoin transaction, but as the issues around privacy within Bitcoin are clarified and made known, the wallets and apps we use to interact with Bitcoin can grow to better handle all of these potential issues for a user automatically.
Over the long-term it’s extremely important that wallet developers and node developers work hard to build in sane and private defaults to their apps, as most users have neither the knowledge nor expertise to properly handle every core piece of Bitcoin privacy. The more we as developers can improve users’ privacy without them even thinking actively about it, the better off our users will be and the better off the Bitcoin network and ecosystem will be.
In part 3 of this series we’ll take a closer look at protecting the sender via CoinJoin, including a sneak peak at what we’re working on to help make Bitcoin privacy more approachable for every Bitcoin user.
Stay tuned, and thanks for diving into the deep end of Bitcoin privacy with us today!
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!”
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.”
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.”
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.
Why we mix
In the fight to reclaim sovereignty in the digital age, Bitcoin has become one of the most powerful tools at our disposal. Bitcoin has the ability to separate money from the State, facilitate direct peer-to-peer transactions, and break the financial censorship and surveillance so rampant in our world today. Therefore, it is immensely important that anyone seeking freedom learn to use it. However, one of the core features of peer-to-peer currencies that we’ve come to love in physical cash is privacy — no one but the people in a cash transaction know how much is transacted, for what, and with whom.
Therefore, privacy in an open society requires anonymous transaction systems.
Bitcoin’s design is one that focuses on security (ensuring only owners of funds can spend them), auditability (ensuring no one can arbitrarily create funds), and censorship-resistant peer-to-peer payments, and has proven over the years to do each of these things *extremely* well. One of the keys to Bitcoin’s early adoption and growth was the ability for anyone testing it out to easily see the flow of funds, understand how bitcoin was created through mining, and confirm that the network did what it was supposed to.
We’ve since moved on from Bitcoin’s early days into an increasingly adversarial environment, one filled with chain surveillance companies, hackers, and controlling governments. This has made it clear that Bitcoin suffers from a privacy problem due to transactions being merely pseudonymous instead of anonymous. In order to fully enable financial sovereignty and better realize the censorship-resistant design of Bitcoin, solutions are needed to allow users to use it as the digital cash we so desperately need. In this series we will walk through why we need better privacy in Bitcoin, what pieces of data are most important to hide or obfuscate, and the tools and techniques that have been created and implemented to enable this.
Ultimately, we at Foundation care deeply about user privacy and want to ensure that every one not only has access to a superior store of value in Bitcoin, but also one that can be stored and spent freely, anonymously, and without censorship.
The threat of identity + Bitcoin
One of the most powerful things that Bitcoin did was to detach money from identity, state, and institutions, giving anyone access to a new, free, and uncensorable type of money. Many of these states and institutions, however, would love nothing more than to co-opt and cripple Bitcoin’s power for the individual through chain surveillance and the introduction of lawless and shadowy “regulations” put into practice under the guise of our protection. One of the most powerful ways that they can seek to limit the power and sovereignty that Bitcoin grants to each of us is to tie our identities back to Bitcoin, often through the use of regulations like “Know Your Customer” (KYC) and “Anti-Money Laundering” (AML) controls.
These controls force users of centralized services and exchanges to give up egregious amounts of personal data in order to convert fiat to Bitcoin (or vice-versa). This data is then easily tied to our usage of Bitcoin, leading to simplified surveillance by chain surveillance companies, confiscation by governments, and theft by bad actors who hack these exchanges and steal our private data. As Bitcoin’s ledger is openly available and stored on thousands of computers around the world, it reveals large amounts of financial information to anyone with a web browser.
Consider this common example: imagine you head to your nearest cafe and buy a coffee with Bitcoin, but you do so without having taken steps towards better privacy. When you pay the barista, they can use their smart phone or computer to see how much Bitcoin you own, where else you spend it, how much you earn, etc. While we generally have quite poor financial privacy today from institutions (think about your bank or credit card company), we expect strong privacy from merchants and random individuals we interact with.
Satoshi’s prescience on KYC/AML
In Bitcoin’s whitepaper, Satoshi saw that the first key to enabling Bitcoin to be used in a private (and thus censorship-resistant and sovereign) manner was to keep the user’s identity off-chain at all costs. When identity is detached from Bitcoin transactions, even the pseudonymity of addresses is a reasonably strong form of privacy for the most common threat models. It may not be perfect, but when bad actors have no clear connections to identity, the job of chain surveillance becomes drastically more difficult. When we choose not to link our identity to our Bitcoin usage we can break many of the most common surveillance methods used and make Bitcoin a much more powerful tool.
The pervasive threat of KYC/AML regulations tying identity to our Bitcoin activity is only increasing, and those who are able to avoid this creeping invasion of privacy have a monumental head start when it comes to Bitcoin privacy. Satoshi was quite prescient when he grasped the disassociation of identity and Bitcoin being important, detailing how this would separate Bitcoin from the traditional financial system and grant greater privacy and freedom. Although this regulation has led to centralized exchanges requiring identification, there is a growing and rapidly improving segment of the space that is focused on building out decentralized methods to exchange that can allow us to buy and sell Bitcoin anonymously (or pseudonymously) and avoid ever relinquishing our personal information. Exchanges such as Hodl Hodl, Agora Desk, and Bisq allow Bitcoiners to escape the KYC/AML surveillance mechanism and give us an invaluable advantage when it comes to Bitcoin privacy.
While most Westerners may not be too concerned with this reality at present, many around the world have come face to face with what happens when their identity is easily tied to financial activity. This pairing can lead to de-platforming, repression, confiscation, and other attacks that limit the power they gain from using Bitcoin.We have seen a rise in surveillance and censorship across the world, but thankfully we have the tools at our disposal to fight back. Our aim is to maximize the impact of Bitcoin in the hands of each sovereign individual, and one of the core ways to do that is to properly leverage the tools available to us.
HOw was privacy viewed in Bitcoin’s early days?
While most people will first acquire Bitcoin through these centralized and regulated exchanges, even those who avoid KYC entirely deserve strong on-chain privacy for their money. As we see in the Cypherpunk’s Manifesto, anonymous ways to transact are key to broader privacy and freedom, and can best enable us to reclaim our financial sovereignty. If our ability to store and spend our money freely is eroded via surveillance and control, the rest of our rights as humans can be quickly degraded.
Enter Bitcoin privacy tools.
Since the very early days of Bitcoin, developers and members of the community have spent countless hours devising methods to preserve privacy in Bitcoin to further protect users and empower its censorship-resistance. While this was a core focus early on, many in the community may not be familiar with how critical this topic was to many of the early Bitcoiners who paved the way for us. Many of the concepts used in Bitcoin and other cryptocurrencies focused on privacy were discussed or created in the first few years of Bitcoin’s existence by Bitcoin legends like Satoshi, Hal Finney, Greg Maxwell, Peter Todd, and Adam Back.
Hal Finney set the tone early on in Bitcoin
Hal Finney set the tone early on in Bitcoin as he immediately saw the privacy implications of a fully transparent system. Finney was an early pioneer and privacy advocate, contributing greatly to the PGP protocol and authoring key emails to the early cypherpunk’s mailing list. While Hal Finney was one of the first to think deeply about how to bring anonymity to Bitcoin, Satoshi and many others joined in throughout the early years. Between 2011 and 2013, we saw “stealth addresses”, “PayJoin”, “CoinJoin”, “Confidential Transactions”, and “Borromean Ring Signatures” all proposed and discussed around the Bitcoin community.
While many of these early concepts were never broadly implemented in Bitcoin, one idea did start to gain traction in 2013 — CoinJoins. Greg Maxwell playfully proposed the concept of CoinJoins in a Bitcoin Talk thread titled “I Taint Rich!”, inviting random users to work with him to create collaborative transactions. The idea was that these transactions would create false links between his coins history and that of other Bitcoin Talk users, sowing doubt in chain surveillance companies analysis. These early Bitcoiners paved the way towards a better Bitcoin by taking the time to create, propose, and discuss amazing concepts like CoinJoin.
In Bitcoin, one of the fundamental heuristics used to attempt to trace coins is called the “common input ownership heuristic”, one that assumes that any inputs to a transaction are owned by the same entity. If we can break that heuristic by having Bitcoiners work together to build transactions, we can make it much more difficult to surveil our activity on-chain. At the same time, CoinJoins allow us to build these transactions in a way that makes it extremely difficult to correctly guess which input is connected to which output — breaking the deterministic links that are the norm within Bitcoin and granting strong transactional privacy.
Paving the way towards a better Bitcoin
While concepts like CoinJoin were only the beginning, they would lay the groundwork for many of the most powerful Bitcoin privacy tools at our disposal today. But how does CoinJoin work? What do we achieve when we build these collaborative transactions? What information do we need to hide when we transact in Bitcoin?
We must defend our own privacy if we expect to have any.
We’ll take a deeper look at the data that we must protect in order to defend our right to privacy in part 2 of this series, and then dive into how we got from the early concept of CoinJoin to the mature tools we have at our disposal today in part 3, including what we have in store for Passport and Envoy users in the near future.
One of the core tenets we live by here at Foundation is that of “don’t trust, verify.” We’ve long had a detailed guide available for verifying and updating the firmware on Passport in a secure way, but we want to expand on that by empowering users to more easily validate Envoy on Android. In this guide we’ll walk through the “why” and “how” of verifying the APK file (the raw binaries that Android uses for manually installing applications) with both simple hash verification and full PGP signature validation to ensure that the app you install is exactly what we published and has not been tampered with in any way.
Why is verification important?
While the Google Play Store and Apple App Store provide a secure centralized method to distribute apps, control over the published application ends up in the hands of Google and Apple, respectively. Because of these centralized “walled gardens,” the ability for end users to verify that the applications they are installing are exactly what the developers publish is minimized, and trust is placed in the app store provider.
When downloading the APK directly from Github, however, we unlock the ability to provide additional guarantees that the application you’re installing is exactly what we at Foundation have made and that it has not been tampered with along the way. Because we’re focused on securely storing and spending Bitcoin with Passport and Envoy, many users understandably want to take as many steps as possible to ensure that their funds are safe against even advanced attacks.
When downloading binaries directly (essentially what an APK file is), even from websites you’d normally trust like Github, you’re placing trust in the source of that binary to match the source code you expect. Verifying the zipped (or compressed) APK file we publish on Github prevents Github (or a malicious attacker somehow injecting themselves between you and Github’s servers!) from being able to tamper with the Envoy APK without being detected. This verification process does require some extra work but can provide additional peace of mind to users of Envoy while reducing trust in third-parties.
Let’s look at how exactly we can perform this verification on Android itself.
Simple hash verification
While full verification via PGP keys is more secure, simple hash verification is very easy and faster to perform while still giving some security guarantees against more trivial man-in-the-middle attacks. A hash of a file is a fixed-length string that uniquely represents a given file, where changing even a single bit of the file would result in an entirely different hash. As a given input file can only have a single hash, comparing the expected hash against the downloaded file ensures that not even a single bit in the file has been changed or corrupted.
Download and install “DeadHash” via the Google Play Store or F-Droid
This SHA-256 hash (the same hashing algorithm used for Bitcoin mining!) is a way to represent the file in a way that cannot be falsified
Open DeadHash and select the folder icon to choose the Envoy APK zip file
Select the downloaded APK zip file, i.e. envoy-apk-1.0.7-18.zip
Paste the hash you copied into the “Compare” field
Press “Calculate”
Ensure that the SHA-256 hash validates and gives you a nice green check-mark
All of the hashing algorithms except for SHA-256 should show a red X, as we’ve only provided the SHA-256 hash
If you get a red X for all hashes, including SHA-256, stop immediately and reach out to us at hello@foundationdevices.com! If it does match, you’re all set.
DeadHash giving a successful hash check
Fully verifying Envoy via PGP
While more involved than simple hash verification, taking the time to validate our PGP key and signatures ensures that as many threats as possible are mitigated. When you validate the PGP keys and signatures of Envoy, you ensure that only a successful attack would require both the PGP private keys and control over our Github account(s). This verification also entirely mitigates the risk, however minor, of Github themselves tampering with the APK.
Getting setup
Before we get started, you’ll need to download and install a separate app on your Android device to enable you to validate the PGP key used to sign the Envoy zip file, and then import the Envoy signing key. For each of the steps below with commands (i.e. pkg install wget gnupg -y), simply copy and paste these into Termux and hit enter.
You should see output including “Good signature from ‘Igor Cota <igor@openbook.hr>‘” in a line of the output from this step
This step ensures that the GPG key we publish was the one used to sign the envoy-manifest.txt file, and that the file has not been tampered with in any way
This step compares the hash for the APK zip in the envoy-manifest.txt file that we’ve verified via PGP with the SHA-256 hash of the actual APK zip file we’ve downloaded, ensuring no tampering or corruption has happened
If the output says something like envoy-apk-1.0.7-18.zip: OK, you’ve successfully verified the binary and can go ahead and install with added peace of mind
Note that the file name will change with each release, but you should always get the “OK” at the end!
Congratulations on successfully verifying Envoy! These steps are certainly going above and beyond, but keeping with the “don’t trust, verify” mantra is one that always pays off. If you’d like to read more about the PGP or simple hash verification process, you can take a look at the following links:
Verifying your Casa Multisig with Passport and Sparrow
collaborative custody
Casa is one of the Bitcoin ecosystem’s leading collaborative custody services. Using the Casa mobile app, you can create a multi-signature wallet consisting of either:
3 keys (Gold Plan) – 1 user secured signing device like Passport, a key stored on the user’s phone (backed up to the cloud), and Casa holding the third key.
5 keys (Platinum Plan) – 3 user secured signing devices, a mobile key and a fifth key held by Casa.
With this setup, the user is always the majority key holder, and Casa alone cannot spend any funds from the wallet. Under normal operation, users do not need to interact with the key held by Casa and can authorize transactions themselves using their majority key set. Where the Casa key comes into play is in a scenario where the user loses access to 1 key in the Gold Plan, or 2 keys if using the Platinum Plan. In this scenario, the user can initiate a Recovery transaction to spend, with the help of Casa, their Bitcoin to a new multisig wallet where all keys are accessible once again.
With the release of Passport firmware v2.0.4, we are thrilled to announce that using Passport with Casa is now easier than ever. Passport’s new Extensions menu lets you quickly and easily enable different features that unlock new functionality. Once enabled, the Casa extension adds an additional Casa account screen. From here you can do the typical transaction signing as you would with any other Passport account, but you’ll also notice some Casa specific features, such as ‘Health Check’, that allows you to quickly confirm that Passport is still connected with your Casa account. You’ll also find a customized Casa connection wizard that makes your initial setup a breeze!
Founder’s Edition Passport users fear not, we will be porting all of the new v2.0.4 features to your firmware very soon.
Who is this guide for?
For the reasons outlined above (and many more), Casa functions incredibly well to help many Bitcoiners secure their wealth. This tutorial is for those users that want to leverage the power of a collaborative custody setup like Casa, but at the same time want to minimize the level of trust they place in Casa. The following steps show how to recreate a ‘watch-only’ version of a Casa multisig wallet. This watch-only version of the wallet will be created in the free and Open Source desktop application, Sparrow Wallet. Being a watch-only, Sparrow will not have the ability to spend any funds from within, though we will make a brief mention of the additional steps required to do this later.
There are three main reasons a user might want to carry out these steps:
To check that Casa is generating receive and change addresses that belong to the wallet created with the three keys provided. Later, we’ll leverage Passport’s ‘verify address‘ scanning feature to make this super simple.
In preparation for a doomsday scenario in which Casa the company ceased to exist and the user needed to recover their funds without the help of Casa.
To use the Whirlpool coinjoin service within Sparrow to mix directly into their Casa multisig wallet.
Sparrow Wallet Preview
Before we start
The following steps assume a few prerequisites are met. Ensure you meet all three requirements before attempting to complete this tutorial:
You have a Casa multisig wallet setup and active on your Android or iOS device.
You have a secure method of transferring sensitive information from your phone to the device running Sparrow Wallet. Examples include Signal, Keybase, or an encrypted notes app like Standard Notes.
Exporting the public keys
To recreate the Casa wallet in Sparrow, we need the public keys from each wallet participant as well as the corresponding derivation path and fingerprint for each. If you’re a Gold plan user, that means you’ll need to check 3 keys, and Platinum users will need to check 5 keys.
Open the Casa app, click on any of the available keys, then tap ‘View Public Keys‘. Copy and paste all information shown into your chosen secure transfer app. Be sure to carefully label which key the information belongs to.
Repeat these steps for every key until you have something that resembles the image below. Depending on how you’ve used the Casa app prior to this guide, your derivation paths may be different to those shown in this guide. Also note the lack of a derivation path for the Casa Recovery Key, the Casa app does not display this information.
Standard Notes app displaying the exported Casa wallet information
Enter Sparrow
Now that we have the required information from Casa, we can turn our attention to Sparrow. Click File > New Wallet and give the wallet a name
Sparrow Wallet Creation
On the following screen, change the ‘Policy Type’ to Multi Signature, then change the ‘Script Type’ to Nested Segwit and finally, set ‘Cosigners’ to 2/3. This will set the wallet’s spending policy to match Casa where two signatures out of a possible three are required to spend from the wallet. If you are following this guide as a Platinum user, set ‘Cosigners’ to 3/5, where three signatures from a possible five are required to spend.
Sparrow Wallet configured to suit the Casa setup
The next step is to import the information taken from the Casa app, into Sparrow. Sparrow represents each cosigner as a ‘Keystore’, and for the purposes of this guide, all three cosigners will be imported using the ‘xPub / Watch Only Wallet‘ option.
Populate the first Keystore using the information saved in your chosen transfer app, ensuring you enter each piece of information exactly as it was copied from Casa.
Keystore 1 populated with public key information
Repeat for all cosigners until each Keystore in Sparrow is populated. For the Casa Recovery Key, enter the same derivation path used for all other keys.
All Keystores populated
Once completed, click ‘Apply’. Sparrow will then ask if you’d like to set a password to prevent unauthorized access to the wallet. This password is unique to Sparrow and, if applied, ensure it is securely backup up.
Do they match?
If you followed these instructions successfully, opening the Transactions tab will reveal your Casa wallet’s total balance and transaction history. If you do not, open the Sparrow Settings tab and double check the information entered is an exact match to that shown in Casa.
Casa Wallet successfully imported into Sparrow
Open the Receive screen in both Casa and Sparrow and check that the addresses shown are an exact match. We can now be confident that Casa is generating the correct receive addresses for your multi-signature wallet. If desired, you can repeat this check every time the Casa app shows you a new receiving address.
Sparrow Wallet receive screen
Verifying with passport
To leverage Passport’s powerful ‘Verify Address’ feature to verify all future addresses shown by Casa (or Sparrow) with a simple scan, we need to make Passport aware of the wallet configuration. Unlike other multisig wallet coordinators, Casa does not currently have a way to export this information via QR code or microSD card, but there are two other ways we can get this information to Passport.
Option 1 – Passport Multisig policy
By having Passport’s multisig policy set to ‘Ask to Import’, Passport will automatically pull the required information from the transaction details when signing a transaction with Casa.
Passport import multisig config
option 2 – use sparrow
With the multisig wallet open in Sparrow, head to Settings > Export, then click ‘Show’ next to ‘Passport Multisig’. Sparrow will then display an animated QR code containing all of the wallet public information which will notify Passport of the wallet details.
Multisig wallet config export
On Passport head to Settings > Multisig > Import from QR then scan the QR being displayed by Sparrow. Review the details shown on screen and then confirm.
scan + go
Now, when using the Verify Address feature on Passport, you’ll be able to choose your imported Casa wallet from the list and will get a confirmation that the address being shown is part of your multisig wallet.
Passport Address Verification
What if i want to spend?
At this stage Sparrow is acting purely as a watch-only wallet that cannot spend, and has no influence on the activities taken in the Casa app. The private keys required to authorize spends are still stored on your Passport, your phone and on the Casa Recovery Server respectively. But what if Casa were to disappear and you needed to move your Bitcoin?
In this very unlikely scenario, the steps required are almost identical to those outlined above. The only difference being, that instead of importing the Mobile cosigner’s public key, we instead need to import its private key. This private key can be exported from Casa by tapping on the mobile key then ‘Import or Export Backup’, followed by ‘Export Private Key’. Casa will then display a list of seed words that should be stored securely and not shared with anyone.
Once you have the mobile key’s seed words, you can change that Keystore in the Sparrow settings. Click ‘Import from an external source’, choose ‘Software Wallet’ then ‘Mnemonic Seed Words (BIP39)’. Then enter the seed words you noted down from the Casa app.
Importing a mnemonic seed to Sparrow
On the following screen set the derivation path to match the other cosigners and click ‘Import Custom Derivation Key’. To finalize these changes click ‘Apply’ on the settings screen.
Custom derivation path setting
Sparrow now contains 1 of the 3 private keys required to spend from this multisig wallet. Now, to spend your Bitcoin to a new wallet, all that’s required is to create the transaction by following the usual steps and providing a second signature with Passport. The video below demonstrates the typical signing flow with Passport + Sparrow.
A note on key rotations
When one key is compromised and replaced, Casa bumps all other keys to the next account level in their respective derivation paths. This means that any time a key rotation is performed within Casa, the above steps must be repeated. More experienced Sparrow users may opt to manually update each Keystore to reflect the wallet changes, but it is good practice for newer users to get comfortable creating the wallet from scratch.
BONUS – coinjoin directly to your casa wallet!
Sparrow Wallet recently incorporated the Samourai Wallet Whirlpool coinjoin implementation. Conjoin is one of the best methods available to preserve your privacy when interacting with Bitcoin’s transparent ledger. Sparrow enables you to participate in coinjoins via your computer without the need for an Android phone. Additional to the Whirlpool functionality, Sparrow also enables users to have those mixed outputs be sent automatically to any another wallet managed by the same Sparrow application. No additional user input, just start the mix, leave Sparrow running and it will do the rest for you!
This section of the guide is not designed to be a detailed walk through of using Whirlpool with Sparrow. For that, you can read this guide or watch this video. Prerequisites for this section of the guide:
Have a Casa wallet imported into Sparrow.
Have a single signature hot wallet (where Sparrow holds the seed words) set up in Sparrow.
Have the hot wallet funded with the amount of Bitcoin you want to coinjoin.
Starting the mix
With your hot wallet open in Sparrow and funded with the amount of Bitcoin you want to coinjoin, open the UTXO tab and from the list, select the UTXOs you want to mix. Then choose ‘Mix Selected’.
Starting a mix with Sparrow Wallet
Work through the following dialogue screens to select your miner fee and pool size to enter. The pool size you choose will depend on the amount of Bitcoin you are mixing plus the desired denomination of mixed output you desire. To confirm click Preview Premix.
Whirlpool info screen
On the following screen Sparrow provides a breakdown of the fees involved and mixed outputs created from the coinjoin. When you are happy click Broadcast Premix Transaction.
Premix preview
The coinjoin is now initiated and Sparrow will take over and do the rest for you, provided you keep the application running. After a short while, navigate to the Postmix tab from the side bar to see your mixed outputs. How many you see in this screen will depend on the amount of Bitcoin you elected to mix, and in which pool.
Mixing larger amounts in smaller pools may take longer to complete, so do not be alarmed the expected amount of Bitcoin does not show up immediately.
Sparrow Wallet Postmix Tab
Mixing to your casa multisig
To get your mixed outputs sent automatically to your Casa multisig, ensure both your hot wallet and the imported Casa wallet are open in Sparrow. Then navigate to the Postmix UTXOs tab and select the UTXO(s) to be mixed into the Casa wallet then click ‘Mix to’.
In the pop up window, select the imported Casa wallet from the Mix to drop down then select the minimum number of mixes required before the UTXOs are eligible to be sent to the Casa wallet, a higher number here will improve your privacy but means the move to Casa will take longer. Finally, leave the index range to Full and click Restart Whirlpool.
‘Mix to’ configuration
Now, when clicking on the UTXOs selected earlier, Sparrow will indicate at the bottom of the screen that they are ‘Mixing to Casa’. Again, all you need to do now is leave Sparrow running on your computer and it will take care of the rest for you.
‘Mix to’ started
After the defined amount of mixes have taken place, you’ll see incoming transactions of the pool amount landing in your Casa app (and the imported version on Sparrow). Each UTXO will be sent individually to your Casa wallet, and the more UTXOs set using ‘Mix To’, the longer the process will take to fully complete. Patience is key here and you can monitor everything from Sparrow.
It’s worth mentioning that whilst Whirlpool provides fantastic forward looking privacy for your mixed outputs, your wallet is still ultimately connected to Casa’s node, meaning that Casa will still know the UTXOs are yours.
the best of both worlds
By following the steps outlined in this guide, you really can have have it all! You get the awesome security and redundancy the Casa collaborative custody model offers, coupled with the fantastic forward looking privacy gained from using the Whirlpool coinjoin service within Sparrow. All of this, whilst also minimizing the trust placed in Casa by combining Passport with a Sparrow watch-only setup to validate everything the Casa app presents to you. Finally, in the highly unlikely situation that Casa were to disappear, you’re now also fully prepared to recover your Bitcoin too.
Stay tuned to our YouTube and BitcoinTV channels for an upcoming video tutorial on using Passport with Casa to secure your sats!
Purchase PASSPORT
Order Passport Batch 2 today, limited to 2400 units!
