Bitcoin in Brief

My first encounter with Bitcoin was probably in 2013, when I wound down my startup and returned to Juniper. For a while, over lunch, my colleague Dong-ge would often hold forth with great animation about anecdotes concerning Bitcoin and Satoshi Nakamoto, along with his amusing experiences doing quantitative trading, and he frequently urged me to look into the subject too — even though I didn’t feel much about it at the time. Having been through a dreamlike entrepreneurial journey, I was still struggling to adapt to the identity of a nine-to-six office worker, and at the same time planning my eventual physical escape over the Great Firewall. I skimmed some Chinese-language online material about Bitcoin, casually equated it with electronic money, never read Satoshi’s paper or followed a single technical article about Bitcoin, and put it out of my mind.

I was dragged back into the world of Bitcoin in August or September of last year. A friend wanted to try quantitative trading — I remembered that Dong-ge had done this before, and I found the whole thing rather interesting, so I pulled him in, and in our spare time we hastily built a demo with Elixir and Datadog (see my article: ). Later we all felt that it required a considerable amount of capital, that the returns after trading fees weren’t large, and that we didn’t have enough time to polish it carefully, so we didn’t continue.

Both encounters with Bitcoin were mere passing brushes; I never touched its core. All my knowledge about Bitcoin and blockchain came from gossip outside the technical community. Then recently, my friend Lao Mao’s ArcBlock caught my attention — less than twenty minutes after ArcBlock’s ICO public sale began, it was declared sold out, and because retail investors’ enthusiasm was so excessive, it caused a massive backlog of Ethereum transactions and quite a stir. When Lao Mao talked about the journey that drew him in, he put it this way: “If I don’t understand something, either the thing itself is unreliable, or my abilities are limited and I haven’t seen through it. But if reliable people are doing an unreliable-seeming thing, then maybe I’m wrong: the thing itself is reliable, and I simply haven’t seen through it. When my Microsoft colleague Flavien Charlon, a virtuoso I deeply admire, also came out to work on colored coins, I was shaken. I began to take blockchain seriously.”

(Ethereum tx congestion)

I was momentarily dumbstruck. Was my indifference to Bitcoin and blockchain technology also a case of my failing to understand, to see through, a technology that was in fact sound? At Lao Mao’s urging, I resolved to dig truly deep into blockchain’s technical details and investigate the real reason why so many formidable people had become fascinated by it (technically speaking). I gathered a batch of papers and white papers, downloaded a number of source trees, found various articles, and then began rolling up my sleeves and reading on weekends. After a hasty first pass through Bitcoin’s founding paper (“Bitcoin: A Peer-to-Peer Electronic Cash System”), some white papers, and various articles and videos, I increasingly felt it necessary to understand the fundamental questions — especially since mainstream technical explanations were all superficial. For example:

• Why PoW?
• What does blockchain’s data structure actually look like?
• Why is a block designed to be 1 MB, and why is the interval between blocks fixed at 10 minutes? What happens if it takes more or less than that?
• Why is the total supply of coins 21 million? (Why the hell isn’t it a power of two? Or some larger/smaller number?)
• Why is a transaction designed so strangely, with multiple inputs and multiple outputs?
• Why must something as seemingly simple as verification be done with opcodes?
• If an open ledger is used, how are security and privacy guaranteed?
• WTF base58?
• Why don’t wallets use the public key directly, instead of hashing it first — isn’t that redundant?
• Why are empty blocks containing no transactions (other than the incentive transaction) allowed to exist? Why doesn’t everyone exploit this to game the system and gain a first-mover advantage?
• What exactly is a wallet? Does a wallet need the data of the entire chain?
• Is quantum computing the end of Bitcoin?
• Why — why could a scholar in 2008 think so clearly and calmly toward the future, and program toward the future? Ten years later, his proposed architecture has needed only minor patches, and as a ledger it has no major problems (Ethereum is solving problems that Bitcoin never intended to solve)?
• …

The list of questions was nearly endless. Armed with these exciting questions, I reread Satoshi’s paper. Compared with my earlier carelessness, this time I read it almost on my knees. To fully digest those eight short pages, I also went through many of the emails in which he explained the paper to others at the time (thanks to mail-archive), as well as some early articles by Vitalik interpreting it. I found myself in the ecstasy of “the more you know, the more you don’t know” — a bit like Alice falling down the rabbit hole, or an indescribable kind of serendipity. I had finally moved from my former ignorant innocence into a state of knowing shame and then summoning courage.

True to my learning-by-teaching compulsion, after my second read of Bitcoin’s founding paper, I hurriedly made slides and presented to my team the exciting thinking and implementation inside Bitcoin. I won’t post the slides one by one; below is one page:

This single page alone raises a great many questions worth asking:

• Why are the values in this data structure stored in little endian? Is this a design flaw or a deliberate choice? (Don’t jump to conclusions; consider that the conventional network byte order is big endian.)
• Why, when computing the nonce, do we not use the entire block, but instead select these fields (even though integrity is still guaranteed through the Merkle root)?
• Why go to the trouble of organizing transactions into a Merkle tree?
• …

Enough said; go download and read it for yourselves at github.com/tyrchen/unchained (I’ll update it as I learn).

A digression. In the Internet era, being an engineer who develops network protocols (a “neteng,” for short) is a thankless job. The value chain has moved upward, turning network equipment and infrastructure into commoditized pipes: applications make all the money, while infrastructure barely earns enough to get by. Although one shouldn’t use the analogy “making atomic bombs earns less than selling tea eggs,” it is an indisputable fact that a neteng with ten years of experience earns less than a scripting kid with two or three. In terms of difficulty, the neteng who spends years wrestling with red-black trees, skip lists, ring buffers, and hash tables, writing a piece of code that forces consideration of endianness, defining a data structure with an eye toward fitting within a cache line, sometimes wishing he could account for every single bit — such a neteng has a much harder job than the scripting kid who throws caution to the wind, stuffs everything into an object (dict/map), has never heard of what a cache line is, and uses JSON even to transmit a single bit. Unfortunately, if you’re not upstream in the value chain, all your effort, all your proof of work, in the waves of the Internet and mobile Internet, is like water poured off a lotus leaf, leaving not a trace. This is unfortunate, but it is the status quo.

Yet blockchain is trying to reverse this value chain, making the network layer and transport layer — rather than the application layer — important again: in this torrent, the value of network development (and systems development) is once again coming to the fore. Look: Bitcoin’s design reflects a profound understanding of networks, exquisite use of memory, and an extraordinary emphasis on data structures and fundamentals. Need one say more? Just the structure of the block header, that magic number 0xD9B4BEF9, is enough to evoke the scent of first love (0xdeadbeef, how the hell have you been?).

So blockchain may be the best comeback battle for netengs — whether or not you get on board isn’t important; get into the rabbit hole first. Building up some technical reserves is always good. Who knows — it might be like joining the Party in 1944.

(This digression is dedicated to all the netengs who have crossed paths with this programmer, and to those who haven’t.)