Over the last 10 years, the Bitcoin ecosystem has attracted developers to dedicate thousands of hours to improve and revamp most of its underlying codebase. Yet, Bitcoin (BTC) is largely the same. The reason for this is that its core set of consensus rules that define its monetary properties, such as its algorithmic inflation and hard-coded supply, remain unchanged.
Time and time again, factions have attempted to change these core properties, but all hostile takeovers thus far have failed. It’s often a painful process but one that highlights and solidifies two of Bitcoin’s biggest virtues: No single party can dictate how Bitcoin evolves; and the absence of centralized control protects Bitcoin’s monetary properties.
The barriers to development — and working through them
The values that make Bitcoin a popular phenomenon are also those that make developing software atop Bitcoin more challenging than any other digital asset. Developers are limited to what they’re able to transform in order to not undermine its apparatus as a store of value.
Nonetheless, as we’ll see from the examples below, innovation in Bitcoin is possible. It requires creativity and patience.
Since changing Bitcoin’s core layer requires a quasi-political process that may infringe upon its monetary properties, innovation is often implemented as modules. This development is similar to that of the internet’s protocol suite, where layers of different protocols specialize in specific functions. Emails were handled by SMTP, files by FTP, web pages by HTTP, user addressing by IP and packet routing by TCP. Each of these protocols has evolved over time to create the experience we have today.
Spencer Bogart of Blockchain Capital has captured this development succinctly: We are now witnessing the beginning of Bitcoin’s own protocol suite. The inflexibility of Bitcoin’s core layer has birthed several additional protocols that specialize in various applications, like Lightning’s BOLT standard for payment channels. Innovation is both vibrant and relatively safe, as this layered approach minimizes potential risks.
The diagram below is an attempt to map all relatively new initiatives and showcases a more complete representation of Bitcoin’s technology stack. It is not exhaustive and does not signal any endorsement for specific initiatives. It is, nevertheless, impressive to see that innovation being pushed on all fronts — from Layer 2 technologies to emerging smart contract solutions.
There has been a lot of talk lately about the rate of adoption of the Lightning Network, Bitcoin’s most prominent Layer 2 technology. Critics often point to an apparent decline in the number of channels and total BTC locked when evaluating Lightning’s user adoption. Yet, these metrics aren’t the most definitive measurement of adoption.
One of the most underrated virtues of the Lightning Network is its straightforward privacy properties. Since Lightning does not rely on global state reconciliation — i.e., its own blockchain — users can transact privately over using additional techniques and network overlays, like Tor. Activity happening within private channels is not captured by popular Lightning explorers. As such, an increase in private usage of Lightning has resulted in a decrease in what can be publicly measured, leading observers to erroneously conclude that adoption is down. While it is true that Lightning must overcome substantial usability barriers before it can enjoy wide adoption, using misleading metrics to make assertions about the current state of the network serves few.
Another recent development in the field of Layer 2 privacy was the creation of WhatSat, a private messaging system atop Lightning. This project is a modification of the Lightning Network Daemon (LND) that allows the relayers of private messages, who connect the entities communicating, to be compensated for their services via micropayments. This decentralized, censorship-and-spam-resistant chat was enabled by innovations in the LND itself, such as recent improvements in the lightning-onion, Lightning’s own onion routing protocol.
There are several other projects leveraging Lightning’s private micropayment capabilities for numerous applications from a Lightning-powered cloud computing VPS to an image hosting service that shares ad revenue via microtransactions. More generally, we define Layer 2 as a suite of applications that can use Bitcoin’s base layer as a court where exogenous events are reconciled and disputes are settled. As such, the theme of data anchoring on Bitcoin’s blockchain goes beyond Lightning, with companies like Microsoft pioneering a decentralized ID system atop Bitcoin.
There are projects attempting to bring back expressive smart contract functionality to Bitcoin in a safe and responsible way. This is a significant development because, starting in 2010, several of the original Bitcoin opcodes — the operations that determine what Bitcoin is able to compute — were removed from the protocol. This came after a series of bugs were revealed, which led Satoshi to disable some of the functionality of Script, Bitcoin’s programming language.
Over the years, it became clear that there are non-trivial security risks that accompany highly-expressive smart contracts. The common rule of thumb is that the more functionality is introduced to a virtual machine — the collective verification mechanism that processes opcodes — the more unpredictable its programs will be. More recently, however, we have seen new approaches to smart contract architecture that can minimize unpredictability and also provide vast functionality.
The devise of a new approach to Bitcoin smart contracts called Merklized Abstract Syntax Trees (MAST) has since triggered a new wave of supporting technologies for Bitcoin smart contracts. Taproot is one of the most prominent implementations of the MAST structure that enables an entire application to be expressed as a Merkle Tree, whereby each branch of the tree represents a different execution outcome.
Another interesting innovation that has recently resurfaced is a new architecture for the implementation of covenants, or spend conditions, on Bitcoin transactions. Originally proposed as a thought experiment by Greg Maxwell back in 2013, covenants are an approach to limit the way balances can be spent, even as their custody changes. Although the idea has existed for nearly six years, covenants were impractical to be implemented before the advent of Taproot. Currently, a new opcode called OP_CHECKTEMPLATEVERIFY — formerly known as OP_SECURETHEBAG — is leveraging this new technology to potentially enable covenants to be safely implemented in Bitcoin.
At first glance, covenants are incredibly useful in the context of lending — and perhaps Bitcoin-based derivatives — as they enable the creation of policies, like clawbacks, to be implemented on specific BTC balances. But their potential impact on the usability of Bitcoin goes vastly beyond lending. Covenants can allow for the implementation of things like Bitcoin Vaults, which, in the context of custody, provide the equivalent of a second private key that allows someone that has been hacked to “freeze” stolen funds.
In essence, Schnorr signatures are the technological primitive that make all of these new approaches to smart contracts possible. And there are even edgier techniques being currently theorized, such as Scriptless Scripts, which could enable fully private and scalable Bitcoin smart contracts to be represented as digital signatures as opposed to opcodes. These new approaches may enable novel smart contract applications to be built atop Bitcoin.
There have also been some interesting developments in mining protocols, especially those used by mining pool constituents. Even though the issue of centralization in Bitcoin mining is often wildly exaggerated, it is true that there are power structures retained by mining pool operators that can be further decentralized.
Namely, pool operators can decide what transactions will be mined by all pool constituents, which grants them considerable power. Over time, some operators have abused this power by censoring transactions, mining empty blocks and reallocating hashing without the authorization of constituents.
Changes to mining protocols have aimed to subvert the control that mining pool operators can have on deciding what transactions are mined. One of the most substantial changes coming to Bitcoin mining is the second version of Stratum, the most popular protocol used in mining pools. Stratum V2 is a complete overhaul that implements BetterHash, a secondary protocol that enables mining pool constituents to decide the composition of the block they will mine — not the other way around.
Another development that should contribute to more stability is reignited interest in hash rates and difficulty derivatives. These can be particularly useful for mining operations that wish to hedge against hash rate fluctuations and difficulty readjustments.
Contrary to some arguments out there, there are a host of emerging protocols that can bring optional privacy into Bitcoin. That being said, it is likely that privacy in Bitcoin will continue to be more of an art than a science for years to come.
More generally, the biggest impediment to private transactions across digital assets is that most solutions are half-baked. Privacy assets that focus on transaction-graph privacy often neglect network-level privacy, and vice versa. Both vectors suffer from a lack of maturity and usage, which makes transactions easier to de-shield via statistical traceability analysis at either the peer-to-peer (P2P) network layer or the blockchain layer.
Thankfully, there are several projects that are pushing boundaries on both fronts.
When it comes to transaction-graph privacy, solutions like P2EP and CheckTemplateVerify are interesting because privacy becomes a by-product of efficiency. As novel approaches to CoinJoin, these solutions can increase the adoption of private transactions by users that are solely motivated by lower transaction fees. As CoinJoins, their privacy guarantees are still suboptimal, but unshielded sent amounts can be beneficial, as they preserve the auditability of Bitcoin’s supply.
If lower transaction fees become a motivator and lead to an increase in Bitcoin’s anonymity set — the percentage of UTXOs that are CoinJoin outputs — de-anonymization via statistical analysis will be even more subjective than it already is.
There has also been considerable progress in the privacy of P2P communications, with protocols like Dandelion being tested across crypto networks. Another notable development is Erlay, an alternative transaction relay protocol that increases the efficiency of private communications and reduces the overhead of running a node. Erlay is an important improvement since its efficiency gains enable more users to more easily complete IBD and continuously validate the chain, especially in countries where ISPs impose caps on bandwidth.
It’s just the beginning
These examples are only a handful of initiatives in play to transform the Bitcoin framework. Bitcoin, in its totality, is a constantly evolving suite of protocols.
While evolution within a relatively strict set of rules and values can be challenging for developers, the layered approach that we’ve seen unfold is what makes gradual, effective change possible. Minimizing politicism within Bitcoin and protecting its fundamental monetary properties are necessary parts of the process. Developers are learning how to work within these bounds in a meaningful fashion.