Our Bitcoin wallet checklist

Bruce Kleinman
Jul 27, 2017 · 9 min read

The features we want in a crypto-currency wallet

making our list, checking it twice

This post is an excerpt from The Bitcoin Tutorial. If bits of it seem to lack context or make oblique references, you know why.

Hierarchical deterministic (HD) wallets

In the Where Is A Bitcoin? post, we discussed the set of bitcoin credentials stored in your bitcoin wallet. Each of your bitcoin is represented by its own unique set of bitcoin credentials, with the private key holding a position of incomparable importance:

  • The private key is produced by a high-quality pseudo-random number generator (PRNG).
  • All other elements of a bitcoin credential can be re-calculated from the private key and re-acquired by querying the bitcoin blockchain with the public key hash.
  • The private key is REQUIRED to spend the associated bitcoin.

Problem statement. Loss of private keys equals loss of the associated bitcoin, full stop. Complete, secure, periodic backup of your bitcoin wallet is, therefore, absolutely essential. Most people (not you, obviously) rarely perform complete, secure, periodic backups.

Innovative Solution. Create ONE high-quality random master seed, when the wallet is first initialized. Process the master seed through HMAC-SHA512 to produce a wallet master key. Compute all private keys in the wallet from the master key using HMAC-SHA512 and a simple nonce.

Because all private keys in the wallet are derived deterministically from the master seed, they can be re-created from the master seed alone. Consequently, only a ONE-TIME secure backup of the master seed is required when the wallet is first initialized.

This is called a hierarchical deterministic (HD) wallet and is standardized in BIP-0032. This is so fantastically clever that I wish I had thought of it.

Restating for clarity:

  • An HD wallet has ONE random master seed.
  • An unlimited number of private keys are derived deterministically from the master seed.
  • Each set of bitcoin credentials can be re-calculated and re-acquired from its private key.
  • Therefore, each wallet needs a SINGLE secure backup of ONLY the master seed when the wallet is first initialized. The entire wallet can be recovered from this single backup of the master seed.

Wallet words

Great news: an HD wallet needs a one-time secure backup of only the master seed, a single 128-bit or 256-bit value. This single value can be printed on paper and stored in an extraordinarily secure location.

Problem Statement. Even encoded in the efficient Base58Check format, a 128-bit or 256-bit master seed is going to be a MASSIVE pain to read and type with perfect accuracy if you need to recover your HD wallet.

Innovative Solution. Base 2048. No, seriously, encode the master seed using 2,048 plain-English (or Chinese, Italian, French, Japanese, Spanish) words. One dozen words for a 128-bit value and two dozen for a 256-bit value.

This encoding is called wallet words and is standardized in BIP-0039. This is ALSO so wonderfully clever that I wish I had thought of it.

The standardized dictionary of 2,048 words was carefully curated: all words have fewer than ten characters, no two words look alike or sound alike, etc. The vast majority of the words are easy to spell, which makes the inclusion of ‘broccoli’ somewhat hard to explain.

Thanks to wallet words, a complete HD wallet backup looks like this:

all hour make first leader extend hole alien behind guard gospel lava path output census museum junior mass reopen famous sing advance salt reform

If your printer is on the fritz, you can literally write your entire wallet backup in longhand on an index card. Use a Sharpie so the words don’t bleed if the index card gets wet (good think your ink jet printer was on the fritz).

Simplified payment verification (SPV)

There ARE advantages to running a full node with an attached wallet:

  • You interact directly with the peer-to-peer network without any intermediary.
  • You work with your own completely trustworthy copy of the bitcoin blockchain.

The previous chapter illustrated [ed: I DID warn you about such dangling statements] that running a full node is NOT the best option for most people. Setting aside concerns around the security of your home network, there remain the inescapable requirements for over 200 GB of available storage and an unmetered broadband Internet connection.

Problem Statement. Communicating to the peer-to-peer network through an intermediary may pose a single point of failure and compromise security. Running a full node resolves these shortcomings, but is impractical for most users. Ideally, a bitcoin wallet would interact directly with the peer-to-peer network without the overhead of a full node.

Innovative Solution. A simplified client that connects directly to the peer-to-peer network, interacts with multiple full nodes, and downloads only the select blocks and transactions needed by the wallet.

This is called simplified payment verification (SPV) and it is standardized in the bitcoin protocol. In fact, the idea appears in Satoshi’s first whitepaper.

SPV wallets deliver reasonably close to the benefits of running a full node. Like a full node, an SPV wallet discovers and connects to full nodes via the peer-to-peer network. This mitigates potential risks of transacting through a fixed intermediary agent, such as a bitcoin exchange and/or developer of the bitcoin wallet.

Be aware that some wallets use the SPV protocol but only connect to vendor-specific servers. If the features of SPV appeal to you — namely, you want your wallet to communicate DIRECTLY with the peer-to-peer network — pay close attention and select an appropriately independent SPV wallet.

First-generation SPV wallets downloaded only the blocks that contained transactions in the wallet. While this is clearly a win over downloading the entire blockchain, there was room for improvement. Downloading entire blocks is still quite a bit of data (especially for mobile wallets) and downloading SPECIFIC blocks could be used by a rogue full node to learn about the SPV wallet’s transactions. Which brings us to …

Bloom filters

One advantage to running your own full node is new transaction anonymity. That might sound counter-intuitive, since for every new transaction the initial (a.k.a. relay) full node is identified by IP address.

Full nodes are typically connected to a few dozen SPV wallets, thanks to the latter’s popularity. Full nodes support their SPV clients, providing them with blockchain data upon request AND receiving their new transactions.

On the peer-to-peer network, there is no way to discriminate between new transactions generated by an SPV client and new transactions generated by a wallet directly attached to the full node. Bingo! The full node enjoys a cloud of new transaction obfuscation, providing transaction anonymity.

SPV wallets enjoy the same benefits on the peer-to-peer network, because their new transactions constitute the aforementioned cloud at the full node. A residual concern is that the full node itself has complete visibility into the activity of its SPV clients, and a rogue full node could use that visibility for profiling purposes. This is not a security issue — it is a privacy issue. Even with visibility into its SPV clients, a rogue full node does not pose a threat to sending or receiving bitcoin.

Problem Statement. First-generation SPV wallets downloaded entire blocks, which is a lot of data relative to a single transaction of interest. Furthermore, full nodes had visibility into the transaction activity of first-generation SPV wallets. SPV wallets would benefit from smaller download requirements and greater anonymity on the full nodes serving them.

Innovative Solution. A bloom filter is probabilistic data structures that always returns the objects of interest and can optionally return additional objects. An SPV wallet specifies the parameters of a bloom filter to return all of the transactions in the wallet AND additional transactions for obfuscation. The SPV client submits the bloom filter to a full node, which returns a mini-cloud of transactions and space-efficient filtered blocks instead of full blocks.

Bloom filters were developed in 1970 by Burton (wait for it) Bloom and are described in BIP-0037 as an enhancement to the bitcoin protocol. The construct is a fantastic fit, because bloom filters produce no false negatives (all desired transactions are always returned) and can be tuned to produce a chosen degree of false positives (arbitrary transactions for obfuscation).

An SPV wallet inventories its transactions and sets the parameters of the bloom filter accordingly. One of the parameters establishes the degree of false positives, which provides a trade-off between obfuscation and the amount of data that must be downloaded. The SPV wallet submits the bloom filter to a full node. The full node matches transactions against the bloom filter — unaware of which transactions are “wheat” and which are “chaff” — and returns the mini-cloud of transactions to the SPV wallet.

For each returned transaction, the full node also returns the corresponding filtered block to the SPV wallet. The filtered block contains the entire block header AND the entire Merkle Tree [ed: yup, there’s an entire chapter on that]. The size of the filtered block is just 1% of the size of the entire block, yielding tremendous download efficiency.

The SPV wallet now has all of its transactions and their corresponding filtered blocks. For each transaction, the SPV wallet verifies that the transaction is present in the corresponding block: it validates the Merkle Path from the transaction hash to the Merkle Root, an exceptionally efficient process that requires checking at most a dozen hashes.

Export private keys in plaintext

This one may jump off the screen at you for any number of reasons:

  1. We just got done saying that recording the wallet words for an HD wallet can recreate all of your wallet’s private keys. So this sounds unnecessary.
  2. We’ve drilled home the point that knowing a private key equals control of the associated bitcoin. With that in mind, exporting all of your private keys in plaintext seems like a fundamentally BAD IDEA.

Let’s tackle these in order. Your wallet words CAN recreate your entire wallet, if you do not change wallet apps. Imagine that you install Awesome Wallet and write down the wallet words … your Mac/PC crashed … you buy a new Mac/PC and install Awesome Wallet … you recreate your entire wallet using the wallet words. That is an awesome wallet.

Now imagine that you start out with Awesome Wallet, but post MC/PC-crash you install Cool Wallet. Why on earth would you do that? For one, there are realistic scenarios in which you might not BE ABLE to install Awesome Wallet … the new machine runs a newer operating system, for example, and Awesome Wallet was never updated to support the new OS.

“But I can use the wallet words I wrote in Sharpie with any HD wallet, right? RIGHT?!?!” One would hope. Despite being codified in BIP-0032 and BIP-0039, different software developers have a funny way of interpreting specs. So your wallet words produced by Awesome Wallet MIGHT NOT perform a successful recovery in Cool Wallet. That would be ROYALLY F***ED.

The above scenario is NOT FICTIONAL. I was privy to it, and while there have been other times that I’ve regretted being “Volunteer IT Guy,” this particular time was BY FAR the least pleasant and most stressful. (Observation: the possibility of losing a pile of Bitcoin is MUCH worse that the possibility of losing a pile of digital family photos.) I’ve read of other people stuck in the same scenario under different circumstances. As “Volunteer IT Guy,” we installed the older version of the operating system, installed Awesome Wallet, took a VERY deep collective breath, and successfully recreated the wayward wallet using the index card inscribed in Sharpie.

That “scared straight” digression is not intended to throw HD wallets and wallet words under the bus. If you are going to rely on that combination for disaster recovery, however, you need to verify the recovery process by performing a dry run using a DIFFERENT wallet app for safety sake … and re-verify periodically to ensure you have a working path to recovery.

Wow, covering [1] certainly spilled a lot of ink. And that is why [2] is the ultimate “get out of jail” card. We’re talking about a plain text export of your private keys, laser engraved on a sheet of titanium — no, no, I’m kidding, though I am a HUGE fan of titanium. We’re talking about a plain text export of your private keys to a legible paper printout or reliable USB flash drive (better still, BOTH paper printout and flash drive) handled and stored in an EXTREMELY SECURE manner.

Not all wallet apps can import private keys, so the actual “get out of jail” process may be somewhat arduous. And there is the matter of UPDATING your repository every time you add a new private key. Hardly user-friendly stuff, to be sure. Nevertheless: all of your private keys in plaintext — held in an EXTREMELY SECURE manner — is DEFINITIVE long-term security for your Bitcoin.

Homework assignment

We’ve got our wallet checklist:

  • BIP-0032 compliant hierarchical deterministic (HD) wallet
  • BIP-0039 compliant generation of one-time wallet words for recovery
  • Simplified payment verification (SPV) DIRECTLY to the Bitcoin peer-to-peer network
  • Export private keys in plaintext
  • Continuing development to keep the wallet current and up-to-date

Your homework assignment before our next post? Find a wallet that checks all the above boxes. Easy peasy.

Next in the series: We have a Bitcoin wallet

Bruce Kleinman

Written by

entrepreneur & author, technologist & economist, consulting detective

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade