Improving the Bitcoin Development Process

The following is adapted from a talk I gave at the 2016 MIT Bitcoin Expo

It wouldn’t be an exaggeration to say I’ve had an involved history with Bitcoin — I started in 2011 or 2012, when I first became aware of this magic internet money called Bitcoin, but I didn’t really get sucked into the vortex until I developed Tidbit in late 2013, a little web mining platform with big ambitions to eliminate advertisements which was quickly subpoenaed by the State of New Jersey, and then when I doubled down on Bitcoin by launching the MIT Bitcoin Project with Dan Elitzer, which gave every MIT Undergraduate 100 dollars in Bitcoin. More recently, I served as program chair for the first Scaling Bitcoin in Montreal, and co-founded the MIT Digital Currency Initiative (DCI). While the DCI is not the focus of this post, in short:

The goal of the DCI is to take a longer term view on research and the future of cryptocurrency. It’s not here to serve as a governance structure for bitcoin or even necessarily weigh in on short-term disputes, though we do care about and support the community individually. Simply put, it’s a group of researchers, developers, and students whose passions align on Bitcoin and decentralized technology, and the DCI is our common ground. As Neha Narula, the DCI’s Technical Director, likes to say, asking the DCI to take a position on Blocksize is a bit like asking if the Massachusetts Institute of Technology is supporting Trump for president. There is certainly more ink to spill here, and we will be communicating what the DCI does more transparently very soon.

I’m sharing my “shortlist” not to brag, but to add context to my words. I’ve had a quite unique set of experiences in the community, as a developer, an undergrad, a master’s student, the target of state investigation, an open source community organizer, a MTGOX creditor, and throughout it all, as someone who has deeply cared about the mission and goals of Bitcoin.

Watching the last year of Bitcoin has been painful to say the least. There’s been so much acrimony among our “brothers and sisters in arms”. It has felt highly toxic to almost everyone I’ve spoken with, and as a result many Bitcoin vets don’t have the same excited glint in their eye as they used to. Who could blame them? Personally, and I’m outing myself as a bitcoin-hipster, I don’t think that Bitcoin has the same charming character that my inner-ideologue was attracted to today as it did 4 years ago.

This isn’t necessarily a bad thing. In the last 4 years, the Bitcoin community has matured significantly. It has been awesome to see some of the engineering efforts being rolled out, to name just a few libsecp256k1, Segregated Witness, Lightning Network, Zero Knowledge Contingent Payments, Invertible Bloom Lookup Tables, libbtcnet, and many others.

However, I know that we can do significantly better.

Let’s delve into a little economic theory. Most Bitcoiners are familiar with Hayek, as Bitcoin is often called by the moniker Hayek-Money, but many people don’t know the exact link between Hayek and Bitcoin. Hayek was a very influential economist, who painted a picture of free markets creating maximum wealth for society. Hayek thought that the promotion of open competition was a critical precursor for a free and wealthy society because centralized structures wrongfully assume they know how to efficiently allocate resources, rather than let efficient resource allocation evolve through competitive processes. Structures that promote open competition was viewed by Hayek as ideal. This is just a brief summary, I highly recommend reading The Fatal Conceit to start. Most people, in my opinion, wrongfully attribute Bitcoin’s economic magic to be due to its monetary fixed supply, which is free of central issuance control. However where I really see the meaning of the term Hayek Money is that cryptocurrencies offer a platform for competing monetary standards, and as a decentralized community maintenance structure which limits state actor coercion.

It is coercion resistant.

In Bitcoin, you’ve probably seen the major competition occurring over the quite contentious issue of block size with Core, XT, Classic, Unlimited, etc. While competition is generally good, this kind of competition has not been healthy.

The reason it hasn’t been particularly healthy is that there has been an overemphasis on winning. In Bitcoin, this is a problem because for consensus you need an inherent monopoly on what consensus critical software actually executes. Making execution of new ideas on the main network the goal of development efforts seems short sighted.

The meaning of the word compete is very nuanced. It comes from the Latin for “com”, meaning together, and “petere”, to seek. It is not about trying to best one another, but rather a noble pursuit to elevate the excellence of all involved.

We must not lose sight of this.

At Scaling Bitcoin Montreal, Matsuo-san gave what I thought was one of the most critical and enlightening talks. He discussed the processes that were behind the SHA3 competition, and how this open contest created an excellent environment for technical achievement. This was no happy accident, for a while I’d been thinking about the potential for a contest process in Bitcoin, and as program chair, I made sure to encourage Matsuo to attend and share what he had learned. At the interactive session following, there was some agreement that Bitcoin could also benefit greatly from some such process, but not agreement on what it would be.

There is a rich history of competitive processes used for technical progression aside from SHA3, which had its flaws. Joi Ito recently told me about the early history of the RoboCup Competition, originally held in Japan in 1997, which used very effective measures to encourage a tight innovation loop. Each year, after the competition, the winning teams had to share their technology with the other teams. The next year, the bar to entry was beating last year’s winner. The first year of the competition was somewhat sad to watch, but this structure quickly propelled the quality of the RoboCup games to great heights. You can find a great compilation of each year on Youtube, it’s really worth watching.

Scalability is a kind of funny thing for the Bitcoin community to be in such a frenzy over. There are so many ways that bitcoin is more or less broken compared to the ideals of the community that are a lot more involved than blocksize, and I’d even written about these problems in June of last year, as the block size debate was amidst rising to crescendo.

And so what I’m proposing is that we take a competitive structure and apply it to some of our hardest problems in Bitcoin, treating it not like a battle to win, but rather as a contest to have and to take glory in the act of competing. I’ll admit that there is a fair criticism that for many things in Bitcoin the decisions are almost deterministic, for instance there is really only one right way to safely bring something like libsecp256k1 into the picture. However, there are many things on the 2–5 year timeline for Bitcoin that are much more freeform or could involve more freeform innovations.

Allow me to paint a vision of what this could look like.

Privacy is a chief concern of many Bitcoin users, and there aren’t many concrete proposals and implementations which increase the privacy of Bitcoin without large tradeoffs.

Imagine a contest which asked the community to identify areas ripe for improvement and forward thinking strategies, to build prototypes demonstrating potential of new technology, and to refine said prototypes into deployable solutions.

Imagine teams of developers and academics working in concert on ambitious ideas, not afraid that their code might be seen politically, not overly concerned with soft forks or hard forks.

Imagine teams with sponsorships from the major Bitcoin companies, not because they are being told what to work on, but because our startups are lead by entrepreneurs who celebrate the technical diversity and brilliance of our ‘Bitcoin researchers’. Imagine a team at every university in the Blockchain Education Network.

Imagine that not just one team was declared winner, but that the top teams, selected for by various technical merits, shared a prize and had wide community recognition for their contributions. Without a single winner, teams would have the incentive to cooperate to learn how to fend off theoretical attacks from their competitors.

Imagine the core team of developers, businesses, and community of users were then able to evaluate the feasibility of deploying these changes on to the main net, and there was room to choose the best path without too much technical dig in.

Privacy is but one issue in Bitcoin, there are many targets for this type of competition, such as a script redesign, node plugin interface, formal verification techniques of consensus critical code, performance engineering, decentralization, and of course scalability.

I’m aware of the irony of centrally proposing we do a competitive process, so I’m bringing it to the community a bit premature intentionally. I’m not announcing a specific contest or format because I want to hear from you about what you think would work and what wouldn’t work. I am committed to making these contests happen, not just with my word, but also I have secured funds to guarantee this can happen. I’m not just taking a shot in the dark here, this is an idea that has been in progress for many months, has rich theoretical backing, and, having shared this idea with many in the community, there is already a great deal of enthusiasm for this direction.

So I hope one day, not too far from now, we’ll be able to say: Let the games begin.