Bobcoin, blockchains, and cryptocurrency
I speak the pass-word primeval, I give the sign of democracy
By God! I will accept nothing which all cannot have their counterpart of on the same terms.
—Walt Whitman, “Song of Myself”
You keep using that word “blockchain”, and everyone nods sagely, as if to say, “Ah, blockchain, of course.” I have a sneaking suspicion, though, that most of us are a bit hazy on what a blockchain actually is. What are these blocks, why are they chained, and what does any of it have to do with money?
In my book Explore Go: Cryptography, you’ll learn all about codes, ciphers, secrets, randomness, and many other exciting things. Cryptography isn’t just useful for protecting private information, such as credit card transactions or chat messages. We can use cryptographic techniques to create the trust and security required for a whole new kind of currency. You’ve probably heard of it, right? Cryptocurrency.
Blocks and chains
In a previous post about AES encryption, I described the basic idea of a blockchain, and let’s quickly recap it here. When encrypting any kind of data, it’s convenient to split it into equally-sized chunks, or blocks.
But if each block is encrypted independently, that makes it easier for a malicious eavesdropper (traditionally nicknamed “Eve”) to figure out the encryption key. Also, there’s no way to ensure that a malicious intermediary (“Mallory”) doesn’t interfere with the message by dropping, replaying, or modifying some of the blocks.
One elegant solution to this is to not encrypt the blocks independently. Instead, we combine each plaintext block with the previous encrypted block before encrypting it. That means that in order to decrypt any given block, you need to have successfully decrypted all the previous ones.
The blocks are now chained together in a cryptographically secure way, creating a continuous sequence that can’t be tampered with undetectably. That’s great for secret messages, of course, but it’s also the kind of thing we need to implement a reliable digital ledger.
To see why, let’s meet two more members of the traditional cryptographic repertory theatre: Alice and Bob. Suppose Bob wants to create his own secure digital currency: “Bobcoin”, we’ll call it, without having any particular real-world cryptocurrency in mind. And suppose Alice wants to use Bobcoin to buy and sell things online.
How’s it going to work?
Let there be “Bobcoin”
The simplest thing would just be for Bob to declare to the world that Bobcoin is now open for business, and invite members of the public to exchange their dollars or pounds for the equivalent amount of Bobcoin.
There’s nothing to stop anyone creating their own fiat currency (Latin for “make it so”) in this way, and of course that’s how all currencies got started.
Traditionally, the exchange is done by a central bank—in this case, the Bank of Bob—which determines the rate of conversion. For example, Bob might declare that one Bobcoin is convertible to one US dollar. Alice pays in $100 and Bob credits her with a balance of 100 Bobcoin.
So far, so good, but what can Alice do with this balance?
Well, she can buy a pizza (from Pat, let’s say). No physical tokens, such as banknotes, need to change hands. Alice simply uses Bob’s banking system to transfer, as it might be, ten Bobcoin from her account to Pat’s. Pat checks her own balance, sees that the ten Bobcoin has been added to it, and she sends the pizza right along to Alice’s house.
Then maybe Pat uses the Bobcoin she just earned to buy a really cute torque wrench she’s had her eye on. And so forth. Round and round the Bobcoin goes: where it stops, nobody knows.
Or rather, Bob knows, because he keeps careful track of everyone’s balance. If Pat decides that she likes the reassuring feel of crisp, green paper (who doesn’t?) she simply asks Bob to convert her ten Bobcoin into $10, and then withdraws it from a nearby ATM.
The problem of trust
So far, so good, but we don’t really need a blockchain for this. Bob can just maintain a record of all the transactions and balances in the usual way.
But, if you think about it, it’s difficult for Bobcoin to scale up. If it really took off and everyone in the world started using Bobcoin for every online transaction, that would place a huge load on Bob’s servers.
Worse, it makes Bob a single point of failure for the global financial system. If Bob’s electricity goes out, commerce everywhere is brought to a shuddering halt. That would be bad, but even if Bob installs a UPS, which he should, there’s another problem. Why should everyone trust Bob?
They shouldn’t. Bob’s a good guy, I’m sure, but who’s to say that the prospect of stealing literally all the Bobcoin in the world wouldn’t turn even Bob’s head? He could be threatened or blackmailed into handing over the keys to the digital vault, or he might just lose them by accident.
Even if Bob is incorruptible and careful, he can’t know for sure that someone hasn’t sneaked into his system and left themselves a little back door, and nor can anyone else. As long as all the transactions are kept private, no one can see if anything nefarious is going on.
So the slightly surprising solution is for Bob to make them all public. He can take the digital ledger—the ongoing record of all Bobcoin transactions—and put it on a public file server for all to see.
Now if Bob, or anyone else, steals money, he can’t conceal those transactions: they’re a matter of public record, literally.
A distributed digital ledger
That removes the Bank of Bob as a single point of failure, but now we have a new one: the public ledger server. No problem: we’ll distribute copies of the ledger all over the place–perhaps to every computer in the world that uses Bobcoin for transactions.
Cool. But what happens when a new transaction needs to be recorded? Won’t the ledgers now be out of sync?
Yes, but only temporarily. Anyone making a transaction can send out a message about it on the Bobcoin network. All nodes on the network can listen for messages about new transactions, and use them to update their own local copy of the ledger.
This distributed ledger will be, in the term of art, eventually consistent. That is, if you wait long enough, every transaction will show up in every copy of the ledger, and everyone’s balances will agree. Not moment-by-moment, for sure, but within a few seconds or minutes, which is fine.
Or is it? I mean, electronic transactions can happen very fast. What’s to prevent some scammer, Sam, from spending the same Bobcoin twice in succession?
For example, suppose that Sam has a starting balance of ten Bobcoin, and they use it to buy a pizza from Pat. But then, moving quickly, before the transaction has had a chance to propagate across the network, Sam spends the same ten Bobcoin on an ice cream from Irene.
The double-spending problem
The distributed ledger will eventually reconcile these two transactions, of course. At that point, Sam will be overdrawn—they’ll have a negative balance—but maybe they don’t care about that. After all, they have the pizza and ice cream. It’s Irene who’s actually out of pocket—or Pat, depending on which transaction the network accepts first.
If Sam wants to make further transactions in the future, there’s nothing to stop them just opening a new account with a fake name. Then they can overdraw that account, and so on.
This would be bad news for Pat and Irene, and junk food vendors everywhere, not to mention the credibility of the Bobcoin system.
Clearly we need some way for Irene to verify that Sam actually has the money to pay for their ice cream. How could we do that?
Ordering transactions
Suppose Sam opens their account with a deposit of ten Bobcoin, and then makes two transactions: spending ten Bobcoin on a pizza, and spending ten Bobcoin on ice cream.
The second of those two transactions should fail, because Sam doesn’t have any money. But, given that Irene’s computer receives these transactions after a delay, and in an unknown order, how can she determine which one came first?
Let’s assume that the stream of transaction data is divided into equal-sized blocks, for convenience. Now the problem reduces to ordering those blocks. To put it another way, we need a way to chain the blocks so that we can detect any out-of-sequence (or modified) block.
Does that sound familiar? It should.
We already know about a kind of blockchain whose ordering is fixed, because each block depends on the previous one. That would be a block cipher operated in CBC mode: the “blockchain” we talked about at the start of this post.
But we’re not encrypting the Bobcoin transactions, because they must be public. How could we use the contents of a given Bobcoin block to produce a unique input to the next block, in a way that makes it impossible (or very difficult) to synthesise fake blocks?
In the next post, we’ll see how to use a hash function to chain blocks of Bobcoin transactions, and how to deal with problems like double spending, netsplits, and doomed stubs. We’ll also look at a fundamental, still-unsolved problem with cryptocurrencies: how to prevent them destroying the planet we live on.
