Even for highly technical, long-time cryptocurrency advocates, using Bitcoin is difficult. Before you even get to the question of securing and backing up your private keys, you have to choose between the multitude of wallets available. If you don’t believe me that this is hard, listen to Andreas Antonopoulos, one of the most renowned and eloquent evangelists of the technology and author of Mastering Bitcoin. One helpful resource is the wallet comparison page on bitcoin.org, but in order to keep the amount of information manageable, it only has short explanations of wallet features that require a lot of background knowledge.
Those new to the space may wonder why there are so many choices and why there is no clear winner. Some wallet features like SegWit and BIP 70 payment protocol support could be added to any wallet with enough engineering effort, but there are certain other considerations that depend on the networking architecture. The way a wallet accesses and verifies blockchain data imposes a fundamental tradeoff between security and convenience, and no application can be best in class at both. Among the most important differences between wallet designs are:
- Storage requirements
- Computation/energy usage
- Bandwidth consumption
- Financial privacy
- Attack vectors
- Effectiveness of fee estimation
- Level of trust and centralization
There are a few general categories of wallets that strike a different balance of these properties. Let’s break them down, starting with the most secure and moving towards the more convenient.
Full Nodes
A fully-validating node is a participant in the Bitcoin peer-to-peer (P2P) network that downloads all blocks and transactions in the blockchain history and validates them according to the protocol-specified consensus rules. The node’s most essential responsibilities are to check that all transactions are properly signed and that there are no double spends.
The Bitcoin Core QT client is an example of a wallet integrated into a full node. The wallet uses the internal APIs and data stores of the full node to get blockchain state and broadcast transactions.
Running a full node offers you the greatest amount of control over your funds and best security possible. The downside is the high resource requirements, long initial sync times, and shortage of options. While Bitcoin Core is the most well-established full node with an integrated GUI wallet, it is not known for its user friendliness. The project incorporates new features slowly due to the strong desire for stability, the decentralized development model, and technical debt in the codebase dating back to 2009.
An alternative to the integrated wallet architecture is a decoupled design, where the wallet is separate from the network node and connects securely to a trusted full node for blockchain data. The wallet is a separate codebase, runs in a separate process or even host, and may index duplicated transaction or block data that is also stored in the node. This is essentially a client-server architecture, with the wallet as a client of a full node, communicating over a P2P or RPC network interface. The main benefit is that the modularity allows for greater customization of clients and diversity of options. Armory Wallet uses this kind of architecture, as does our custom wallet backend service at Coinbase.
Resources
With regards to storage and bandwidth, full nodes download and store on disk every block since the blockchain genesis, which at the time of writing is 513,400 blocks taking up 176 GiB. Note also that the time to sync the blockchain is greatly improved by using an SSD, which is more expensive than an HDD. Nodes also get notified of all new, valid transactions on the network, even ones that don’t end up getting confirmed. Computationally, full nodes perform must perform relatively expensive signature verifications, often more than one per transaction.
One option to reduce the storage requirements of full nodes is to discard old blocks after validating them (this has no effect on bandwidth or computing usage). Bitcoin Core supports the option to prune the amount of stored data to a minimum of ~3.5 GiB. The downside of pruning is that your node cannot serve historical block data to new nodes that are trying to sync from genesis, but the wallet functionality is mostly unaffected.
Privacy
Depending on the wallet’s usage patterns, it may be possible to analyze the movement of funds on the blockchain to extract more information about one’s finances. For example, say Alice pays Bob 0.1 BTC for some item, then Bob creates a transaction for a total of 100 BTC where one of the inputs spends Alice’s output. Alice can reasonably assume now that Bob had 100 BTC, which he may have not wanted to reveal. Leaking information through on-chain transaction patterns is a problem that all wallets suffer from, and I will not focus on it here.
What a wallet does have more control over is how much additional information is leaked to network peers. A full node running over Tor has the best possible privacy from a networking perspective, since peers cannot tell whether it is even hosting a wallet or just forwarding transactions relayed by other nodes.
Attacks
A full node offers the best possible security from blockchain attacks since all blocks are fully validated locally, though two attacks are still possible. The first is a 51% attack, where a miner or cartel of miners with over 50% of the network hash rate creates a fork of the blockchain with more proof-of-work than the current one and double spends funds that have already been assumed to be confirmed. Due to the economic incentives designed into the protocol, this has never happened in Bitcoin’s history.
Short of a network-wide 51% attack, the next worst-case scenario is a so-called eclipse attack. An attacker who controls all of the node’s network peers can theoretically execute a double spend attack by releasing a lesser-work, though still valid, chain of blocks with transactions that are double spent on the main chain. This, however, requires the attacker to create multiple, very expensive proofs of work, and the attack is thwarted if the node has just one honest, well-connected peer.
In the case of a decoupled architecture, a major consideration is securing the communication between client and server, especially if it is between different hosts. Since the network node is a fully trusted component, an attacker with the ability to man-in-the-middle the connection could report completely invalid transactions to the wallet as confirmed. One challenge is that Bitcoin’s P2P wire protocol is currently unauthenticated, though BIP 150 and 151 would provide a native solution if adopted. Currently available alternatives include SSH tunneling and network access controls.
Fee estimation
A full node can use transaction fees from recent blocks and in the mempool to estimate market fee rates and confirmation times.
SPV Wallets
Though a Bitcoin full node can be run on standard desktops and laptops, the resource requirements are far too great for mobile devices and syncing takes several hours in the best case. Fortunately, the Bitcoin protocol was elegantly designed to support client applications that only download transactions relevant to them with a high degree of security. Such applications are generally classified as light clients. Section 8 of Satoshi Nakamoto’s original white paper describes a mode called Simplified Payment Verification (SPV), where network clients only download the block headers and rely on compact proofs of transaction inclusion from full nodes.
In 2012, the lead developer on the Android Bitcoin wallet proposed a protocol extension to support SPV light clients. BIP 37 added new messages to the P2P protocol allowing nodes to fetch partial blocks, including only some transactions in the full block. In order to let the full node know which transactions it cares about, the client sends a Bloom filter of all its addresses upon connecting, then the node filters for transactions that pay to or spend from them. Since Bitcoin headers contain Merkle tree commitments to transaction data, the node can prove that transactions are committed in a block, given just its header and a small Merkle branch. A BIP 37 light client just has to fetch and validate all block headers from its peers, upload the Bloom filters to them, then download only the transactions that are relevant to it. Even though the client does not validate blocks according to all consensus rules, it makes the assumption that the majority of the network hash power is mining valid blocks due to economic incentives.
Resources
Both storage and bandwidth requirements are minimal because only blockchain headers and relevant transactions are downloaded and stored. Each block header is 80-bytes, which amounts to a total of ~40 MiB at the time of writing. Computation performed is also significantly reduced because blocks and transaction signatures are not validated. Applications can even discard headers for all blocks prior to the wallet creation date.
Privacy
There is a tradeoff between privacy and bandwidth usage, which can be tuned by adjusting the false positive rate of the Bloom filter. In theory, more false positives creates a greater anonymity set of a client’s requested data, but at the expense of more data downloaded. In practice, however, it has been shown that due to implementation flaws, the Bloom filter mechanism provides virtually no privacy over directly revealing the account’s set of addresses to all peers.
Some light wallets provide the option to improve privacy by connecting to a trusted full node, which is a kind of hybrid between true SPV and the decoupled full node architecture mentioned above.
Attacks
Since SPV clients download all headers and follow the chain with the greatest total work, the method of attack is the same as on full nodes: 51% attacks and eclipse attacks. The risk for SPV clients is greater, however, because a successful attacker can not only double spend, but forge completely invalid transactions. This means an attacker controlling all of a client’s peers can undetectably make a transaction to the victim using funds created out of thin air. The best protection is waiting for more confirmations than a full node otherwise might, to raise the cost of the attack.
BIP 37 also permits another attack on light clients, where a full node can omit data that matches the client’s filter. While this perhaps has limited risk for regular wallets, some smart-contracting applications like Lightning Network nodes critically rely on the ability to detect certain transactions.
Fee estimation
Dynamic fee estimation is a significant challenge for light clients since they do not have access to historical block information or a complete transaction mempool. The best strategy currently is to get estimated fee rates from a trusted service or ask the user to enter one themselves and raise it if necessary using Replace-by-Fee (RBF).
Electrum
Electrum is a popular Bitcoin wallet that also uses SPV validation of transactions, but connects to specialized servers instead of connecting directly to the Bitcoin P2P network. The server connects to a locally running Bitcoin full node and indexes additional information in order to quickly serve client queries. Since the software is open-source, servers are run by many parties, not one central entity.
Clients connect randomly to a selection of Electrum servers, from which they download Bitcoin block headers and relevant transaction data. Like BIP 37 clients, Electrum wallets validate headers from all connected servers and track the longest proof-of-work chain. The wallet then chooses one primary server to retrieve block data from and sends it all of the wallet’s addresses. The server uses its index of transactions by address to notify the wallet of transactions in the blockchain that send to or spend from them. With each notification, the wallet downloads any new, relevant transactions along with Merkle proofs of inclusion in the header chain.
Overall, this architecture is similar to BIP 37 but more centralized because there are fewer Electrum servers than BIP 37 serving full nodes.
Resources
Bandwidth usage is more efficient because there are no false positive matches on the address set, but storage and computation is similar.
Privacy
Privacy depends on trusting Electrum server operators not to keep logs, and clients don’t even get the weak privacy that Bloom filters provide. Factoring in greater centralization as well, the story overall is pretty poor.
Attacks
The same 51% and eclipse attacks on BIP 37 SPV clients are possible, though may be easier or more difficult to execute depending on the assumptions made about an adversary. On the one hand, there are fewer servers that an attacker needs to compromise to feed an invalid header chain. On the other hand, Electrum uses TLS to authenticate servers, whereas Bitcoin P2P connections are unauthenticated, so an attacker would have a more difficult time executing a MITM attack. Essentially, this places more trust in the servers and less trust in the network.
Fee estimation
Electrum wallets get fee estimates from the primary server, though users can tweak the value as desired. In the worst case, a malicious Electrum server could coerce a client into overpaying on fees.
Client Side Filtering Wallets
As mentioned above, the fact that SPV clients may not be notified of transactions when connected to a faulty peer is a big problem for lightning nodes. Specifically, lightning nodes are constantly watching the blockchain for evidence of their counterparties cheating by releasing a past channel state. Missing such a transaction could result in loss of funds.
In an attempt to fix this and some of the other issues with BIP 37, lightning developers put forward a proposal for an alternative light client mode that is starting to gain traction in the community. The concept is that instead of clients sending Bloom filters of their addresses to servers and downloading matching transactions, nodes serve deterministic Bloom-like filters of block contents to clients, which can decide to download blocks in full or skip them. Assuming clients are able to obtain correctly crafted filters, they are not vulnerable to peers omitting transactions and can improve their privacy by downloading blocks from multiple sources.
As specified in BIPs 157 and 158, the client first downloads headers and filters for all blocks after the wallet creation date from multiple peers. Using chained commitments like those of the block headers themselves, BIP 157 allows clients to efficiently check agreement on the filter headers among all peers and ban any attempting to serve invalid filters. This means that a client with at least one honest peer serving block filters is guaranteed to see all transactions relevant to it. Already there is a preliminary implementation of such a client called Neutrino, created by Lightning Labs.
Resources
This type of light client must download filters for each block after the wallet creation date as well as every full block containing even one relevant transaction. Basic block filters on average are ~3% the size of each full block, including witness data. The number of full blocks downloaded depends on how active the wallet is. Furthermore, unlike SPV clients, these wallets cannot filter unconfirmed transactions effectively, so the only options are to download all unconfirmed transactions or none. There are on average 250 KB of new transaction data per minute on the Bitcoin network.
While bandwidth usage is higher, the clients can discard most of the data they download, so storage and computational demands are the same as on SPV clients.
Privacy
A primary benefit of this proposal is improved privacy over SPV clients. The main reason is that peers serving blocks to a client cannot determine which transactions within the block it actually needs. Furthermore, the full blocks are downloaded from different sources, so that no one sees the complete set of blocks relevant to the client, foiling intersection analysis. This is an example of the general tradeoff between bandwidth usage and privacy: more data downloaded creates a larger anonymity set for the data the client actually cares about.
Attacks
Unfortunately, this type of light client is no less vulnerable to 51% and eclipse attacks than SPV clients. BIP 157, however, does provide protection against nodes forcing wallets to miss transactions.
Trusted Server, Local Key Wallets
As noted above, full nodes demand significant resources and SPV clients leak sensitive financial information to untrusted nodes and are susceptible to more attacks. User experience on both suffers as well because of the initial header sync, which can take more 15 minutes on mobile devices.
Another common wallet architecture for resource-constrained devices is to keep keys locally and connect to trusted backend servers for blockchain data. This model is employed in different forms by the Copay, Mycellium, and Blockchain.info wallets, to name just a few. When the user wants to send funds, the backend service generates an unsigned transaction and sends it to the client. The client can then validate the amount, fees, and destination of the transaction and add signatures. Since the private keys never leave the client, they remain secure even if the backend is compromised; however, other attacks are possible as we will see in a second.
For users who would rather trust a known company, this security model may be more comforting than SPV security, and these wallets are often quite easy to use. On the other hand, a centralized, trusted service carries many of the risks that led to Bitcoin’s creation in the first place.
Resources
There are no significant resource requirements for these wallets as they query a backend server for relevant transactions and do not need to download headers. This means a user can begin using the wallet immediately after generating and backing up their key material.
Privacy
All addresses are known by the server. Taken even further, some wallets like Copay keep an HD extended public key on the server, from which all future addresses belonging to the wallet may be derived.
Attacks
The most interesting question with this architecture from a security perspective is how the connection to the backend is secured. A compromise of the backend can result in the wallet seeing confirmed transactions without the attacker creating any proofs-of-work.
Mycelium uses Tor hidden services and pinned certificates hard-coded into the source code, which provides the best degree of cryptographic authentication. Copay wallet uses TLS to connect to the Bitcore backend servers, which introduces certificate authorities into chain of trust. Blockchain.info also relies on TLS, but an attacker who steals the certificate can not only intercept requests to the backend but also serve a malicious web client. This could result in private key material being stolen, unlike any other attack possible so far.
Fee Estimation
Fee rates are set by the trusted backend server when it generates the unsigned transactions.
Custodial Accounts
The most centralized type of Bitcoin wallet is a custodial account like Coinbase (disclose: I work there*). Here the private keys are managed by a fully trusted entity, which generates, signs, and broadcasts transactions to fulfill user requests.
In this category, Coinbase remains a popular option on desktop and mobile, even despite statements that Coinbase is not a wallet, because of the ease of use. Many customers do not understand or feel comfortable managing private keys themselves and prefer to use a more traditional service with a username and password and account recovery features. Another large benefit is that sends to other users on the platform can be done off-blockchain, incurring no network fees.
The trust model for privacy and security is markedly different for custodial accounts than any of the other wallets discussed. Security conscious providers like Coinbase are able to pool customer funds together and keep a large majority stored in highly secure offline keys, called cold storage. They also are able to hire teams of full time security and cryptocurrency experts to protect customer holdings. Again, however, the increased centralization also has its drawbacks. For one, custodial accounts are subject to local laws and regulations and may not be available for everyone, and companies providing such services are required to have KYC/AML policies. Also, transfers into and out of the account can be delayed for a long time in the event of high traffic or technical issues. And in the worst case, there is always a risk that the custodian gets hacked or otherwise loses access to funds, which has unfortunately happened repeatedly throughout Bitcoin’s history. The golden rule of Bitcoin is that if you don’t own the private keys, you are not in control of the funds.
Resources
These apps use the minimum possible resources since all work is offloaded to managed servers.
Privacy
There are advantages and disadvantages to a centralized privacy model. Because customer funds are pooled, individuals actually get enhanced privacy from anyone trying to deanonymize their transactions by watching the blockchain. For example, if Alice sends Bitcoin to Bob’s custodial account, the transaction spending that output is almost certainly not Bob’s transaction. On the other hand, the account provider has total visibility into all customer transactions and, depending on local regulations, could be subpoenaed for information about a particular account by the government. This is essentially the same type of privacy that one gets using a regular bank account.
Attacks
There are two main security concerns with custodial accounts: 1) an individual account getting hacked and 2) the custodian getting hacked.
Account compromises can happen in a variety of ways such as phishing, phone porting, weak passwords, and so on. Custodial account services can help customers secure their accounts by enforcing strong passwords, offering two-factor authentication based on TOTP, and providing features to whitelist withdrawal addresses or time-delay withdrawals of large amounts.
Aside from securing one’s own account, is important to do diligence on the custodian’s security practices and track record before opening an account. You can read here about some of the security measures Coinbase implements, for example.
That was a whole lot of information that I will attempt to state in one table:
So if all wallets have issues, how are you supposed to choose one? The good news is that you don’t have to — you can have have multiple wallets for different use cases! For example, I keep multiple wallets: a mobile one that I use for day-to-day spending (well, when fees are reasonable), and a more secure one for longer-term hodling. The important thing is to understand the differences and choose appropriately based on your needs. The decision ultimately boils down to how much you value privacy and ease of use, and how much money you are storing.
There may never be a perfect solution, but there is still a long way to go in designing better, privacy-preserving, secure, trustless, and convenient Bitcoin wallets. Stay tuned for my next post on what features we may see in the next generation of light clients, and what it will take to get them.
*Jim is an engineer on the Protocol team at Coinbase. This post reflects his own opinions, and not those of the company. That said, we are hiring engineers, so you should apply.
Thanks to Josh Ellithorpe and Varun Srinivasan for reading drafts of this post.
