Skip to main content

12 words are the standard

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

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

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

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

What is a private key?

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

https://youtu.be/S9JGmA5_unY

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

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

1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD

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

Private keys made human

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

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

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

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

Attacking your private keys

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

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

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

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

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

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

12 words is the sweet spot

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

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

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

Bringing things back to reality

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

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

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

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

Let’s make 12 words the standard.

Dive deeper

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


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

    Building a Private Future: Tor Library’s Move to MIT Licensing

    Building Tools for Freedom

    At Foundation, we believe that true freedom in the digital age starts with privacy. We’re excited to announce that we’ve changed the license of our Tor library from GPL to the more permissive MIT license. This shift allows developers even greater flexibility to integrate and adapt our Tor library within their Flutter-based wallets and privacy-focused projects, furthering the mission of protecting user privacy across the globe.

    Why Tor Matters in the Fight for Privacy

    Tor is a vital tool in the ongoing fight for privacy. By routing internet traffic through a series of encrypted hops, Tor masks users’ IP addresses and encrypts their traffic, making it very impossible for third parties to monitor their online activities.

    In the context of Bitcoin and privacy, this is especially important. By integrating Tor, developers can ensure that users’ transaction data and personal information are not easily tied together. This not only enhances the privacy of users but also adds an essential layer of security to wallets. As more people turn to Bitcoin as a tool for financial sovereignty, protecting their digital footprint is crucial.

    Empowering Developers with Open-Source Tools

    At Foundation, we are passionate advocates of open-source and collaboration across the space to help people regain their freedom. While our Tor library has always been open-source, we’ve now made it even more accessible by switching its license from GPL to the MIT license. This change provides the community with greater flexibility and ease in integrating Tor into any Flutter-based wallet, making it an even more seamless and powerful tool for enhancing user privacy.

    With just a few lines of code, developers can add this crucial privacy feature to their wallets, ensuring that user data is not only secure but also more private. We see this as an important step toward creating a more private and secure digital ecosystem, where financial independence and privacy go hand in hand.

    Contributions from the Community

    We’re thrilled to highlight the incredible support and contributions from our community. A special thanks goes to our friends over at StackWallet, who not only integrated the Tor library into their own stack (pun intended) but have also provided invaluable feedback and contributions that have helped make the library what it is today.

    In addition, we’re excited to say our friends over at Cake Wallet are also integrating our Tor library into their stack. As a privacy-first wallet, their commitment to user security and anonymity aligns closely with our own mission. By incorporating our Tor library, Cake Wallet is taking an important step toward bolstering privacy for their users, ensuring that sensitive data remains protected.

    Licensed Under MIT: Free to Use, Modify, and Share

    We strongly believe in the power of open-source technology to drive innovation and advance privacy and freedom for all. That’s why our Tor library is licensed under the MIT license, meaning it’s free for anyone to use, modify, and distribute. We want to create a world where privacy-enhancing technology is accessible to all, without barriers or gatekeepers.

    Whether you’re an independent developer or part of a larger team, our Tor library is there for you to integrate, experiment with, and build upon. Together, we can continue advancing the possibilities of secure and privacy-focused technologies.

    Explore the Tor Library and Start Building

    We invite developers from all walks of life—whether you’re passionate about Bitcoin, privacy, or decentralized applications—to dive into our Tor library and start building. We’ve made it as easy as possible to get started, and we’re excited to see how the community uses this tool to enhance privacy in their projects.

    To get started, you can find our open-source Tor library on GitHub:

    GitHub Repository: Foundation Devices Tor Library

    Let’s work together to build tools that make the digital world more private, secure, and free for everyone. At Foundation, we believe in a future where privacy is a right, not a luxury, and we’re excited to continue building that future—one open-source tool at a time.

    Passport version 2.3.2 is now live!

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

     

    WHAT’S CHANGED

    With this version of Passport’s firmware we’ve added one of the most requested features — ephemeral seed support! You can now easily use ephemeral seeds in several ways, directly on Passport. We’ve also added the ability to sign messages via QR code, and added a connection flow for Fully Noded.

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

     

    NEW FEATURES

    • Seeds can now be loaded temporarily in three ways:
      • Ephemeral seeds can be used instead of a permanent seed phrase. This is great for advanced users that do not want to permanently store any seeds on Passport. When turning on Passport you can scan in a SeedQR or manually enter a seed, then use Passport as you normally would to connect to wallet software and sign transactions. The seed will be forgotten when Passport is turned off.
      • Ephemeral seeds can also be used alongside a permanent seed phrase. Keep a main or ‘master’ seed phrase on Passport as normal, but also temporarily load a seed phrase from the ‘More’ page at any time. That temporary seed will be forgotten when you shut down Passport or you can manually remove it from the same menu. Once you’re done with the ephemeral seed, Passport will go back to using it’s primary seed just like before!
      • Ephemeral seeds can be loaded from Key Manager alongside a permanent seed phrase. Ever needed to help a friend or family member spend from the child key you created for them? Just head to the Key Manager page, select any seed from your list and load it temporarily.
      • Learn more about temporary seeds in our docs.

     

    • Passport can now be used to sign messages via QR code!

     

    • Added Fully Noded to Passport’s wallet connection options.
      • Fully Noded is an open source and feature packed iOS and Mac app designed to connect and remotely manage your Bitcoin node, Lightning channels and offline wallets. 
      • Learn more about Fully Noded.

     

    IMPROVEMENTS

    • Improved the microSD signing flow by removing unnecessary options.
    • Expanded the suggested words to 10 in the import seed flow to capture edge cases where importing a seed using only four letters could sometimes not display the expected word.
    • Added Address Explorer to the Postmix extension.
    • Added the Theya single signature connection flow.
    • Updated the supported UR types to be in line with the Blockchain Commons standard.
    • Added a new warning screen if outdated or unrecognized UR types are scanned.
    • Additional firmware file state check before installation.
    • New wallets now default their multisig policy to “Ask to Import”.
    • The multisig wallet import question is now more streamlined and the decision point is clearer.
    • Improved some wording and updated some icons to make them more consistent across all the menus.

     

    BUG FIXES

    • Fixed an issue where users could get stuck in a screen if an obscure flow path was followed in some multisig pairing flows.
    • Fixed an issue where trying to manually add account #0 would crash Passport.
    • Fixed a minor issue where Passport would remember the device name after the device was erased from Settings.
    • Fixed an issue where Passport would sometimes improperly create the QR displayed in the Casa extension.
    • Fixed a minor seed entry issue on restore.
    • Fixed an issue where trying to sign a taproot PSBT for an incorrect wallet would fail without showing the fingerprint required.
    • Fixed a visual bug where the found and required fingerprints in some error messages were switched.

     

    VERIFYING, REPRODUCING, 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

    If you’d like to take the additional step of testing the reproducibility of Passport’s firmware, you can follow our guide on the topic here: Reproducibility Guide