Eric Lombrozo is a Bitcoin Core developer and CEO of Ciphrex, a software company developing tools and application development platforms for cryptographic transaction processing.

In this CoinDesk 2016 in Review special feature, Lombrozo recaps a fraught year in bitcoin's development history, one that he believes should serve as a reminder of how the community should come together and recognize its common goals.

When I first started working to develop bitcoin applications in 2011, I assumed it was a fairly stable protocol that would be unlikely to change in drastic ways – the rules were well-defined and the network was open to participation by anyone who adhered to these rules.

Despite noting plenty of ways the system's design could have been made better in hindsight, it was clear that getting everyone on the network to adopt changes to these rules would be a difficult task.

It was feasible to have multiple implementations as long as they all followed the same rules. But even relatively small differences in behavior could introduce systemic incompatibilities that would break the network.

In general, it would be much easier to just try creating a new network from scratch, and in fact, a number of people did just that.

I was involved in the early phases of two of such projects, Ripple and ethereum.

Extending or modifying decentralized consensus protocols turns out to be an extremely challenging problem.

As opposed to more conventional deployment models in the software industry, providing a migration path for users involves not just requiring backward compatibility with older protocols and data formats – it also requires ensuring that the economic incentive structures that provide the security as well as the eventual consistency of the entire network remain intact.

In particular, when dealing with a distributed financial ledger, it is important that everyone come to agree on its state, and that nobody be able to game it unfairly or violate existing contracts at any stage of an update. I think it's fair to say that the subtle challenges posed by these requirements tend to be often highly underestimated.

Bitcoin encountered its first major protocol upgrade challenge in 2015.

Prior to this, the bitcoin software had been undergoing frequent updates and releases. There had even been a few additions to the protocol itself. But up until 2015, none of these updates had deliberately involved any changes that could potentially severely disrupt incentives or fork the ledger.

There had been minor incidents such as the March 2013 fork that resulted from an undocumented behavior in the database engine. (This caused some nodes to reject a particular block that others had accepted).

But while this particular incident required manual intervention to resolve, the incentives were still sufficiently well-aligned to allow for a coordinated cooperative effort that restored the network's functionality quickly and without significant widespread losses.

2015 marked an important turning point.

It was the first time a change was proposed that predictably would alter incentives and would be certain to break compatibility in ways that would not only require extensive logistical coordination but would also lead to controversies that would make the kind of cooperation required for smooth transition extremely difficult.

To the untrained eye, it seemed to be like a very innocuous and simple change, one involving a single parameter that capped transaction blocks at a maximum size of 1 MB.

However, from the perspective of system engineers, what was being proposed was not just a technical change, it was a political powder keg.

In a more conventional network setting, especially one where a small number of players could control the execution environment (such as is the case with deployment of new servers within an organization), such a parameter change would seem like an almost trivial change.

Engineers would have to weigh the tradeoffs in terms of system behavior and costs. Processing bigger blocks would require bigger, more powerful hardware, but the extra costs can be calculated and the organization can decide whether the greater transaction throughput justifies these costs.

However, in a decentralized deployment setting, especially one where participation is voluntary, the entire network is held together by economic incentives in a tight balance, and all network participants must agree to the same rules governing how a financial ledger can be modified.

In this way, even such a seemingly trivial change can become a monumental task fraught with tremendous risks.

I had already been working on Bitcoin Core for a few years by this time, and I was already very familiar with many of the difficulties that arise in free, open-source software development. But for the first time, I felt the entire bitcoin network (with a market capitalization in the billions of US dollars) was potentially threatened by rising community tensions.

I, myself, had no particularly strong preferences for a given maximum block size. But I would have liked to see a good long-term solution emerge where block size could increase dynamically as better technology emerges.

This seems to be a common view among many bitcoin developers, but a good solution continues to elude us and will require more work.

What was clear was that attempts to just alter this parameter or remove it were highly controversial, and that the economic incentives keeping the network healthy were at risk.

The fact that it was controversial meant that without overwhelming stakeholder support that could keep the differing incentives in balance, coordinating a smooth transition would be nearly impossible – there was a very real risk of the network splitting in two or more fragments, all of which would be incompatible with one another.

I should point out that no one is to be faulted for this – it is the nature of a system that is designed to be immutable. And had it not been this particular issue, some other controversial issue would have arisen sooner or later.

The problems mentioned above had been discussed to considerable length in public discussions, which continued throughout 2015 and well into 2016. Perhaps what was most surreal was seeing the community splinter and fragment as inaccurate information flooded outwards.

Camps formed, largely based on events occurring on social forums and a few stories pushed by mainstream media that many engineers viewed as tangential to the essence of the problem. Perhaps ironically, the response to these ended up resembling quite closely the kinds of scenarios that some had anticipated might result from controversial protocol change proposals.

It became clear then that despite the issue having arisen due to a technical challenge – namely, how to scale transaction throughput while keeping fees low and the network decentralized – the biggest challenge bitcoin was facing at this time was not technical but political and social.

A campaign attempting to circumvent the technical review process had been unleashed, and the existing technical review process at the time was ill-equipped to handle this kind of scenario.

With this, 2016 was the year that the term "hard fork" entered the popular lexicon – it was the year the world would see the first highly publicized occurrence of a contentious hard fork on a consensus network with significant capitalization.

This occurred, of course, on the ethereum network after a major project – The DAO – was hacked, which caused the ethereum network to split into two different networks.

For those who are new to the term, a hard fork is any change to consensus rules in a decentralized consensus network that would cause nodes that adopt the changes to fork off to a separate network from nodes that do not adopt the changes.

If the changes in question are universally supported by all network participants, then the problem of deployment reduces to one of logistics. These sorts of logistical issues are still quite intricate and carry risks – but they can be tackled via technical means – and it is within the scope of engineering to find workable solutions.

However, if the changes are controversial, the problem ceases to be within the realm of engineering and becomes political.

Emphatically, bitcoin and proof-of-work blockchains generally do not offer solutions to the basic political problems that have plagued humanity since prehistoric times. Thousands of years of history have demonstrated that the resolution of political disputes is a very hard problem fraught with social unrest, and at times resulting in war and bloodshed.

What bitcoin offers is a form of money that is defined by algorithmic rules, enforced not by some external party but by the natural economic and social incentives of the participants within the system, in a decentralized manner.

Participation in networks like bitcoin is voluntary.

In the event of an incompatible ledger change that is controversial, unless the different parties are able to arrive at some resolution, either one party must coerce the others into adhering; or the parties must all go their separate ways.

Coercing people to change their software takes us outside the realm of computer code. Even if a reasonably fair democratic process existed and were to be used (and that's a huge if), it significantly degrades the voluntary nature of participation.

And if the parties go their separate ways, the network fragments, reducing its utility and destroying people’s confidence in the underlying financial assets.

For bitcoin to have value, we need a robust, global network that can withstand determined, well-funded attacks. It must retain its security and stability even in times of turmoil.

As we begin 2017, I encourage people to look to ways we can continue to build upon this technology while avoiding divisive scenarios that could threaten to destabilize or fragment the network.

Earth image via Shutterstock