Layer 2

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 at an apparent decline in the number of channels and total BTC locked in Lightning; two metrics frequently used to evaluate user adoption. Although the community has converged on such metrics, it is important to point out that they are fundamentally flawed given the way Lightning works under the hood.

One of the most underrated virtues of the Lightning Network is its straightforward privacy properties. Since Lightning does not rely on global validation of all state changes (i.e. its own blockchain), users can transact privately over using additional techniques and network overlays, like Tor. At this point, we can estimate the percentage of private usage of the Lightning network by analyzing the number of channel opening transactions on-chain, and comparing that to the number of public channels off-chain. Christian Decker estimates that 41% of Lightning channels are private:

Activity happening within these channels is not captured by popular Lightning explorers. As such, an increase in private usage of Lightning results 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, we must stop using misleading metrics to make assertions about the current state of the network. As Decker pointed out in his talk at the latest Lightning Conference in Berlin, even the above estimate of private vs. public channels is flawed, as the adoption of Schnorr signatures will make channel-opening transactions indistinguishable from regular transactions.

Another interesting 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 deamon which allows for relayers of private messages (the messengers that connect the entities communicating) to be compensated for their services via micropayments. This decentralized, censorship-and-spam-resistant chat was enabled by innovations in LND itself, such as recent improvements in the lightning-onion, Lightning’s own onion routing protocol.

The growth of Lapps, or Lightning Applications, demonstrate the wide applicability of these innovations when it comes to consumer applications, from a Lightning-powered cloud computing VPS to an image hosting service that shares ad revenue via microtransactions. And that’s just layer 2 innovation within Lightning. More generally, we define Layer 2 as a suite of applications that 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 is much broader, with companies like Microsoft pioneering a decentralized ID system atop Bitcoin. Such initiatives increase the demand for on-chain reconciliation and are instrumental for the long-term development of a Bitcoin fee market.

Smart Contracts

There are also a number of 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 terrifying bugs were unveiled, which led Satoshi himself to disable some of the functionality of Script, Bitcoin’s programming language.

Over the years, it became crystal clear that there are non-trivial security risks that accompany highly-expressive smart contract functionality. 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 in Bitcoin that can minimize unpredictability, but also provide vast functionality.

The devise of a new approach to Bitcoin smart contracts called Merkleized Abstract Syntax Trees (MAST) has ignited a new wave of supporting technologies that attempt to optimize the trade-offs between security and functionality. Most prominently is Taproot, an elegant implementation 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. Along with Taproot will come a programming language called Tapscript, which can be used to more easily express the spend conditions associated with each branch of the Merkle Tree.

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 seven years, covenants were impractical to be implemented before the advent of Taproot. Now, 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 attached to 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 a party that has been hacked to “freeze” stolen funds. There are so many other applications of this technology, like Non-Interactive Payment Channels, Congestion Controlled Transactions, CoinJoins, it truly deserves a standalone post. For more on this, check out Jeremy Rubin’s BIP draft.

It is important to note that Schnorr signatures are the technological primitive that make all of these new approaches to smart contracts possible. After Schnorr activates, even edgier techniques being can be 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). Similarly, Discreet Log Contracts also employ the idea of representing a smart contract’s execution outcome as a digital signature for better privacy and scalability. Together, these new approaches may enable novel smart contract applications to be built atop Bitcoin and Schnorr is the basis of it.

Mining

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 which 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 output to other networks without the authorization of constituents.

Thankfully, there are technologies that are attempting to flip that power structure upside down. 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 and not the other way around. Stratum V2 also implements several optimizations, and allows mining pool constituents to better communicate and coordinate.

Another interesting development in the mining industry that should contribute to more stability is reignited interest in hashrate and difficulty derivatives. These can be particularly useful for mining operations that wish to hedge against hashrate fluctuations and difficulty readjustments. While these derivatives have yet to be productized, this marks an interesting evolution in the industrialization of Bitcoin mining.

Privacy

After our report on Schnorr signatures, some privacy-coin advocates were outraged by the suggestion that sufficient privacy may be optionally achieved in Bitcoin at some point. Although this suggestion may challenge theses around the long-term value proposition of privacy assets, there are a host of emerging protocols that can bring better privacy into Bitcoin. Although it is likely that privacy in Bitcoin will continue to be more of an art than a science, there have been interesting innovations on this front that are worth highlighting.

Before we delve into specific privacy innovations, it’s important to highlight that the biggest impediment to private transactions across digital assets is the fact 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-anonymize via statistical traceability analysis at either the P2P network layer or the blockchain layer.