There’s no such thing as a self-hosted wallet

They’re not content with just controlling our fiat money and your Bitcoin on centralized exchanges, so they’re coming for our self-custodied Bitcoin as well.

In a proposal to the European Union, the General Secretariat laid out an updated set of restrictions on cryptocurrency usage within the EU. While much of the proposal should be familiar, the updated language and recommendations around so-called “self-hosted wallets” are a frightening step towards tighter control over how we use Bitcoin. This new regulation proposes not only an implementation of the “Travel Rule” (requiring personal identification attached to each transfer between centralized, regulated entities) but also a limit of €1,000 to transfers from and to regulated exchanges and a recommendation to “mitigate the risks posed by transfers from and to self-hosted addresses” with forthcoming recommended restrictions.

One of the most onerous aspects of this new regulation is the introduction of a new phrase to imply that money that you own and control can and should be regulated by introducing the term “self-hosted,” when no such term exists for physical cash or fiat. When you choose to control your Bitcoin, you don’t have to “self-host” anything, you simply have the key to certain Bitcoin outputs and can transfer ownership of Bitcoin outputs (or coins) to other entities by signing over control to them. This key is a randomly generated 64-character string of letters and numbers (i.e. E987…3262), and regulating knowledge of a string of characters is an unbelievable overstep of power. The ability to transfer monetary value in a peer-to-peer manner is one that has existed since the early days of civilization and has historically been private, without requiring disclosure or surveillance.

The implication that the only way the State can prevent crime is by surveilling and collecting personal information from every financial transaction is an unprecedented shift towards centralized control. This control has not been necessary in the past for a safe, effective, and high-functioning society to prosper. When compared to fiat, cryptocurrencies like Bitcoin present an infinitesimally small amount of illicit activity. In their 2022 “Crypto Crime Report”, Chainalysis estimated that only 0.15% of all cryptocurrency volume involved illicit activity, compared to an estimated 2-5% of all GDP ($1.6-4 *trillion*) for fiat. The EU wishes to wield irrational fear and literary propaganda to justify centralizing and expanding their control over our lives.

With these numbers in mind, why are regulators like the EU attempting to tighten the noose on cryptocurrency usage by sovereign individuals? It certainly is not to prevent rampant crime, as cryptocurrencies are barely utilized for that and the low-hanging fruit is fiat use in crime. Is it for our own benefit? It certainly isn’t for our monetary safety, as users’ funds are far safer when self-custodied than when left to centralized exchanges and regulated custodians. Maybe, just maybe, they want to limit the ways in which each one of us can take back some control of our money from the state.

When they can’t control or surveil our finances or our actions, the power returns to the sovereign individual.

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.

Eric Hughes, “A Cypherpunk’s Manifesto

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.

“… privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous.”
Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System”

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.

Eric Hughes, “A Cypherpunk’s Manifesto

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.

Learning more

Passport version 2.0.4 is now live!

We’re excited to announce that the latest version of Passport firmware – 2.0.4 – is now live! To download it, simply initiate the update from Envoy to be guided through the process.

What’s changed

With version 2.0.4 of Passport firmware, we added the Extensions menu, allowing users to enable extra features on Passport with the flick of a switch, starting with the Casa and Postmix extensions. We also greatly improved the QR code scanning and display functionality and fixed several minor bugs.

For more details on each of the changes, keep reading below!

New Features

Improvements

  • Improved QR code display and scanning
    • Improve the size and density of QR codes to better fill the screen
    • Remove vertical line from camera image when scanning QR codes
    • Remember last brightness setting when showing a QR code
    • Remember last pixel density setting when showing a QR code
  • Improve microSD and file handling
    • Autorefresh file picker when microSD inserted/removed
    • Erase the PSBT file after signing
    • Allow user to go back up a level when there are no files in the current directory
  • Improve user experience
    • Make delete key handling on Backup Code page more intuitive
    • Add low power warning dialog when battery hits 5%
    • Tell user when they are installing a developer-signed firmware update
    • Show new fingerprint (XFP) when switching passphrases
    • Show Clear Passphrase and Change Passphrase menus instead when a passphrase is already active
  • Show brick warnings on 5 and 1 PIN code entry attempts remaining
    • Ensure that users properly understand that the device will be bricked after entering an incorrect PIN code 21 times
  • Add several new/updated icons
  • Add support to enter account numbers up to 2,147,483,646
  • Improved paginated layout for seed words page
  • Rename Testnet menu to Network
  • Search “change” addresses for multisig address verification

Bug Fixes

  • Bring forward bug fixes from Founder’s Edition code
  • Fix Verify Address for all uppercase bech32 addresses
  • Fix XFP missing crash
  • Respect “Skip address verification” flag in wallet settings
  • Respect “Force multisig policy” flag in wallet settings
  • Fix multisig import and multisig address verification during connect wallet process
  • Fix text alignment in mulitsig QR import screen
  • Fix scrollbar margins in a few places
  • Fix QR and microSD wallet import crashes
  • Fix backspace bug when entering a 12 digit PIN
  • Fix toggle switch right padding
  • Don’t import duplicate multisig wallets (show error page)
  • When Auto-Shutdown is set to Never, the selection now scrolls into view properly
  • Fix Bitcoin URI parsing (when URI was followed by query params, parsing failed)
  • Allow up/down keys to increase/decrease screen brightness on all QR code pages, not just animated ones

Verifying and Installing Passport Firmware

If you’d like to verify and install the latest version of Passport manually, you can follow our guide on the topic here: Firmware Update support page

Envoy version 1.0.7 is now live!

Envoy Release v1.0.7

We’re excited to announce that the latest version of Envoy 1.0.7 – is now live on all your favorite mobile platforms! To download it, simply visit our download page or check for updates on your platform of choice.

What’s changed

With version 1.0.7 of Envoy, we added in a firmware update button to simplify the process of installing firmware updates after you’ve initially setup your Passport, squashed some pesky bugs, and overhauled our app to the latest Flutter release.

For more details on each of the changes, keep reading below!

New Features

  • Added a firmware update button to the home screen card for Passport
    • Now you can force a firmware update anytime, anywhere for your Passport device straight from Envoy’s home screen
Envoy’s new firmware update button

Improvements

  • Upgrade to Flutter 3
    • While this may not be immediately visible from a user’s perspective, it helps us cut down on bugs and improve our release workflow
    • Flutter 3 also enables us to more easily bring desktop support for Envoy in the future across all platforms, including Windows, macOS, and even Linux!
  • Remove Google MLKit QR scanner
    • Removes a dependency on Google and an unwanted network call
  • Change Postmix account color for consistency with Passport

Bug Fixes

Verifying Envoy on Android

If you’d like to take the optional additional step of verifying Envoy binaries on Android, follow our guide: Verifying Envoy on Android

Verifying Envoy on Android

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.

  1. Download and install “DeadHash” via the Google Play Store or F-Droid
  2. Copy the SHA-256 hash for the Envoy APK zip file from the Github release page
    • The hash will look something like this:
    • 08cc97450febd558a0f54d93b181f9a90
      ccf05662828977cb8277181ab86b126
  3. 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
  4. 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
  5. Paste the hash you copied into the “Compare” field
  6. Press “Calculate”
  7. 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.

  1. Install the Termux app from Github or F-Droid
  2. Open Termux and install the required packages
    • pkg install wget gnupg -y
  3. Download the Envoy signing PGP key
    • wget --quiet https://docs.foundationdevices.com/envoy_key.pgp
  4. Download the Envoy APK file, manifest file, and PGP signature file
    • Replace the links below with those from the latest release!
    • wget --quiet https://github.com/Foundation-Devices/envoy/releases/download/v1.0.7/envoy-apk-1.0.7-18.zip
      wget --quiet https://github.com/Foundation-Devices/envoy/releases/download/v1.0.7/envoy-manifest.txt
      wget --quiet https://github.com/Foundation-Devices/envoy/releases/download/v1.0.7/envoy-manifest.txt.asc
Successful prep steps

verifying Envoy

  1. Import the Envoy signing PGP key
    • gpg --import envoy_key.pgp
    • Validate the key ID that is shown on the first or second line matches that on https://foundationdevices.com/pgp/ under “Envoy Signing Key”
      • i.e. “E8CE0DD2B5528043” (note that the key is not case sensitive)
    • If the key does NOT match, stop immediately and reach out to us at hello@foundationdevices.com! If it does match, proceed to step two below
    • This step imports the PGP key we publish on our website, allowing you to properly validate our PGP signature in the next step
  2. Verify the “envoy-manifest.txt” file is properly signed with our Envoy signing PGP key
    • gpg --verify envoy-manifest.txt.asc envoy-manifest.txt
    • 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
  3. Verify the Envoy APK zip file
    • echo "$(grep "envoy-apk" envoy-manifest.txt)" | sha256sum --check
    • 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
  4. 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!
    • If the output does NOT say “OK“, stop immediately and reach out to us at hello@foundationdevices.com!
Successful verification of Envoy via Termux

Conclusion

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: