On May 18th, the Open Bitcoin Privacy Project published our first wallet ratings report. To my knowledge, this is the first publicly shared data that compares wallet privacy. We have many plans to hone and expand our analysis, but already it has revealed a wealth of insight into the current state and near future of Bitcoin privacy.

In this article, I’d like to take a look at how well mobile wallets stood up against wallets designed for running on desktop computers, and discuss some of the engineering problems that mobile wallets developers face. Mobile wallets are a special challenge because, even though our mobile devices are incredibly powerful compared to just a few years ago, they will always be relatively resource constrained compared to desktop computers due to their smaller size and reliance on batteries. The slower speeds, lack of permanent storage space, lower bandwidth, and inconsistent data connections make Bitcoin harder. The easiest way to remedy this is to turn mobile devices into dumb clients that outsource all of the work to servers, but of course this results in significant sacrifices of security and privacy.

This is to say nothing of feature phones, also known as “dumb phones,” which have even fewer resources and are currently far more widespread globally. But that’s a topic for another time.

Here are the ten wallets we rated for the Spring 2015 report, separated into mobile and non-mobile:

wallet scores
(Click or tap to enlarge.)

First off: savvy Bitcoin users may notice from this graph that the number one differentiating feature for all of the wallets scored was HD, short for Hierarchical Deterministic wallets. The lowest scoring wallets, including Blockchain.info’s current wallets on web and Android, Multibit Classic, and Coinbase all lack an HD architecture. I’ll tackle the reason for that in another post.

Despite the challenge of designing privacy into mobile wallets, they stacked up pretty well against desktop and client wallets this spring. In fact, the desktop/web wallets had an average score of 34.3%, while the mobile wallets had an average score of 38.8%. If we remove the non-HD wallets from the running as outliers, mobile comes in at 47% on average, just a few points below desktop/web wallets at 51.3%.

Desktop and Mobile wallets scored about the same as long as they were HD wallets.

The similarity in score between the HD wallets on desktop, web, and mobile has a lot to do with their similar protections of privacy on the blockchain: They all do an okay (but not great) job. OBPP’s ratings put a high emphasis on blockchain protections because the blockchain is the one indelible, utterly public record of financial information. As an investigator of Bitcoin transactions, I can ignore Bitcoin for a decade — store no data about it at all — but return after ten years to download the entire blockchain record with little effort. By then, blockchain analysis software will be sophisticated and cheap to purchase. In other words, if there is one place you do not want to leak user data to as a wallet company, it’s the blockchain.

Once we’ve conceded that these wallets are about equally mediocre at protecting privacy on the blockchain, the next place to look at is how they obtain their balance information for the addresses that comprise a user’s wallet. Armory’s greatest strength when taking the #2 spot was arguably its reliance on downloading the entire Bitcoin blockchain, allowing it to obtain balance information without giving any hints away. “Full nodes” of this kind will download all of the blockchain data and then sort through it offline to determine the balance information of addresses in their wallets. On the other hand, when you use any light client, such as Electrum, Multibit, or any of the mobile clients, you can avoid downloading the entirety of the substantial Bitcoin blockchain (currently around 34GB). This efficiency gain explains why all Bitcoin mobile clients are thin clients. The downside to using such a light client is that it becomes very difficult not to give hints away about which bitcoin addresses you’re most interested in when asking a server or network peer for balance information.

Imagine the following: the blockchain is a massive chalkboard in the sky on which all Bitcoin transactions are written. Full nodes are giants — they can read the entire chalkboard because they are so high up. They sure do consume a lot of resources, though, so there aren’t a ton of giants. Way, way further down on the ground, thin clients are dwarves. They have no chance of seeing anything on that board in the sky. They’re going to need to ask the giants what’s written on the board. They’re somewhat at the mercy of the giants, in fact, who can refuse to send messages down. But in terms of resource consumption, dwarves are efficient. It’s cheap to be a dwarf in this system, and so there are many of them.

The-Giant
A full node waiting for the next block in the blockchain.

 

How does a dwarf find out when a payment intended for him has been recorded on the board? It’s tricky. The dwarf is small, and so he can only receive short messages. He can’t ask for everything that’s been written on the board unless he wants to get crushed by a giant-sized scroll, so he’s going to have to ask for specific details. He can ask a giant directly, or ask a nearby dwarf who can ask another participant. One way or another, though, he’s revealing to his fellow dwarves and to the giants which transactions he’s interested in, losing financial privacy.

Mobile clients rely on Bitcoin peers or servers to find out when they’ve received a payment.

Addressing this on light clients remains an open research issue. For a while, we thought that a technique used by many light clients called “bloom filters” might help. Bloom filters were originally intended to reduce the size of the queries that light clients make. As it turns out, they do not benefit privacy. We’ve been bloom filtering in such a way to maximize efficiency, but at the cost of achieving little to no privacy gains. The research issue remains open because we’re stuck with a trade-off: we must choose a balance between efficiency and privacy in our current approaches. Desktop clients like Electrum and Multibit have some wiggle room for future improvement, since they have respectable computing resources and bandwidth to work with. Sadly, mobile clients are still handicapped when it comes to obtaining balance information privately. Even as mobile devices get more powerful and achieve better connectivity, allowing them to download and process more information, the Bitcoin blockchain is growing at an even faster rate. Returning to our dwarf metaphor: The dwarves are getting a little bit bigger all the time, able to see higher and pass along larger messages. But the chalkboard is getting bigger and higher up, as well.

Broadcasting transactions privately is similarly difficult for a light client. Back in fantasy land, dwarves want to get their transactions written on the big board in the sky. Only giants are high enough to do that. So, any dwarf is going to have to write his transaction details down, and pass the message around until it gets to a chalk-wielding giant.

Dwarves
Light clients are numerous, but individually resource constrained.

Desktop clients like Multibit have an array of privacy tools available to them for this step. Perhaps the most robust ability is to connect to the Tor network, allowing the desktop client to obfuscate its identifying details, such as its IP address. Configuring an application to connect through the anonymizing Tor network can be difficult, but there are operating systems, such as Tails Linux, dedicated to doing all of this configuration for the user. In fact, Tails even includes one Bitcoin client — Electrum — in its pre-installed bundle of software.

Mobile clients are not as lucky. In order to use Tor on mobile, you’ll likely have to void the manufacturer’s warranty by jailbreaking or rooting your device. That is to say, you’ll have to download some software from a (hopefully) friendly hacker to exploit a weakness and hack into your own phone or tablet. Often, recent versions of your mobile operating system will prevent such modifications for months with patches until friendly hackers can find a new vulnerability to exploit. Once you get your device jailbroken or rooted, the software available for mobile Tor use is still comparatively tricky to configure, riddled with bugs, and less thoroughly peer reviewed.

Privacy for thin clients is a challenge, but especially hard for thin mobile clients.

What’s a mobile wallet to do? In the second and final part of this series, I’ll discuss some of the countermeasures being used by desktop and mobile light clients, and further improvements recommended by the OBPP to get some privacy back from this dire state of nature.