Recently, there has been a considerable amount of interest in making Bitcoin usable in environments where the technological comforts that we take for granted every day are simply not present. Kipochi is in the process of developing a Bitcoin wallet that works over cell phone text messages, allowing people with ordinary “dumb phones” in Africa (which are, despite the continent’s general poverty, nearly ubiquitious throughout the region) to use Bitcoin simply by sending and receiving text messages. More recently, Coinbase has done the same thing. In Austria, Mycelium Media is in the process of developing a “Bitcoin card” that is essentially a fully-fledged physical Bitcoin wallet capable of holding money and sending and receiving transactions but is only the size of a credit card – thickness included. The company is also releasing Mycelium Wallet for smartphones running Android, and on the iPhone Gliph is finally breaking through in rolling out a Bitcoin solution. The future of Bitcoin, it seems, is mobile, just like the future of everything else in our modern world.
The problem is, however, how do you actually tell the wallet who to send to? On the desktop, the solution is simple: copy and paste the recipient’s Bitcoin address. And for those who don’t like addresses, the Bitcoin developers are coming up with a payment protocol that substitutes them with a system of payment requests. On smartphones, scanning a QR code seems to be the ubiquitous answer. Problem solved? Not quite. All of these solutions certainly have their place, and when they work they are certainly very effective ways of identifying who you intend to send money to. On the desktop, all commerce is e-commerce, so if you don’t have an internet connection to send Bitcoin transactions and receive sending addresses over then you also do not have an internet connection to find anything worth paying for. In person, however, the situation is different. In theory, there are of course solutions for everything; if you want to send to a merchant, you scan a QR code from their own mobile application. If you want to send to a phone number, type in that phone number and the SMS wallet’s backend will figure out what Bitcoin address belongs to that particular number. Want to send to an email address? Same thing.
However, perhaps the single most undervalued rule of usability design in general is this: do not optimize for the case of how things work when they work. Rather, optimize for the case of how things work when they don’t work. People can figure out their way around unintuitive software quirks if those quirks are predictable; however, people with little background in Bitcoin are going to have a very hard time getting around the corner cases that leave even Bitcoin afficionados whipping out their laptops and opening up command line interfaces. Anyone who actually spends time in in-person Bitcoin environments knows that the internet is often missing or not present at all, merchants don’t yet have a wallet application installed, you’re trying to send to a QR code printed on paper or, worst of all, the phone is not working and there is no QR code printed on paper, leaving you no choice but to type in a 34-character address manually, on a smartphone keyboard.
The case of SMS wallets is similar. Right now, we have Kipochi and Coinbase, and they do not even serve the same region. What if, in two years’ time, we’ll have three different SMS wallets serving every region, and people using different wallets want to transact with each other. Currently, the best that we have is a very poor solution: every provider forces everyone to have an account. If you send money to a phone number with your Coinbase SMS wallet, and that number does not yet have Coinbase, then the system that will soon be implemented is that that phone number will receive instructions on how to create a Coinbase account to retrieve their money. With one provider, this works fine. But suppose there are five; suppose, in 2015, that there are SMS wallets run by Coinbase, blockchain.info, Kipochi, Bitstamp and BIPS, and each of them works in the same way.
The result is obvious: each and every person would need to keep track of five different accounts. The five companies could come together and create a common database, but this runs the risk of creating a centralized and anti-competitive ecosystem; if a new company wants to join, they essentially need the existing consortium’s permission. How do we create a decentralized common database? Well, we already have the blockchain, and it is certainly not difficult at all to design a common protocol for registering your cellphone number by sending a specially formatted transaction (essentially, this involves sending 0.0001 BTC to a fake Bitcoin address encoding your number, and SMS wallet backends can detect these transactions and search through them). However, that will take work to create, and for now, once again, Bitcoin addresses are all we have. The moral of the story is this: Bitcoin addresses are the ultimate fallback, and to make wallets what “work when they don’t work” it is simply necessary to have a good way of entering them.
Enter Firstbits
The idea behind firstbits has been around for nearly two years now. Essentially, how it works is this. The firstbits of an address is simply the first few characters of that address, converted to lowercase; the first bits of 1McqmmnxRwZRCpD2VoGEMzCYcdeXYvCBsB, for example, is “1mcqmmnx”. To recover the address from a firstbits, simply take the first Bitcoin address to appear in the blockchain that matches that firstbits. Because the first Bitcoin address is used, there is no ambiguity, and future blocks cannot change a firstbits to address mapping that already exists. To determine exactly how many characters to use, simply try just the first character of your address, then the first two, then the first three and so on until the firstbits maps to your address. “1mcqmmn”, for example, maps to “1McqmmnNB7urUowJULWHnSfKio8fw7a55m“, but “1mcqmmnx” maps to 1McqmmnxRwZRCpD2VoGEMzCYcdeXYvCBsB as desired (and so do, and forever will, “1mcqmmnxr”, “1mcqmmnxrw” and so on), so we use “1mcqmmnx”. The result is an “address shortening” service, similar to URL shorteners like bit.ly, but which is an open standard requiring no centralized gatekeepers.
The idea has been out there, it seems obvious, and yet for some reason almost no wallet providers have tried to integrate it. The obvious question is: why? As it turns out, the majority of Bitcoin developers are against it. The arguments given in the above linked Bitcoin wiki page are as follows:
- Firstbits enourages Bitcoin users to generate addresses with “interesting” firstbits and “claim” them by sending a transaction to those addresses just to make sure they make it into the blockchain, similar to the practice of “domain squatting”, or registering short domain names on the internet with the aim of selling them later at a profit. This increases blockchain bloat, meaning that miners have to store a larger amount of transactions, and also means that if firstbits becomes widely used anything shorter than a 7-letter firstbits will become impossible.
- Firstbits is vulnerable to confusion; for example, Wikileaks deliberately created a Bitcoin address starting with “1snow” for their Edward Snowden fund. However, the actual firstbits of that address is “1snowq”, with “1snow” itself going to “1SnowmhKHWcKZCFcv7Qjtg3jqhW2f3naZ“. Similarly, the firstbits of the Bitcoin Foundation’s addrss, 1BTCorgHwCg6u2YSAWKgS17qUad6kHmtQW, is “1btcorgh”, not “1btcorg”. Fortunately, no one was caught by this accidental trap, but if firstbits was more commonly used, people might be.
- Many developers hold the position that “Bitcoin was designed such that addresses should only be used once”. Thus, the whole idea of creating a “vanity address” (whether “1snow…”, “1BRMLAB…” or “1BTCorg…”) starting with some specific easily memorable prefix and widely publicizing it for long term use should be strongly discouraged.
- It’s impractical for the average Bitcoin client to maintain a firstbits database, as such a database would be gigabytes in size. Therefore, firstbits requires central service providers, and so it would be better to just use a proprietary database so as to avoid the other three problems described above.
Some of these arguments have merit, and some may or may not have merit depending on whether or not you think blockchain bloat is a problem; others, however, completely miss the point. The argument about “firstbits” squatting is a decent argument against using “vanity firstbits” like “1brmlab”; however, what it misses completely is the fact that vanity firstbits is not the main point of firstbits; rather, the main point of firstbits is to let people enter a few characters of an address manually and have it autocomplete. This can be done with any address. “Domain squatting” all possible addresses above about 7 letters is impossible; even at 7 letters, claiming half of them requires claiming 32 billion addresses, or over a hundred times the current size of the blockchain. As for confusion, the solution is simple. On the user side, user can be more careful and type in nine characters instead of seven; this reduces the risk of a mismatch by a factor of over a thousand. On the software side, the software should always give the full address back and ask for confirmations; on an SMS wallet, the interaction might look like this:
> send 0.01 1mcqmmn
1McqmmnNB7urUowJULWHnSfKio8fw7a55m
Correct? (yes / no)
> no 1mcqmmnx
1McqmmnxRwZRCpD2VoGEMzCYcdeXYvCBsB
Correct? (yes / no)
> yes
Sent 0.01 BTC to 1McqmmnxRwZRCpD2VoGEMzCYcdeXYvCBsB.
If you need to pay people remotely (eg. you’re an employer and you want to give your farm workers 1 BTC per week but you won’t always be there yourself), you can simply store the full address, or even just half of it, in your phone’s address book, and then get the firstbits from there when needed. Another use case is on a smartphone; there, the interaction is similar, but more fluid; one might imagine the Android app showing the current firstbits completion of a given address in grey in the textbox while you write it. Leaving the textbox implies acknowledging that a given completion is correct.
Lastly, there is the “centralization” argument. When making this claim, what opponents of firstbits fail to understand is that there are several degrees of centralization. At one end, there is full centralization, where everything relies on one, completely trusted, central authority; a good example is Facebook. At the other end, there is full decentralization, where all nodes are essentially equal. Here, we have perhaps Bittorrent. In the middle, there is the concept of “federation”: centralized providers exist, but they all follow a common protocol, there are many to choose from and each one can be swapped for any other in an instant. Email providers, Bitcoin mining pools, Bitcoin block explorers and Ripple gateways all fall into this category – and so do Firstbits providers.
Federation is not perfect, but it is a massive improvement over centralization; if email was not federated, users of different email providers would have a hard time communicating, and it is quite likely that today there would be only one email provider of any scale left standing. With federation, there are businesses and institutions, but it is much harder to lock out new competition, betray one’s customers or become a monopoly. In the case of Bitcoin address shorteners, it also means that a wallet can query three servers run by three different institutions, preventing any one of them from substituting in their own Bitcoin addresses in a fraudulent attempt to seize bitcoins in transit. Bitcoin address shorteners like btc.to are centralized; firstbits is federated.
Firstbits is certainly not a panacea; at best, it will remain a backup option, as in most cases copy/paste, QR code scanning and sending to emails and phone numbers will work fine. It does not even always work; if an address has never sent or received any money, then it is not in the blockchain and so firstbits has no way of recovering it. However, in those cases where it can be used, it is invaluable. Having to type in seven to nine characters on a smartphone is annoying, and on a dumb phone with only twelve buttons for 0-9, * and # it is quite hard. However, typing in an entire thirty four characters is brutal.
So what is the next step? If a firstbits server exists, implementing firstbits is easy; just call the API and get the address back. And a firstbits server does exist, in the form of blockchain.info; to see the API in action, just open up http://blockchain.info/q/resolvefirstbits/1mcqmmnx in your browser. Using ‘getfirstbits’ instead of ‘resolvefirstbits’ does the inverse operation. However, this server is not always reliable, and has been known to go down at times. Thus, what is needed is for more companies to do the same, and ideally for someone to create an open-source version. Caution is important; the service must do the same thing as blockchain.info in case two addresses with the same firstbits appear for the first time in the same block. Getting bitcoind to include a firstbits database may seem like the best solution of all, but this would be excessive; firstbits requires an entire database of its own, so it is not worth the bloat to have every single full Bitcoin node running one. Once firstbits is implemented, well, it will be one small step closer to making Bitcoin convenient and easy to use for the masses. These days, nearly everything has some form of “autocomplete” functionality; so why not Bitcoin addresses as well?
