Chapter 06

Evolution of the Bitcoin Protocol

A lot has been discussed about the actual contribution of Satoshi Nakamoto’s invention. As shown in the previous chapters, however, Bitcoin did not come out of nowhere. It was an inevitable step in the evolution of multiple subfields within computer science. Satoshi neatly combined multiple components like public key cryptography, elliptic curves, distributed computing and others into a powerful machine worth much more as a whole than the sum of its parts. P2P networks, consensus algorithms, proof-of-work, identity systems based on PKI, digital signatures — these were all proposed long before Bitcoin arrived. Nakamoto’s brilliant idea was to combine all these technologies into one distributed network where countless nodes that join and leave the network at will in an asynchronous manner utilize the computational heavy operations as a tool to reach consensus about the state of the ledger.

The Bitcoin machinery is orchestrated in a way that every single (full) node contains the same copy of the ledger. The ledger is being appended and synchronized across the network almost in real time. Anytime someone sends a transaction, the transaction data is propagated over the network in milliseconds, as nodes listen for transactions, collect them, and relay them to other peers with whom they are connected. The nodes fill up their locally produced blocks with as many transactions as possible until they compute the appropriate hash, the parameter given by the network. Whoever produces the hash first — which is an undeniable proof of computational work — and announces it to the network, wins the block reward.

The other nodes in the network express their acceptance of the winning block by including its hash into their blocks from which they compute the next hash. This way, the role of a bookkeeper rotates randomly in every round of block generation, with the odds of getting it proportional to the computational resources dedicated to the network. As long as the block generator follows some basic protocol rules with regards to transaction validity, size and some other parameters, the network will reach consensus. Which protocol rules to follow, however, is determined off the blockchain.

Arguably, while a good part of the codebase has been changed, some rules stay more or less the same because of the historical reasons. In August 2017, new bits of Nakamoto’s words emerged on the Internet. A Bitcointalk user named CipherionX published emails exchanged between Satoshi and Mike Hearn in 2010 and 2011. This makes for very alluring reading that contained a number of interesting facts that would have seemed curious in 2017. Unsurprisingly, some in the community were skeptical and called out the veracity of the emails in question, but Mike Hearn later confirmed personally that they are indeed authentic. In December 2010, he reached out to Satoshi with an eagerness to understand some of the design choices Satoshi made:

Happy Christmas Satoshi, assuming you celebrate it wherever you are in the world :-)

I have been working on a Java implementation of the simplified payment verification, with an eye to building a client that runs on Android phones. So I've been thinking a lot about storage requirements and the scalability of BitCoin, which led to some questions that the paper did not answer (maybe there could be a new version of the paper at some point, as I think aspects of it are now out of date).

Specifically, BitCoin has a variety of magic numbers and neither the code nor the paper explain where they came from. For example, the fact that inflation ceases when 21 million coins have been issued. This number must have been arrived at somehow, but I can't see how.

Another is the 10 minute block target. I understand this was chosen to allow transactions to propagate through the network. However, existing large P2P networks like BGP can propagate new data worldwide in <1 minute.

The final number I'm interested in is the 500kb limit on block sizes. According to Wikipedia, Visa alone processed 62 billion transactions in 2009. Dividing through we get an average of 2000 transactions per second, so peak rate is probably around double that at 4000 transactions/sec. With a ten minute block target, at peak a block might need to contain 2.4 million transactions, which just won't fit into 500kb. Is this 500kb a temporary limitation that will be slowly removed over time from the official client or something more fundamental?

Understandably, Hearn inquired about the system parameters that were included in the code but were missing explanations in the documentation or the white paper. Hearn pointed out the obvious comparison with the performance of Visa and that of Bitcoin. From the response he received, it seems that the mentioned analogy did not seem wrong to Satoshi:

Educated guess, and the maths work out to round numbers. I wanted something that would be not too low if it was very popular and not too high if it wasn’t.

If propagation is 1 minute, then 10 minutes was a good guess. Then nodes are only losing 10% of their work (1 minute/10 minutes). If the CPU time wasted by latency was a more significant share, there may be weaknesses I haven't thought of. An attacker would not be affected by latency, since he's chaining his own blocks, so he would have an advantage. The chain would temporarily fork more often due to latency.

A higher limit can be phased in once we have actual use closer to the limit and make sure it's working OK.

Eventually when we have client-only implementations, the block chain size won't matter much. Until then, while all users still have to download the entire block chain to start, it's nice if we can keep it down to a reasonable size.

With very high transaction volume, network nodes would consolidate and there would be more pooled mining and GPU farms, and users would run client-only. With dev work on optimising and parallelising, it can keep scaling up.

Whatever the current capacity of the software is, it automatically grows at the rate of Moore's Law, about 60% per year.”

In a different email, Satoshi also explained more in detail his rationale behind choosing 21 million coins as the final amount of bitcoins in circulation:

My choice for the number of coins and distribution schedule was an educated guess. It was a difficult choice, because once the network is going it's locked in and we're stuck with it. I wanted to pick something that would make prices similar to existing currencies, but without knowing the future, that's very hard. I ended up picking something in the middle. If Bitcoin remains a small niche, it'll be worth less per unit than existing currencies.

If you imagine it being used for some fraction of world commerce, then there's only going to be 21 million coins for the whole world, so it would be worth much more per unit. Values are 64-bit integers with 8 decimal places, so 1 coin is represented internally as 100000000. There's plenty of granularity if typical prices become small. For example, if 0.001 is worth 1 Euro, then it might be easier to change where the decimal point is displayed, so if you had 1 Bitcoin it's now displayed as 1000, and 0.001 is displayed as 1.

The deflationary model of Bitcoin’s monetary policy has been debated both inside and outside the Bitcoin community since its introduction. While the fans of hard money stand behind it, there are also community insiders who express concerns related to security considerations of the monetary cap. These voices have been translated into monetary regimes of alternative cryptocurrencies, as quite a few of them implement a long tail coin emission with a certain level of continuous inflation, the most notable example being Monero. From the current standpoint, it is unlikely that changes of any sort could be made into the Bitcoin monetary model.

Governance

Outsiders of the Bitcoin community often wonder how changes are implemented in the protocol in the absence of a central authority. As Bitcoin is completely decentralized and open-source, anyone can freely modify the code in whatever way they desire. Perhaps counterintuitive for many, this anarchical decision process has certain rules. While the term anarchy usually connotes the absence of order, in various schools of thinking in economics or political science, the term merely implies the absence of governmental authority, which does not necessarily translate into disorder and chaos. On the contrary, the spontaneous order that emerges within the peer-to-peer interaction may allow for greater flexibility and resilience of the system overall. Many of the open-source projects of today, including Bitcoin and other cryptocurrencies, build their governance system upon the Request for Comments (RFC) format that was utilized and evolved from the researcher community around ARPANET in the 1970s.

In crypto jargon, the protocol governance in Bitcoin happens off-chain. This is sometimes criticized for being too centralized, and is something that many of the smart contract platforms are trying to improve. We’ll discuss these efforts further in the next few chapters. It is arguable, though, whether other governance alternatives provide some viable long-term alternatives to Bitcoin. Nonetheless, over the past years, hundreds of people contributed their code to Bitcoin even though only a handful of them had access to the code of the Bitcoin Core client. This right was initially transferred from Satoshi to Gavin Andresen, who shared access with other active members of the community, including Wladimir van der Laan, Pieter Wuille, Gregory Maxwell, and Jeff Garzik. Hence, the Bitcoin Core developer label was born. The torch has been passed from person to person, and by 2021 only the first name from the above-mentioned quarteto still has access. The lead maintainer Wladimir van der Laan, paid by MIT’s Digital Currency Initiative, was joined by Marco Falke, Jonas Schnelli, Samuel Dobson, and most recently Michael Ford.

Despite the fact that the repo maintainers are sometimes viewed as the project leaders, it is a claim that does not necessarily bear fruit. In fact, they have quite limited power. Even though it would be technically possible for them to hijack the repository, it is likely that such an attack would result in simply shifting development efforts under different repositories. After all, that is exactly what has already happened many times in the crypto space, not just the Bitcoin protocol.

At the beginning of every change that gets into the code base, there is a Bitcoin Improvement Proposal (BIP). Anyone is free to submit proposals for protocol upgrades in the form of a BIP. Upon any BIP submission, a public discussion takes place. The proposal is discussed via Internet Relay Chat (IRC) as well as the mailing list of Bitcoin developers. If the change is considered to be reasonable and is accepted by the developer community, it is ultimately added to a Git repository.

The first-ever Bitcoin Improvement Proposal was submitted in August of 2011 by Amir Taaki. It was codenamed BIP 0001 and it defined what BIP is and what it should contain. It was further expanded on by Luke Dash Jr. in BIP 0002. The entire BIP process is derived from Python Enhancement Proposals, and in general distinguishes between three kinds of BIPs: Standard Track BIPs, Informational BIPs, and Process BIPs. Standard Track BIPs propose changes in the codebase and affect the network protocol as well as applications built around it. The second category are Informational BIPs that focus on description of certain design issues of the protocol and do not directly propose any particular changes. The last broad category are Process BIPs. They also do not propose changes of the code base itself, but instead aim to improve processes around decision-making in development.

Ironically, Taaki who worked on the BIP review system to establish some standards when it comes to the code changes and their public review, said in an article for Bitcoin Magazin in March 2020 that he perceives the system as “a hindrance on development in Bitcoin that favors the status quo over technological progress”. He elaborated on how his attempts to commit code into Bitcoin Core were blocked by its maintainer Gavin Andressen, who was turned off by Taaki’s militant rhetoric when speaking at Bitcoin conferences.

Some of the more famous BIPs that introduced important changes included BIP39, which included mnemonic codes also known as seeds that allowed for easier creation of wallet backups in the form of easy-to-remember words. This BIP was preceded by BIP 31, which introduced deterministic wallets that eliminated the need to back up the wallet every time one generated a new address. Both of them increased the convenience of working with the wallet for users.

In general, protocol changes are often evaluated in the context of backwards compatibility. As coordination of such a massive network as Bitcoin is quite challenging, it may easily happen that any given protocol modification is disagreed upon, and thus not accepted, by some part of the community. The protocol changes that do not necessarily require a whole network upgrade are implemented through a soft fork. This means that even though it is, naturally, desired for the change to be widely accepted by the whole network, nodes that do not upgrade to the newer version of the protocol will still be able to communicate with the nodes that do upgrade. Hence, we talk about the change being backwards compatible.

In some cases, proposed changes modify the protocol rules in such a way that the upgraded nodes effectively create a new network, in parallel with the nodes that do not accept the proposed modifications. Such changes require a so-called hard fork, and are not backward compatible. As the history (of anything) suggests, governance is never easy. The level of difficulty is amplified in distributed systems, and even more so in those that are related to such a serious issue as money. Ultimately, the consensus over the protocol changes in Bitcoin are dynamically formed via balancing the needs and views of core developers, miners, users, and business entities, which sometimes may or may not play out with drama.

The Community Consensus

Since the beginning of Bitcoin, the miner’s reward to a large extent has consisted primarily from the block reward, and transaction fees were more of a bonus as they make up roughly around 10% from the whole reward. This ratio is likely to change in the upcoming years. As increasingly fewer bitcoins will be released into circulation per every block mined, the miners will need to be (monetarily) incentivized via other means. Therefore, it is reasonable to assume that transaction fees will be where the miners will point their ASICs.

The most fundamental question that remains to be answered is whether there will be many transactions in the (bigger) blocks with relatively small fees, or on the other hand, fewer transactions with fees of a considerable amount. The transaction fee size essentially determines the utility of the protocol. But higher fees may deter various use-cases. While for intercontinental transfers it may be just fine to pay a few dozen cents or even a dollar per transaction, for retail payments this is very costly. The Bitcoin community has, for many years, been looking to answer this question. Unfortunately, the topic has become extremely contentious and emotional.

Satoshi inserted the 1 MB limit into the code in 2010 when he realized that some miners could eventually produce larger blocks than other miners were willing to accept. This would cause the chain to split, and thus problems to manifest. Unlimited block size would also make Bitcoin vulnerable to DOS attacks, so there was every reason to implement a cap.

We can phase in a change later if we get closer to needing it.

It can be phased in, like:

if (blocknumber > 115000)

maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

As Theymos, an admin of the r/bitcoin subreddit pointed out, Satoshi rarely explained his motivations for particular design features. It is likely that Nakamoto never expected this line of code to cause such a drama. Some Bitcointalk users expressed their concerns early in 2010. While some saw it as more of a marketing ploy, as it's tougher to get people to buy into a system if the network is technically incapable of supporting high transaction rates, others did foresee the difficulty of a whole-network block-size upgrade once the Bitcoin economy and ecosystem would scale and grow. History suggests that Satoshi’s judgement was not infallible and should be taken with a grain of salt. Bitcoin, and other cryptocurrencies for that matter, make up a giant technological as well as socio-economic phenomenon that is difficult to fully comprehend, even by its creators. Satoshi underestimated how hard it would be to increase bitcoin blocks once it is really needed.

One of the first notable hard forks that aimed to solve this issue was Bitcoin XT launched in 2014 by Mike Hearn, one of the core developers. While this included new features, the main proposed change was to increase the block size from 1 MB to 8 MB. This would result in increasing the amount of transactions per second from a theoretical maximum of 7 to 24. Despite initial success with more than 1000 nodes running the software, it fell out of favor in just a few months following a significant drop in user interest.

The idea of increasing the block size reappeared a few months later, this time in a more conservative version that would increase blocks to only 2 MB. It went by the name Bitcoin Classic. Similar to the previous case, initial response from the community was favorable, and this version of Bitcoin ran on thousands machines for several months during 2016. But not for long. The community soon evaporated as well.

The next attempted upgrade was Bitcoin Unlimited, which followed the suit of an alternative version of the Bitcoin software, and came with an even more controversial proposal. The proposal let the miners decide on the size of blocks they wanted to accept, and set the cap on 16 MB. Given the community’s sensitivity towards too much data in the blocks, it is no wonder that the proposal failed to gain traction.

Eventually, the effective increase in the block capacity came with BIP 141, also known as Segregated Witness, or SegWit. It was first presented in late 2015 by Peter Wuille, and it bundled together a host of different improvements. It segregated digital signatures from the transaction data, and moved it to a new structure at the end of the transaction. This allowed for larger blocks in a way that did not cause a hard fork nor a rejection of the blocks from nodes that did not upgrade to SegWit. It further fixed so-called transaction malleability, which potentially allowed for changing transaction IDs for yet unconfirmed transactions. SegWit was also the last prerequisite for the safe deployment of the Lightning Network.

Yet, its implementation became defined as one of the most heated discussions during the block-size debates. SegWit’s activation was blocked by miners for almost a year despite it being the centerpiece of Bitcoin Core’s roadmap. This gridlock resulted into something that forever changed the narrative and perception of the power possessed by miners: user activated soft fork (UASF).

For this reason, August 1, 2017 was one of the most expected and most closely watched days in the history of Bitcoin. UASF BIP 148 was proposed essentially as a method to reduce SegWit activation requirements, and it was not clear how the whole situation would play out. The lack of support from the miners — the very same actors who had blocked the proposal for months — would have caused a serious chain split. Days before the UASF, this was not an unlikely scenario, and the general advice disposed to anyone using bitcoins was to not use it during the first few hours, possibly days, after the event. To make it even more complicated, there were multiple scenarios in play that could have caused quite dramatic situations. Fortunately for the users, the hashrate swings did not result in the most dramatic ones, and instead followed the economic majority: wallets and exchanges. Some saw this as a capitulation of miners, and memes even called it "Independence day". Yet, the chain split occurred and August 1st gave birth to what has been dubbed Bitcoin Cash.

Bitcoin Cash development efforts were led mostly by Jihan Wu of Bitmain and Roger Ver, the CEO of Bitcoin.com, known as Bitcoin Jesus due to his activism and promotion of Bitcoin. Bitcoin Cash shares many similar characteristics with Bitcoin, including the entire transaction history within the first 478,558 blocks that led up to August 1, 2017. From block number 478,559, the two effectively had become different currencies with different ledgers, networks, and protocol parameters. The major difference lies in the block size, as Bitcoin Cash boosted the size limit to 8 MB. This limit was later even tripled to 32 MB, even though the actual blocks rarely contain more than 2 megabytes of data. Furthermore, Bitcoin Cash did not adopt SegWit, the prerequisite for Lightning Network, as its community leaders opposed the off-chain scaling idea. Despite larger blocks, Bitcoin Cash has been operating since its inception with merely a fraction of transactions and hashrate of Bitcoin.

In the months following the Bitcoin Cash hard fork, several other implementations emerged that forked the Bitcoin code base. Perhaps the most notable was Bitcoin Gold, which tweaked the hashing algorithm in a way that allowed for mining with graphic processor units. This was happening in parallel to the awaited fork of SegWit2x that would enlarge the block size limit to 2 MB on the Bitcoin blockchain. This protocol change was not eventually implemented as the community, developers, and the companies behind these ideas, backed out.

Roughly a year after the forking event, proponents of the big blocks started to fight among themselves, leading to creation of Bitcoin SV (Bitcoin Satoshi’s Vision). The efforts were led by the notoriously controversial persona Craig Wright and billionaire Calvin Ayre, who proposed increasing the block size limit even higher to 128 MB. In spite of many controversies with both Bitcoin alternative versions, they remain in the list of the Top-10 cryptocurrencies in terms of market capitalization. Needless to say, each of them call themselves the “true” Bitcoin.

While the block size debate was the most publicized and arguably the most crucial conflict within the Bitcoin community, it was not the only one. A similar beef occured years prior in an engineering battle over the Pay-to-Script-Hash (P2SH) proposal. Initially, Bitcoin transactions used the Pay-to-Public-Key (P2PK) format in which coins were sent directly to the public key of the receiver. This is suboptimal, as it wastes the precious block space and identifies the receiving party. As mitigation, another format was introduced, called Pay-to-Public-Key-Hash (P2PKH). This represented a subtle improvement as the address was created by hashing the public key.

P2SH was proposed as a more sophisticated version of the Bitcoin address created by a script hash. This allowed a simple sending to scripts that involved complicated multisigs. It was more private, data-savvy, and convenient. Because it was quite early in Bitcoin's history in a much smaller community, this dispute has not generally been publicized beyond the early bitcoiners. This proposal was led by Gavin Andresen, who at the time effectively served as the lead developer after Satoshi's disappearance. That said, an opposition formed in the form of a slightly different implementation called CheckHashVerify (CHV), coded by Luke Dashjr. All of them introduced new op-codes, and differed in trade-offs but essentially could have been implemented as a soft-fork. Disagreement on them fueled disputes over many months, and ignited many philosophical contemplations over the power of miners and “voting” by hashrate. We would see these proposals become resurrected in the block-size debate a few years later. Eventually, P2SH was enacted in April 2012.Another milestone in the evolution of bitcoin addresses came with Segwit in 2017, which introduced the Bech32 format. This format allows users to benefit from the capabilities of Segwit, and thus saves space in Bitcoin blocks.

Despite a rather complicated process of governance, Bitcoin as a protocol has evolved tremendously over the past years. Initially you could even send bitcoins to someone using their IP address, as Satoshi stated in his announcement of the first release:

There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They'll receive the transaction the next time they connect and get the block it's in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections.

This feature, however, allowed any “man-in-the-middle” to intercept transactions and pretend that they were the actual recipient. As such, these transactions were deemed insecure, and thus it was removed as a “dead feature” in version 0.8.0. Sending transactions over an IP address is one of the rare instances of features that lead nowhere and were eventually removed. The vast majority of design features included by Satoshi were very thought through, and were expanded by the wider community of developers over the course of the following years.

Dan Kaminsky, a leading security researcher famous for discovering a fundamental flaw in the DNS (Domain Name System) protocol in 2008, had long found his hobby in penetration testing. It was no wonder that a project like Bitcoin would attract his attention. In a 2011 interview for magazine New Yorker, he described his assessment of the quality of the Bitcoin code after his attempts to break it:

When I first looked at the code, I was sure I was going to be able to break it. The way the whole thing was formatted was insane. Only the most paranoid, painstaking coder in the world could avoid making mistakes.

I came up with beautiful bugs, but every time I went after the code there was a line that addressed the problem.

He’s a world-class programmer, with a deep understanding of the C++ programming language. He understands economics, cryptography, and peer-to-peer networking. Either there’s a team of people who worked on this, or this guy is a genius.

Bugs and Flaws

Brilliance does not necessarily exclude flaws and bugs. This is true for Bitcoin, even though its code is open-sourced and has been reviewed by thousands of eyes. Of course, most of them have been eliminated over the years but one never knows. When Satoshi released Bitcoin, its programming language — Script — contained several serious bugs. It has been speculated that, given its incompleteness upon the release, Script was something of an afterthought. These bugs, along with Satoshi’s willingness to disable quite a big part of its functionality, suggest that he was in a rush to finish the job, and did not test it extensively.

August 2010 brought perhaps the first instance of a critical bug in the Bitcoin source code, now referred to as the value overflow incident. At that time, it was discovered that block 74638 contained a strange transaction that created something over 184 billion bitcoins. The core developers responded promptly and a patched new software version that was issued within five hours after its discovery.Nevertheless, the bug caused a fork in the main chain. Even though some unpatched nodes kept building on top of the “strange” block, the correct blockchain overtook it within the next few blocks. As we’re mentioned previously, Bitcoin developers have been known for being cautious about what is accepted into the source code. While this later caused many disputes within the community, it proved to be the right approach, as any other critical bug could have caused serious consequences for the entire ecosystem that could be easily reflected in the off-chain world. Extra coins could be easily deposited to an exchange, traded for different cryptocurrencies, and withdrawn soon after. This could be technically repeated with a few other exchanges and cryptocurrencies in a matter of hours. The ramifications could have been vast.

As history suggests, when it comes to software development, no amount of prudence and caution is ever enough. Despite Bitcoin being a cryptocurrency with the largest ecosystem and highest level of scrutiny reviewing its source code, bugs do still occur. Not to mention its Non-Turing-complete modest scripting system with no loops. One can estimate how less secure cryptocurrencies must be with Turing-complete virtual machines and much fewer developers auditing their code. Yet, with all the prudence and security measures in place, even Bitcoin is not immune from critical bugs. The release of the 0.8 version of Bitcoin Core in March 2013 resulted in another fork of the main chain that operated for a couple of hours. Pieter Wuille of Bitcoin Core posted on the matter:

If this is a widespread problem, it is an emergency. We risk having (several) forked chains with smaller blocks, which are accepted by 0.7 nodes. Can people contact pool operators to see which fork they are on? Blockexplorer and blockchain.info seem to be stuck as well.

Again the bug was fixed and resolved very quickly. Fortunately, the following years of Bitcoin were not marked by any major bug in the software. That was, however, until September of 2018, when another inflation bug was discovered and shook the Bitcoin world. The bug was present in the software versions 0.15-0.16.2 and was named CVE-2018–17144. This risk associated with the bug was related to the potential double spend of the same UTXO multiple times in one transaction. Its exploitation required sufficient mining equipment and electricity, and could not be completed by regular users. It also made the network vulnerable to a DoS attack, even though the incentives for an adversary to do so were quite low. The inflation risk was of a higher severity, though, as it allowed some nodes to accept invalid blocks that inflated the supply. This would likely cause a fork. Even though the fork would likely soon be detected, the situation could be very chaotic as different software versions present in the network would react differently. The perceived degree of severity of this bug differs. The bug was disclosed by a developer who was behind Bitcoin Cash and Bitcoin Unlimited, so motives to describe the risk posed by the bug more dramatically should be taken into account. One of the Bitcoin core contributors, Jimmy Song, analyzed the bug very thoroughly in his blog post and noted:

Because of these irregularities, people on the network would soon have tracked this down, probably have alerted some developers and the core developers would have fixed it. If there was a fork, the social consensus at that point about which is the right chain would start getting discussed and the chain creating unexpected inflation would have likely lost out. If there was a stall, there likely would have been a voluntary rollback to punish the attacker.

In his analysis, Song brought up a point that has been often overlooked by many in the space: social consensus. Contrary to the popular belief that cryptocurrencies are completely trustless as they are all about zeros and ones, the reality is far more nuanced. The aspect of social consensus is often neglected. Throughout Bitcoin’s history, there were many attempts to introduce various changes into the codebase. This is especially relevant when it comes to the scaling debate. In response, we did see multiple modifications of the Bitcoin software that came with different solutions.Arguably, the authors of the code, and the way they advocated for the changes, often had larger effects on the receptiveness of the community than the code itself. If we had three different proposals to modify the Bitcoin codebase from anonymous authors, they are much more likely to be evaluated unbiasedly, or even evaluated at all, than if the proposals made were from people like Matt Corallo, Roger Ver, and Craig Wright. Any of these names would trigger different emotional responses in different tribes. This would be likely reflected in evaluation of their proposals.

Of course, the same patterns are present in different cryptocurrency communities. The infamous hack of The DAO in 2016 was perhaps one of the greatest manifestations of this phenomenon. Few things make one reevaluate their moral principles more than a bug in the code in charge of “costly bits”. In this case, the bug allowed the hacker to drain millions of dollars worth of ether out of The DAO. "The code is the law" was the narrative in the Ethereum community, but the aftermath of the hack revealed that this might not be necessarily so, given enough social pressure. The hard fork reversing the transaction was proposed very shortly. The money affected by the hack belonged to the early adopters and the most enthusiastic ones from the community. People around the Ethereum core team were likely also invested in it. This undoubtedly created a certain level of social pressure. There were, of course, more fundamental arguments for a rollback, such as that the amount of ethers stolen was relatively too high compared to the circulating supply as it accounted for roughly 11% of all ethers that existed at the time. Indeed, this could cause problems, given the network had been planning transformation to Proof-of-Stake consensus mechanism. In such a precarious and tricky situation, it is no surprise that resolution to the dilemma is sought by the stalwart leader of the community — in this case Vitalik Buterin. Regardless of the controversy, the point here is that the state of Ethereum’s blockchain was determined by social consensus, not Proof-of-Work. In other alternative cryptocurrencies, this is even more frequent and likely.

Interestingly enough, in May 2019, according to another Bitcoin Core developer nicknamed "Luke Dashjr", there were still more than 50% of all Bitcoin full nodes that did not update their software and thus remained vulnerable to CVE-2018–17144. It is worth noting that his numbers, especially when it comes to overall Bitcoin full node count, might not add up with most of the data resources on this issue. While most of the analytics platforms reported the total number of nodes in the network to be around 10,000, his website states it is closer to 100,000 nodes. When asked by the media outlets, he explained that unlike most of the other resources, he takes into account full nodes that don’t "listen" for new connections, and don’t have easily discoverable open port connections.Nonetheless, it was surprising to see half of the network being vulnerable to such a severe bug merely waiting for exploitation. Even though miners and economically rational agents might not have incentives to do so, some big players with enough money to burn might.

Building Layers on top of Bitcoin

That Bitcoin could serve as an underlying protocol that provides settlement for many other protocols and applications on top of it was clear to many early adopters. Even Satoshi began work on a marketplace application, as he explained to Hearn when he inquired about an unfinished part of the protocol that dealt with setting up publisher/subscriber channels for distributed routing via the network:

I was trying to implement an eBay style marketplace built in to the client. Publish/subscribe would be used for broadcasting product offers and ratings/reviews. Your reviews would be weighted by the blocks you've generated. I rightly abandoned it in favour of JSON-RPC, so other authors could implement it externally. The publish/subscribe "meet in the middle" mechanism was an interesting concept, but nothing remains that uses it.

It was part of writing code to explore the most technically demanding use cases and make sure Bitcoin could support everything that might be needed in the future, given the locked-in nature of the rules once the block chain started.

Mastercoin

Nakamoto did not finish that part of the protocol features, and it took a while for other developers around Bitcoin to begin building layers on top of it in order to realize innovations allowed by Bitcoin’s modularity. Analogous to the evolution of the Internet protocols focused on specific functions, Bitcoin has been evolving its own protocol suite. This started in July 2013, when a software developer J.R. Willett posted on Bitcointalk:

I am VERY excited to announce that I now have a complete specification for building a protocol layer on top of bitcoin (like how HTTP runs on top of TCP/IP).

The coins of the new layer have:

- Additional security features to make your money much harder to steal

- Built-in support for a distributed currency exchange

- Built-in support for distributed betting (no need to trust a website to coordinate bets)

- Built-in support for "smart property" which can be used to create and transfer property such as titles, deeds, or stock in a company

- Capability to hold a stable user-defined value, such as an ounce of gold or U.S. Dollar, with no need to trust a person promising to back up that value

This is a significant improvement over anything we've had before, including colored coins. This protocol has been my life's work for over two years now, and you can finally get a piece of it today!

He was about to initiate what would later spark a tremendous amount of hype and a small crowdfunding revolution: an ICO for Mastercoin. He wasn’t a stranger to Bitcoin and its community. To the contrary, he was an avid advocate who released a document with an ambitious name “The Second Bitcoin White Paper” in January 2012. Willett even launched a mining scheme where he paid random people from Craigslist to run his mining software. Even a year and half after the paper release, no one even tried to pursue the idea of what he called “initial distribution”. Eventually, he decided to do it on his own.

The original vision was to take Bitcoin and build on top of it. People who I know who do computer science would recognize the analogy of building protocols on top of each other. For instance, we have ethernet, is a pretty low-level communication protocol and on top of that we run TCP/IP and on top of that, we run HTTP.

And you know, these protocols stack on top of each other, each one relies on the one underneath for a certain level of functionality and each layer adds functionality to the function, to what's underneath. And on top of HTTP then we have various JavaScript rest APIs, and it just continues to stack up more and more abstraction from the various layers.

The idea then with MasterCoin was to create a new layer on top of Bitcoin. That would take advantage of all the hashing power and solving the computer science problem of which transaction happened first, which is really the main thing that Bitcoin solved. I call it the, and other people call it other things, but I call it the 'what-happened-first' problem.

Over the years, MasterCoin rebranded to Omni, and became the platform of choice for many projects from the crypto space aiming to issue assets. Most notably, it was used for issuance of Tether, a stablecoin pegged to USD, and the team behind Maidsafe that issued their proxy tokens on Omni. From a long-term perspective, this was not the best strategic move for the teams, though, as over time Ethereum took over this role and dominated the market. Tether migrated to other chains, and while Maidsafe stayed. This, arguably, contributed to their token being delisted on some exchanges, and thus resulted in lower liquidity of the token.

Counterparty Protocol

Another attempt with a similar goal was the Counterparty protocol which launched in early 2014. It also allowed the issuance of assets on top of Bitcoin. Even though the protocol has its own internal currency (XCP), issuing assets requires only regular bitcoin transactions. The XCP token was distributed in a unique way using the Proof-of-Burn approach, where minting of the new tokens is conditioned by “burning” bitcoins. The burning process simply means sending bitcoins to an address from which they are provably unspendable, and thus out of circulation forever.Over the years, there were a few dozen projects that took advantage of this protocol. Among them were Storj, Swarm and one of the earliest digital art projects — Tatiana Coin — issued by songwriter Tatiana Moroz. After the launch, XCP was able to maintain a relatively high valuation as one of the top 10 cryptocurrencies. Its development has been relatively slower and the price gradually fell and by the early 2021, it was not even counted in the top 1000 coins.

Colored Coins

Colored Coins were another of the client-side validated protocols that emerged fairly early. It, too, aimed to create a method of representing and managing real world assets within the Bitcoin infrastructure without having to create tokens. As with other protocols of this kind, Colored Coin transactions were embedded into the Bitcoin blockchain, and miners did not audit them for validity. Their transactions were crawled for on the blockchain by the client who checked the validity. The protocol, though, did not reach widespread usage as Ethereum eventually dominated the market share.

Factom

Factom was another protocol launched in 2014 aimed at building an additional layer atop Bitcoin. Its primary goal was to tackle weaknesses the team saw in Bitcoin. These included long transaction confirmation times, possible fluctuations in transaction fees, and low transaction throughput. The protocol uses its own currency, called Factoid, with which users can pay for data entries assembled on the Factom servers, after which time they are anchored into the Bitcoin blockchain. In April 2020, news broke that Factom faced liquidation issues as investors refused to provide the company with additional funding.

Lightning Network

Perhaps the most popular “Layer 2” solution built on the Bitcoin protocol is Lightning Network. It was proposed in 2015 by Joseph Poon and Thaddeus Dryja. In their paper, they outlined the design principles of the network consisting of, possibly, countless payment channels created off the main Bitcoin blockchain that would support micropayments and could boost the mythical TPS parameter of Bitcoin to thousands. In simpler words, the Lightning Network allows users to create off-chain bidirectional payment channels with a peer. Opening and closing the channel both require one on-chain transaction. Once the channel is open, the parties can transact thousands of transactions per second with very low fees (even smaller than 1 satoshi). These transactions are not broadcast on the Bitcoin blockchain. Once any of the parties close the channel, only the final balance of all the transactions is published on-chain. Moreover, party A can transact with party C as long as both of them have a channel open with party B. The routing capabilities of Lightning are being improved as these lines are being written. Overall, the Lightning Network improves Bitcoin transactions significantly as it makes them cheaper, faster, and more private.

As Aaron van Wirdum from Bitcoin Magazine noted in one of his many articles covering Bitcoin and Lightning Network, the idea of payment channels can be traced back to Satoshi himself. He included a draft of the code that let the users update their transactions before they were confirmed in Bitcoin 0.1.Satoshi’s idea was improved and elaborated on by multiple members of the Bitcoin developer community, including Mike Hearn, Matt Corallo, Alex Akselrod, Corné Plooy, Peter Todd, Gavin Andresen, and others. While some of these improvements led to different concepts with different sets of trade-offs, such as Amiko Pay, Strawpay, and Duplex Micropayment Channels, others eventually ended up in what we today know as the Lightning Network. One of the main reasons why Lightning won out over all the other payment channels was that it introduced a way to organize a payment channel network in a trustless manner. Furthermore, compared to all the others, it required fewer modifications of the Bitcoin protocol, and seemed to deliver a more user-friendly experience.

Like preceding payment channel designs, Lightning channels also rely on partially signed but non-broadcast transactions. Unlike them, however, the Lightning channel design involved an additional exchange of secret numbers that allowed for bidirectional update of the channels. In addition, the concept leveraged something called Hashed Timelock Contracts (HTLCs), a technique proposed initially for trustless cross-blockchain transactions.

The idea of Lightning Network has been so far translated into multiple mutually compatible implementations. The first one, written in the C programming language, was begun by Blockstream and goes by the name c-lightning. The second implementation was developed by a Paris-based startup called ACINQ in the Scala programming language, named eclair. The third implementation, named LND and developed in Golang, came from Lightning Labs, the company initially made up of the Lightning Network authors, Poon and Dryja. Dryja later left the company, but continued to work on Lightning in a software version he named lit. Bitfury, one of the leading companies in the Bitcoin ecosystem, also began working on an implementation but this initiative has since stalled. The same fate was also met by an implementation named thunder, which was developed by Blockchain, one of the major wallet providers.

Nevertheless, the first three major implementations remain actively developed by the respective companies, which make efforts to keep them interoperable. This has resulted in a common protocol specification known as Basis of Lightning Technology, often dubbed as "BOLTs".

While secure implementation of Lightning did not require major changes in Bitcoin, there were a few required. The most notable was related to transaction malleability we mentioned earlier in regards to the SegWit fork. Another change implemented into the Bitcoin Core even earlier was connected to so-called relative time-locks, which required users to close their channels periodically, as opposed to the previous state where they could leave the channels open indefinitely.

The first Lightning implementation was released in alpha even before the SegWit fork was activated in January 2017. By that time, it had been tested on the fourth SegWit-specific testnet dubbed “SegNet 4” for a couple of months. This milestone ignited the development of apps on all of the Lightning implementations that came to be nicknamed as "Lapps".The alpha phase virtually concluded, coincidentally, with the purchase of pizza by the same Bitcoin Pizza guy — Laszlo Hanyecz — in February 2018, almost eight years after he executed what has been recognized as the first commercial Bitcoin transaction. This time, even though he was not the first one to do it on Lightning, he was close. It is not exactly clear which transaction was the first commercial one, but according to some sources it could be the one done by Alex Bosworth, who paid his phone bill via Lightning using the services of the payment processor Bitrefill in December 2017. Until the summer of 2018, all three implementations moved into beta, which caused a significant spike in the number of opened channels.

Lightning experienced stable growth throughout 2019 and 2020 in all important respects: the network nodes, channels, and capacity. While the network density grew above 5,000 nodes, the number of channels oscillated between 30,000 and 40,000. The network capacity has reached and fluctuated at 1000 bitcoins as far as the public data is concerned. What the Lightning explorers fail to capture, though, is the private part of the network. As presented by Christian Decker during The Lightning Conference in Berlin in October 2019, this could consist of up to 40% of the whole Lightning Network. In this regard, the picture of what we will see will be distorted even more in the future as adoption of Schnorr signatures will make channel-opening transactions indistinguishable from regular transactions.

The Lightning ecosystem has also been expanding steadily with the increasing number of wallets, the most prominent ones being Zap, Eclair, Casa, Joule, Breez, and others. Much effort has gone into making Lightning easy to accept by merchants through e-commerce integrations such as BTCPAY, Lightning Charge, Strike, and OpenNode. This also resulted in dozens of new Lapps that popped up, many of them fun and experimental. Satoshi’s Place was one such Lapp that gained easy traction within the community as it allowed users to pay a few satoshis for every pixel they drew on a digital wall.

Anyone interested in diving in and exploring all the technical aspects of Lightning Network is encouraged to read Mastering the Lightning Network by Antonopoulos, Osontokun and Pickhardt.

RSK

RSK evolved from QixCoin and Ethereum. The former was the first Turing-complete cryptocurrency created in 2013 by several founders of RSK. The main contributors to its source code were the team behind IOV Labs. The key persons have been Sergio Demian Lerner and Diego Gutiérrez Zaldívar. RSK introduced innovative concepts that have extended Bitcoin’s functionality. It created a two-way peg sidechain with “Smart Bitcoins'' that are pegged to the value of Bitcoin. It is a two-way peg as users can move bitcoins between the Bitcoin blockchain and RSK sidechain. That is unlike the Counterparty protocol, where they could move it in only one direction.

The sidechain’s RSK Virtual Machine (RVM) copies Ethereum Virtual Machine (EVM) and supports smart contracts on top of Bitcoin. More interestingly, the sidechain is secured by merge mining, which allows miners to submit their proof-of-work hashes not only to the Bitcoin network, but to RSK as well. Therefore, they can get rewarded twice for the same work.

Shortly after launch, RSK was secured by almost half of Bitcoin’s hashrate. By early 2020, this number dropped to just above 30%. While RSK has received a mostly positive reception, not everyone approves of the merge mining model. Some critics believe it undermines Bitcoin's security model. In our interview, Bitcoin Core’s Peter Todd explained:

But the way it stands right now, the projects that are trying to do this are effectively an attack on the system. It’s just an attack, I don’t really quite know how to prevent it. It’s actually a much harder thing to do than that. I mean, I can out-compete them, because there are better ways to do what RSK does. But as a Bitcoin user, you don’t directly have a way of stopping RSK. So that’s unfortunate.

Nonetheless, despite possible drawbacks of merge mining, RSK represents one of the major sources of innovation on Bitcoin. The semi-trusted method of securing the side chain should be improved once the drive chain protocol is implemented in the Bitcoin protocol. The temporary solution reached by the stakeholders places several high-profile Bitcoin companies and exchanges in charge of the Federation that collectively manage bitcoins that are locked on the RSK blockchain.In addition, RSK implemented DECOR+ and FastBlock5 protocols that allow reaching a faster average block rate while disincentivizing mining centralization and selfish mining. Moreover, the RSK also improves transaction capacity by orders of magnitude, which may be enhanced even more with the Lumino protocol built on top of RSK. Naturally, RSK raised the hopes of many in the Bitcoin community, as it could end up being a real competitor in smart contract platforms, even enough to threaten Ethereum. In our conversation, RSK’s Sergio Lerner addressed this topic:

It won’t be a threat for a couple of years. On the contrary, I see that the existence of RSK is a good sign for the Ethereum developers because it shows confidence in the EVM and represents an alternative platform in case Ethereum fails to deliver the PoS migration long promised.

But I understand that in the mid-to-long term, if the Ethereum token price keeps going down compared to Bitcoin, then confidence in Ethereum may decrease. Also, the PoS switch represents a risky cliff: if something goes really wrong, then migration to RSK can happen overnight.

Liquid

By 2021, Liquid is one of the two Bitcoin sidechains in operation, along with RSK. It was developed by Blockstream to address the particular needs of traders and exchanges. At the time of writing, there are 35 exchanges and financial institutions involved in the network. The whole concept of sidechains was initially described in a 2014 paper written by some of the company founders and other Bitcoin developers. It is based on an open source platform called Elements, developed by the namesake company that launched a year later in 2015.It offers almost instantaneous transfers between exchanges, especially attractive when it comes to arbitrage trading. Apart from that, the network offers faster block verification and, more importantly, confidential transactions that allow users to hide the transacted amount. All these features come at the expense of a semi-trusted solution that relies on the foundation of the institutions involved, however. Overall, that is a reasonable price to pay for the benefits offered.

Statechains

Statechains are some of the more recent layer two proposals that aim to help Bitcoin with scaling. It uses a semi-trusted setup, as the funds are locked in a multisig between the user and the statechain entity that transfers the private key, also called the transitory key, to the transaction recipient. The term semi-trusted is used because even though the statechain entity cannot move coins at will, it could do so in cooperation with other users who own the transitory key. It is important to note that the statechain entity resembles something like the federation or foundation used by Liquid and RSK. Statechains could also work hand-in-hand with the Lightning Network, as they allow creating payment channels without having to actually make an on-chain transaction, an often criticized feature in Lightning.

Easypaysy

Perhaps the most recent proposal of a layer two protocol, launched by José Femenías Cañuelo in December 2019, is Easypaysy. It essentially allows users to create Bitcoin account IDs in the form of words that would be familiar to those who use the BIP39 format. Such accounts would represent a significant boost in the user-friendliness of Bitcoin addresses, a goal attempted by many altcoin projects as well. The proposal also introduces three different payment types that differ in setup and level of interaction they require between the payer and payee. The paper proposes also creation of domain IDs that would depend on the Domain Name System (DNS).

The Second Decade of the Bitcoin Protocol

In 2019, Bitcoin entered its second decade of operation as one of the most developed protocols on Github with innovations happening on every layer. Given the sheer volume of transactions, it is reasonable to assume that Bitcoin will become the protocol of choice when it comes to the transfer of value over the Internet. It is almost impossible to track, as your humble author has attempted, to understand the details of all development initiatives that happen around Bitcoin, but this section attempts to map most of them.

Even though Bitcoin Script has been often criticized, mainly by the altcoin community for being too “dumb,” history suggests that despite its simple stack-based nature, it remains fairly complex. This realization was manifested by Satoshi when he disabled some Bitcoin opcodes himself, owing to a series of critical bugs that were unveiled. A team of researchers at Blockstream came up with further optimisations of Bitcoin syntax when they proposed Miniscript. Miniscript stripped down Bitcoin’s Script to a few components to make programming and verification easier. As it abstracts away certain complexities by limiting some of the Script’s capabilities, it makes the scripts, in general, safer. Miniscript is not the only new language being worked on when it comes to Bitcoin. Simplicity and Ivy are programming languages that were designed to make smart contract development on Bitcoin easier.

The notion of smart contracts on Bitcoin has been a constant end goal for many in the crypto space. Bitcoin maximalists would argue that Bitcoin already supports smart contracts as they are merely if-then statements locking scripts used in every Bitcoin transaction. Nevertheless, more complex smart contracts are likely to arrive on the first layer. There are a number of technological components that are being worked on as of early 2021, and that will make it possible. Sources with extensive explanations of each of the respective techniques are linked in the bibliography.

One of them are called MASTs (Merkelized Abstract Syntax Trees) that were proposed in BIP114. They combine data structures such as Merkle trees and Abstract Syntax Trees (AST) into something that brings more privacy and more complex smart contracts to Bitcoin while reducing transaction size. What MAST does is that it allows the describing of any program or script by splitting it into individual parts. This alone makes it easier to analyze and optimize the code. Each of these parts is further hashed into a short unique identifier that is paired with an identifier of another part and so on, until there is only one identifier left on top of the structure — the merkle root.

Nowadays, when sending a transaction, a user may create multiple conditions upon which the UTXO (Unspent Transaction Output) they are sending may be redeemed. All these conditions are in the blockchain, accessible by the public. While implementing MASTs will leave the outside observer with the knowledge that there are multiple conditions that redeem the UTXO, what those conditions look like will remain unknown to him. Therefore, this may be considered as a decent privacy improvement.Another benefit of MASTs is that they make adding subscripts less data-heavy, and thus cheaper. Reduction in size not only allows one to add subscripts for lower costs, but also allows for creating scripts with complex conditional branches that have not yet been possible. This is because Bitcoin has various hard limits that apply to individual scripts. Bare scripts as well as segwit scripts are limited to 10,000 bytes and Pay to Script Hash transactions (or P2SH) have a limit of 520 bytes. MASTs enable us to bypass these limits with smart use of cryptography.

One of the implementations of the MAST structure is called Taproot. Taproot allows the expression of an application in the form of a Merkle Tree where each branch of the tree represents a different outcome. This technique should be accompanied by Tapscript, a programming language that allows for easier definition of the spend conditions for each of the branches. Privacy properties of MASTs may be well combined with some other techniques that have been proposed for inclusion into the Bitcoin codebase.

These include Schnorr signatures. When Satoshi began his work on Bitcoin, he had to decide which signatures scheme to use. The goal was to choose something well-understood, sufficiently secure, widely used, and ideally open-source. He went for Elliptic Curve Digital Signatures Algorithm (or ECDSA), even though other options existed. Schnorr signatures were another, but at the time they were covered by a patent until 2008. As a result of the patent, Schnorr signatures were less used, and thus less understood, when compared to ECDSA. Moreover, ECDSA was supported by a spectrum of open-source encryption tools. As more than a decade has passed since then, Schnorr signatures are now commonly implemented in some altcoins, and justifiably so as they offer numerous benefits over ECDSA.They are provably secure and non-malleable. Provably secure, meaning that in opposition to ECDSA, we can mathematically prove they are secure without relying on strong assumptions. Malleability in this sense refers to a property that allows a third party with no access to the private key to alter a valid signature for a given public key and message, by producing another signature that is valid for them. Again, this is something present in ECDSA, but absent in Schnorr signatures.

Arguably, the most important feature that differentiates the two signature schemes is that Schnorr allows multiple signers to aggregate their public keys into a single key. Key aggregation thus allows for enhancing efficiency and the privacy of Bitcoin transactions. One of the practical considerations is that entities signing a multi-signature transaction will no longer be identifiable. More importantly, multisig transactions will be indistinguishable from regular transactions. Combining Schnorr signatures with Taproot could result in hiding that a transaction is associated with any MAST structure. As such, Schnorr signatures are a welcomed modification of Bitcoin’s stack.

Activation of Schnorr signatures allows even further protocol upgrades and innovations such as fully private and scalable smart contracts in the form of digital signatures, instead of opcodes. Some design implementations that aim to achieve this include Scriptless Scripts, Discrete Log Contracts, and Generalized Threshold Trees.

Many of these improvements enhance confidentiality of more complex transaction structures. Transaction-graph privacy of simple transactions can be improved by CoinJoin or its derivatives such as PayJoin (also known as P2EP), SNICKER (Simple Non-Interactive Coinjoin with Keys for Encryption Reused) and ZeroLink. A very useful set of upgrades in this regard are Confidential Transactions (CT) that obscure the transacted amount, something that is already deployed on the Liquid network.

However, privacy is more complicated than just the network level. Fortunately, there are teams pushing the boundaries on this front. One of the most anticipated upgrades, not only for Bitcoin but also some altcoins, is Dandelion. Its main purpose is to obscure the source of the transaction during its propagation. It purports to be able to do the job at reasonable costs in terms of latency. Some of the most recent innovative approaches to achieve similar results were presented in 2019 in the form of Erlay. Erlay is a new transaction dissemination protocol that not only increases the security of the network, but also significantly reduces the bandwidth consumption of a full Bitcoin node. This may prove to be an important factor, especially in countries where Internet Service Providers impose bandwidth limitations.

Last, but not least, there is room for improvement when it comes to light client implementations. Simplified Payment Verification (SPV) introduced by Nakamoto has served as the basis since it was inserted into the actual codebase in 2013 in the form of BIP0037. It allowed the light clients to query full nodes for proof that certain transactions happened in a certain block. Difficulties related to implementation of BIP0037 unfortunately led to utilization of other proprietary solutions. Regardless, it allowed the queried server to harvest a lot of information about the light clients. The Neutrino protocol should fix this, as it shifts the burden to filter transactions to the client that receives them compressed from the server. Thus, Neutrino mitigates the privacy leaks and trust issues when it comes to verification of receiving transactions. Even though it is not much help when sending transactions, it is an important step to the right direction.

But innovations in Bitcoin are also happening in areas such as mining. Stratum, the most popular protocol used by mining pools, is being upgraded to its second version that includes BetterHash — a protocol proposed by Matt Corallo. This tweak gives miners using mining pools greater autonomy when it comes to selection of transactions they want to mine. Until this point, miners would usually not even run a Bitcoin node as they delegated this role solely to the pool operators. BetterHash allows them to decide for themselves what kind of block they mine. This largely mitigates risks of centralization related to mining pools. In addition, miners have at their disposal an increasing amount of tools that allow them to hedge against sudden and unpredictable changes related to Bitcoin hashrate and difficulty. Mining derivatives allowed by the POWSWAP protocol represent an important milestone in the evolution of the entire mining industry.

The future of Bitcoin holds a great promise. As more research is completed in the area of consensus algorithms, we can expect various tweaks that will increase the scalability of Bitcoin, even with on-chain improvements similar to proposals like Bitcoin-NG and GHOST that modify the way nodes construct and reorganize blocks. While the former has been implemented in a number of altcoins like Waves, Aeternity or Cypherium, the latter is used in Ethereum. Teams such as Hivemind aim to make popular Bitcoin-based prediction markets. These kinds of applications have so far enjoyed more popularity in the Ethereum space, but chances are their primetime will come to Bitcoin, too. Other ideas formerly proposed, such as Bitcoin Covenants, are occasionally resurfacing. Covenants would enable “vaults'' that essentially allow a kind of transaction that may be reversed in a certain timeframe, which represents a great measure and mitigation against hacks. All the above-mentioned features, if and when implemented in the future, will aspire to make Bitcoin far more secure, efficient, and easy to use.

As discussed in this chapter, the amount of progress in research and development of the Bitcoin protocol is almost impossible to follow and accurately document. Bitcoin has been often criticized for being slow and conservative when it comes to the integration of new features. Certainly, there are merits to this perspective, and history suggests there is evidence to back it up. Many protocols such as Zerocoin, Zerocash, and MimbleWimble were originally meant as upgrades of Bitcoin, but ended up having their own separate blockchains, networks, and currencies. That is why they are discussed in the following chapters and not this one. Bitcoin Core developers have always been vocal that changes to the code should be battle-tested, and therefore they are conservative toward new proposals that often take many years to merge into the codebase. While this level of cautiousness is favored by most of the Bitcoin OGs, there are some that despise it and find it detrimental to Bitcoin’s cause. One of the earliest Bitcoin developers, Amir Taaki, expressed his critical views for Bitcoin Magazine:

The problem is that the culture we initiated in those early days has completely overtaken the mindspace of Bitcoin. That was not the original intent. Originally, the intent was to have Bitcoin be a conservative against changes. But it wasn’t to stop any kind of progress from happening inside of Bitcoin. It’s very poorly engineered. It’s very inefficient. The developments in cryptography that are happening now are going to lead to a system that’s eventually going to supersede Bitcoin.

What we’ve seen happen since then is that those simplistic ideologies, which initially converged around Bitcoin, haven’t really been able to guide us. And so we’ve seen a diversification from these ideologies … There’s this weird, regressive or reactionary Bitcoin culture … and it’s opposed to any kind of change or progress or development or advancement.

Taaki is by far not the only Bitcoin developer who abandoned the oldest digital currency to work on other blockchain protocols with a more receptive environment and community. But the vigilant approach of Bitcoin Core is justified. With hundreds of billions at stake, and so far still an irreplaceable role in the broader crypto economy, there is little space for missteps, especially when it comes to the development of such a crucial piece of the Internet’s infrastructure. Time has shown that many of the protocol upgrades that initially caused excitement have been flawed, and thus prudence is appropriate. Zerocoin and Zerocash are the most notable examples. When it comes to Bitcoin, as the saying goes, it is better to be safe than sorry. The plethora of competing blockchains offers a tremendous amount of space for experiments of all kinds. In such a dynamic, complex and volatile space as that of cryptocurrencies, a stable anchor in the form of Bitcoin is a welcome component.