Guy Corem
A lot of intriguing and conflicting things have been said about Bitcoin in the past few years. Some see it as the salvation of the financial system, others as a new toy, appealing only to the technologically savvy.
Say what you will, but so far, Bitcoin is a technological success. Minor glitches aside, the developer community that originally rallied to launch this project forward turned an immature, yet mind-opening computer protocol into a functioning monetary system, operated and used worldwide.
These developers’ personal investments have been enormous. It took incredible creativity and innovation to combine knowledge in software engineering and cryptography with a high political sense, game theory with international diplomacy and computer networking with coalition forming and mass persuasion.
All of these skills are required to lead Bitcoin’s core development. As the stakes go up and the authority of early involved developers gets stretched thin, the big question is, “Can the Bitcoin community create new tools to reduce the burden of politics?”
Bitcoin, a decentralized monetary system, aims to be the new money for the Internet arena, eliminating lack of trust and reducing risks to the monetary system that are brought on by human involvement and decision making.
But even Bitcoin is a machine that is programmed by mere humans. Under the hood, politics can still be divisive when developers disagree on important code changes.
To qualify for entering the debate, one needs to invest themselves heavily and create the proposed fix; this tends to filter out all but the most opinionated developers. The reward is, of course, proving the other side wrong, and saving the day for millions of users. Oh, and those Bitcoins in your pocket, too.
Making A Decision
So how can such integral decisions be made in this new challenging environment containing so many different players?
Until the end of 2010, Bitcoin had a single voice: “Satoshi Nakamoto,” its mysterious and unidentified creator. The Bitcoin Protocol was embodied in Nakamoto’s software. The community involved was small and Nakamoto’s vision was revered as near prophecy.
By the end of 2010, Nakamoto disappeared, leaving a large vacuum in leadership. Since then, the Bitcoin community has been left with flesh and blood developers whose legitimacy is tested with every decision they make.
The debate is exacerbated by the huge financial stakes for participants and by a trust-no-one mentality — ironically, the same mentality that brought forth the need for the Bitcoin system.
Unlike other software projects, a small tweak in code will affect the entire ecosystem. For example, the current crisis deals with fixing unforeseen effects of an early change that attempted to fix “spam” transactions by introducing limits to the number of transactions.
There are billions of dollars at stake, so who has the authority and immense responsibility to take risks in such a situation?
Learning From Other Software Projects
It has been proven over time that strong leadership does in fact help forge consensus. For example, Linus Torvalds, the inventor of Linux, has served as “benevolent dictator” for 24 years of continuous development.
The technological bets he took have propelled the once-hobbyist operating system into billions of smartphones and millions of servers. With a clear vision of scaling the project, Torvalds stepped in countless times, accepting or rejecting changes. As the original inventor, never bowing to political correctness, his authority was unchallenged.
If Torvalds didn’t like your code, tough luck. For years, Torvalds was, in a practical sense, the final guardian of Linux’s code. You could always create your own type of Linux (known as a fork) — a departure from the official Linux, which you would control — and include your code.
That would be considered a dramatic move, a competition to “mainstream Linux.” The tools to move code between the two versions were cumbersome, and code tended to diverge, forcing developers and users to make hard choices.
To handle the growing number of Linux types and the difficulty of managing them, Torvalds created Git, a decentralized repository of code, allowing people to interact and share code easily.
Bitcoin and Git have a main similarity, as they both deal with getting to a consensus: Bitcoin is the agreement on which transactions are considered valid; Git is about the agreement on what code changes should be included in the latest version, on top of which developers should work.
Git has changed the politics of code development. You no longer need to beg for a central authority like Torvalds to accept your code change.
With Git, it’s trivial to post your own version, and it’s trivial for Torvalds to pull it into his code, if he or his lieutenants find it worthy. Every code change is essentially a little fork, but merges became much easier. With changes moving around freely, developers compete on the merits and usefulness of their version.
What’s a useful version? How does a piece of code get merit? Those are still subjective questions that Git can’t solve. The authority behind an official version still underlines a struggle of power, but more voices can be heard, and forks are less dramatic.
By contrast, the consensus on the state of the Bitcoin ledger is mathematical, with rules on which Bitcoin participants agree. In practice, Bitcoin rules are set in the code of the official version.
Although the Bitcoin world is not quite where the Linux world is today, perhaps there is a lesson to be learned from Linux’s success versus reinventing the wheel.
Where Things Differ
The truth is, Bitcoin can’t afford a code fork. Subtle differences between implementations can lead to several competing versions of the Bitcoin ledger, the main database of all Bitcoin transactions.
Such a schizophrenic beast wouldn’t survive, as users would receive Bitcoins spent on one ledger and unspent on another. That’s why Bitcoin core developers, like neurosurgeons, won’t poke around unless absolutely necessary. They have this unwritten contract with the Bitcoin community: keep the fundamental rules of Bitcoin, keep the system running, keep it scaling and build up the system that could contend with traditional finance.
Where To Go From Here
There’s no doubt that testing needs to be done and changes have to be put in the system, but this has to be done responsibly. Some developers choose to create new coins and test their code there, in an environment separate from Bitcoin. These are commonly known as Alt-coins and do not enjoy the same popularity as Bitcoin.
Another possible solution is being promoted by the team at Blockstream. The VC-funded company pushes for experiments to happen within the Bitcoin currency, but not as part of the main system. This introduces flexibility, allowing the core developers to innovate without compromising the currency.
Opponents see it as a backdoor to coerce the Bitcoin protocol in a more government-friendly direction, taming the beast. Much like Git, these experiments, known as side-chains, separate the human consensus debate of what should be the authorized version from the underlying code-change mechanism.
Meanwhile, they keep the one consensus that seems to unite Bitcoiners: Keep Bitcoin alive and strong!
As the debates heat up, we’re reminded that consensus-building remains a difficult, human task. Previous attempts by the community have been extremely problematic, at best. VC-funded companies could play a larger role, but most would rather pretend that Bitcoin will be maintained by others.
Companies that step up to the job will have their work cut out for them, proving their value to the community while being deemed agenda-free.
Can we really create a human-free consensus? Nakamoto left us with an experiment. The current value of the experiment is US$4 billion, and the Bitcoin community is following closely to see how this turns out.
Bitcoin may not need a “benevolent dictator,” but as the system reaches new scales, it will need strong leadership, along with new development tools to experiment in bold directions.
Comment