Bitcoin is a decentralized and censorship resistant network built around independent participants maintaining and verifying their own copy of the database storing its historical transaction record. 

Its entire purpose for existing is to function in a manner that prevents anyone from being shut out of the system, or prevented from using it. That is its raison d’être.

People will use Bitcoin for things that it wasn’t intended for, or things that some people disapprove of, or some things that almost everyone will agree is abhorrent. These things will happen because Bitcoin works, you can’t stop people from using it. 

The entire conversation around this reality in the last year or so hasn’t even really touched on the core dynamics of competing use cases, it has just been an argument between people advocating trying to stop people from using Bitcoin in certain ways, and people explaining the futility of that. There is an inescapable underlying reality that the entire discourse, debate, or whatever you want to call it, is almost entirely ignoring: there are different use cases for blockspace, with different needs of blockspace, and these all compete with each other. 

That is writ large. 

So what do we do about that? There is nothing to do but adapt. Blockspace is a competitive free market, it is Darwinian. Different use cases are very much like organisms, existing in an environment called the blockspace market. Like all environments, it can change and become dominated by new conditions. Anomalous and extreme events or changes in that environment can occur. It’s a dynamic system. 

Like any organism in any changing or dynamic environment, use cases must adapt to those changes. 

Blockspace Density

One of the core considerations when it comes to a use case adapting is density. How “dense” can a single use case’s utilization of blockspace be? 

To put another way, how much can you compress the transactions required to fulfill a certain use case in order to minimize the blockspace required, and therefore the cost required. Means of exchange as a use case is a good example to start with. When Bitcoin was first launched, a single transaction, or exchange, required a single on-chain transaction in order to facilitate. Each and every economic exchange required one transaction’s worth of blockspace. 

That is no longer the case, because the “density” of Bitcoin’s use as a means of exchange increased dramatically with the introduction of off-chain accounting mechanisms. This includes everything from custodial ledgers like ChangeTip (an old tipping service), Coinbase, and Wallet of Satoshi, to decentralized and self-custodial tools like the Lightning Network, Ark, and other Layer 2 designs. The efficiency of Bitcoin as a means of exchange has increased by orders of magnitude compared to Bitcoin’s early days. The amount of blockspace necessary to meet this use case is orders of magnitude less than what it used to be. 

Let’s look at another use case, timestamping. Bitcoin is incredibly useful in this regard, by embedding a piece of data (or a hash of said data) into the blockchain, the existence of any digital file at the time it is confirmed can be proven thermodynamically beyond the shadow of a doubt. In the early days of the network, people used to include the hashes of every individual file being timestamped in an OP_RETURN of a single transaction. One transaction = one file timestamped. 

That is clearly not very dense at all, and not very scalable. Opentimestamps changed this. Rather than make an individual transaction for each file to be timestamped, Opentimestamps introduced the concept of a “calendar server” that would accept numerous file hashes to be timestamped, and construct a merkle tree including all of them. A single transaction can now timestamp an infinite number of file hashes. 

This was demonstrated by Opentimestamps creator Peter Todd in 2017, when he timestamped the entirety of the contents of the Internet Archive. That included over 750 million files, all thermodynamically attested to with a single transaction. If the density of the means of exchange use can be viewed as equivalent to a neutron star, an extremely dense stellar body, timestamping is the equivalent of the largest blackhole in the universe. 

Let’s look at a final use case example, inscriptions. This use case utilizes blockspace in order to not just prove the existence of a piece of data at a certain point in time, but to make use of the Bitcoin blockchain in order to ensure that piece of data remains available to all who want it by counting on the incentives of the network to ensure the blockchain in its entirety remains available. 

This use case has been made marginally denser. Ord, the ordinals and inscription client, has implemented compression algorithms for different types of data such as text and pictures. This however can only go so far, as the laws of information theory show that information can only be compressed so far without destroying information in the process. Trying to compress data beyond this limit renders such data irrecoverable. 

Other NFT projects have tried to get inventive to circumvent this limitation, inscribing individual pieces of art such as body outlines, facial features, etc. and using small snippets of code to programmatically generate individual NFT images from these pieces. But that again can only go so far. 

This is a use case that, given its entire purpose is to write the data itself directly to the blockchain in order to guarantee its durable availability, cannot be made denser to the same degree things like means of exchange use or timestamping can be. 

Trust Models

One of the inescapable realities of increasing the density of blockspace use for individual use cases is the implications that has for any given use case’s trust model. 

Looking at the means of exchange use case is the clearest example of this. Making a transaction on-chain is as trustless as a bitcoin transaction can be. A user can be in total control of their own funds, with no restrictions whatsoever on their use except the need to pay for blockspace. The denser you make transactional use, i.e. the more transactions you try to facilitate off-chain, the more you introduce new restrictions or trust requirements. 

To transact on the Lightning Network means your coins must be locked into a payment channel. This subjects your funds to the liquidity requirements of the Lightning Network. Are funds available in other channels to route a payment to your intended destination? It also subjects your funds to time restrictions in the worst case scenario. If your channel counterparty is unresponsive, you must wait through a timelock in order to claim back unilateral control of your funds. It also introduces the responsibility to keep more data secure. If your channel state data is lost, access to your funds can be lost forever. Unlike mnemonic seeds, this data cannot simply be “regenerated” from a static one time backup. 

Custodial systems are yet another different set of restrictions and trust trade offs. You might not be subject to liquidity requirements like on Lightning, but you must now completely trust your custodian. In order to transact, their permission is required. In order to claim back your money through a “less dense” mechanism, their permission is required. Everything you want to do with your funds requires that custodian’s permission. 

Timestamping is a relatively easy thing here. The only change with more dense mechanisms like Opentimestamps is the need to store extra data, the merkle proof connecting the timestamp to the blockchain. Other than that, there are no fundamental differences, and the trust model of Opentimestamps is the same as directly timestamping a single file. It proves that file existed at that time, and nothing else. 

Inscription’s trust model is essentially destroyed by attempting to maximally increase the use case density, i.e. storing files entirely off-chain. It is simply not possible to increase the density of this use case beyond the marginal improvements already made on-chain without completely destroying the trust model the entire use case is predicated on in the first place. 

Demand Elasticity and Scaling

If each use case is to be looked at like an organism in a Darwinian environment, each use case’s ability to tolerate higher fees is the equivalent of an organism’s ability to adapt to a new environment. 

If a use case can’t pay higher fees when the blockspace market gets more competitive, then it effectively dies. It becomes an evolutionary dead end. There are only two ways that a use case can adapt to a higher environment, either users just suck it up and pay the higher fees, or some mechanism is found for distributing fees amongst multiple users so that the individual cost is still bearable. 

For transactional use cases, this necessitates facilitating more users being able to coordinate to share control of a single on-chain coin, and importantly having a cost effective mechanism for enforcing their share of ownership on-chain if necessary. The Lightning Network, and now soon Ark, have made massive progress in this direction. But it is nowhere near enough to increase blockspace density to the point where it can handle global use at scale without defaulting to most people using custodians. 

That denies Bitcoin’s most important properties to most means of exchange users at scale. There is still a lot of work to be done in order to increase this use case’s density enough to bring censorship resistance to the masses. 

Timestamping has already solved this problem as efficiently as it can be solved. A merkle tree is unbounded in size, and can commit to an infinite number of hashes. This means that an infinite number of users can collaborate to bear the cost of the single transaction necessary to timestamp everything. 

Inscriptions cannot really adapt in the same way as the other two. While many users could collaborate in order to share the cost of inscribing data, this isn’t practical for many use cases. That might work if the goal is to inscribe some politically or socially relevant information, such as sensitive data leaks from government or corporate databases, but this is not the primary use case for Inscriptions. NFTs and other speculative assets are. 

It makes no sense for a large group to share the cost of inscribing NFT data if only one person can “own” the resulting NFT. You could potentially share ownership with schemes like multisig, but this would be a complete evolution of the use case itself, not simply how the use case is facilitated. At the end of the day someone inscribing an NFT to sell must sell it for more than the cost to inscribe it. Otherwise they are losing money. 

This will have an impact on the demand for such assets, and as such Inscriptions are decidedly at a disadvantage to other use cases in this respect. 

Adapt or Die

You cannot stop people from using Bitcoin, even if you don’t like how they are using it. If you could, then Bitcoin would be a failed project that cannot even deliver on one its core value propositions: censorship resistance. 

This is just the reality of how it works. Conversations around how to stop certain use cases, or users, is an exercise in futility, and quite frankly a comedy show. It completely ignores the reality of what Bitcoin is, how it works, and the underlying fundamental dynamics of multiple use cases existing together in a competitive system built around a scarce resource: blockspace. 

It should be very clear that means of exchange as a use case has a decided advantage over a use case like Inscriptions in almost every way. It can be made denser, it can scale further while keeping more of its ideal trust model intact, and its demand is much more inelastic. If bitcoin’s desirability as a means of exchange faded, then Bitcoin as a system in its entirety would fade. Even just buying and selling the asset is a use as a means of exchange, it is being exchanged for fiat. 

It is the primary use case, and for it not to be means that demand for bitcoin in general has failed to materialize to a sustainable level. That is clearly not the case. 

Conversations around different use cases of Bitcoin should be focused on a single thing: how to increase the density of a use case, while maintaining the properties of its ideal trust model, to remain competitive with others in the market for blockspace. 

If we want bitcoin to become a primary means of exchange, a global money, then this is necessary. Its density must increase, and its competitiveness must be maintained. Users who engage in other use cases can worry about those themselves, but all of us must be concerned with the competitiveness of the use case of means of exchange. 

That is, unless you’re cheering on Bitcoin to win a Darwin Award.