Red Team Blues

Since I started my career as a Cassandra of Cryptocurrencies I haven't had much time to read novels; I have too much fun reading about the unfolding disasters. But I did enjoy Cory Doctorow's Little Brother and Homeland, so when he asked me to review Red Team Blues I sat down and read it.

The first thing to catch my eye was the dedication to the late, great Dan Kaminsky, a fellow attendee of the Asilomar Microcomputer Workshop and someone I admired.

It is an engrossing read. The action moves swiftly, the plot requires little suspension of disbelief and has plenty of twists to keep you thinking. The interesting parts are the details about how people and their money can be tracked, and how people with a lot can prevent it being tracked. Doctorow gets to cover many of his favorite themes in a fast-moving story about a character approaching retirement. I'm well past that stage, but I understand some of those issues.

The story ends happily because all the bodies that pile up are bad guys. This is necessary since this is apparently the first in a series. I'll definitely read the next one.

You don't need to understand blockchains and cryptocurrencies to enjoy the story, but I do so, below the fold, I can't resist picking some nits with the technical details.

David Gerard explains the technology:

Trustlesscoin, a cryptocurrency blockchain that solves the Sybil problem with secure enclaves. (See Mobilecoin for one real-world example.)

There are two reasons why something like Trustlesscoin is a bad idea:

• The one that Doctorow uses as the MacGuffin for this story, which is that the keys can leak. (See Western Digital for an up-to-date example). Leaking of the keys would lead to a catastrophic failure of the system, in Doctorow's telling to a $1.2B loss, and much other damage.
• The one that Doctorow doesn't discuss, because it would spoil the story, is that "secure enclaves" are just software running inside a hardware "moat". As with all software, the software inside can have vulnerabilities, which can also lead to a catastrophic failure of the system. See Intel's SGX for an example.

Now it is true that the precautions manufacturers take in practice, which don't include handing the keys to their friends as they did in Doctorow's story, make both of these failures improbable but, the examples above show, not impossible. As I've been writing since at least 2015's Brittle systems, systems such as Byzantine Fault Tolerance that work perfectly until they meet a situation they can't handle then fail abruptly and completely are bad engineering. They aren't tolerated in life-critical physical systems, and they ought not to be tolerated in critical software systems either. Unfortunately, building software systems that fail gradually and controllably is beyond the state-of-the-art. The best that can be done is to build in ways to recover after a failure. One of the genuinely impressive things about Nakamoto's Bitcoin protocol is that, if the miners can take coordinated action, it is possible to recover from a 51% attack. Of course, if the miners can take coordinated action, they can mount a 51% attack, so it is a double-edged sword.

In Doctorow's story the initial need for the keys was not theft, but the ability to rewrite the blockchain in the case of a bug. In the cryptosphere this is normally managed without rewriting by a "hard fork", as Molly White discusses in Blockchain-based systems are not what they say they are:

the case of The Dao, a project that is often described as the first ever DAO. In June 2016, attackers exploited a vulnerability to steal 3.6 million ETH (then about $50 million) of the project’s 11.5 million ETH (about $160 million). And so the Ethereum blockchain was simply “hard forked”, resetting the funds into a recovery address where they could be returned to the community. This was not a one-off mulligan in the early, Wild West days of blockchains and DAOs: Polygon hard forked after the discovery of a huge vulnerability just this December.

But surreptitious blockchain rewriting isn't unknown. Two excellent summaries of investigations by @cryptohippo65 and DataFinnovation, Dirty Bubble Media's The Binance Scam Chain and Patrick Tan's Binance Built a Blockchain, Except it Didn’t, reveal that Binance routinely rewrites the Binance Chain.

And now for a couple of really minor nits that are clearly allowed by the artistic license:

• A Walmart parking lot in Menlo Park? The nearest one is in Mountain View.
• A laptop with a hard drive? How long is it since laptops you could buy at Fry's had SSDs instead of hard drives?