Make the fundamental primitive pieces of "tape"

[joshdoman]

@casey and I were talking offline about how Bitcoin metaprotocols can be thought of as immutable Turing Machines, running on pieces of tape.

I'd like to publicly share a proposal that expands upon this idea, and suggests a fundamentally different way to build metaprotocols on bitcoin, which could provide a path toward a far more composable, and therefore less brittle, way of building basic metaprotocol primitives that live on the same piece of "tape."

Metaprotocols as Turing Machines, running on pieces of tape
There is a simple way to describe meta protocols on Bitcoin, to someone who has no understanding of how bitcoin-transactions are structured themselves.

Bitcoin can be thought of as an ever-lasting, ever-running "tape," which can be wound backwards and replayed at any time. It has a definite beginning, but game theoretically, the tape will keep going forever, as long as there exists someone and something to add.

This tape, from a certain perspective, looks like nothing more than a series of complete random and meaningless bytes. According to a specified set of rules, which we-the-people decide, those bytes are grouped into chunks, called "blocks," and those blocks of data are sent through a machine that does nothing except determine whether to accept it as an extension of the existing tape, or whether it first needs to be rolled back.

At any time, however, new chunks of data can be presented, which convince the machine to rewind the tape to a certain point, and add those chunks of data instead.

Critically, beyond this consensus mechanism, those bytes of data need not have any specific meaning to anyone. That's all they are. Bytes.

Now, of course, as of today, that consensus mechanism relies on a specific meaning of those bytes. They must be structured in a specific way that we-the-people generally agree represent something of value. That thing is bitcoin, the first perfectly finite and "conserved" ownable idea, which we as bitcoiners consider to be the perfect representation of "money."

For this reason, we as bitcoiners accept the idea that bytes can only be added to the "tape" if they're first assembled into a finite-sized block of data, which contains bytes representing a certain amount of "work." Within the block, we also accept that bytes can only be structured in a way that represents what we consider to meaning bitcoin "transactions."

We do not care if non-bitcoiners do not assign meaning to these bytes. That is their prerogative, just as it is ours. Like anything, we give meaning to the tape only the way we want.

With this framework in mind, we can easily explain "Bitcoin" to anyone. It is nothing but a piece of tape, where we-the-people choose what gets added, and under what conditions it gets rewound. This provides a way to explain "Bitcoin" to someone who doesn't assign the same meaning to the bytes as we do. They might say bitcoin-the-asset is meaningless, but they can still grasp the idea of a universal, global tape.

Why do tapes matter?
In some ways, the entire field of computing can be traced back to a single, groundbreaking idea: the Turing Machine.

This was invented by Alan Turing, as a way for describing a process which we call "computation."

A Turing machine is quite simple. It consists of a piece of tape, that is fed into the machine, and a second piece of tape, which comes out.

This tape represents nothing more than a series of 1s and 0s. The machine decides how to give those 1s and 0s meaning, and the machine decides how it wants to give meaning to the 1s and 0s coming out.

That meaning then governs a "program" in the machine, which determines what 1s and 0s get placed onto the second tape, given the input 1s and 0s being fed through by the first.

The tape that is "Bitcoin" is what we, as metaprotocol developers, consider to be the first. We accept, if not cherish, that we get to release the burden of what governs the Tape to others, who maintain the backward-compatible set of rules that govern the process of adding to the tape.

Just as we give up one burden, we take on another. We are responsible for writing an immutable, backward-compatible set of rules that give meaning to some of the 1s and 0s on the Tape, and decide the meaning and the 1s and 0s of a new tape coming out.

We write our own machine. We form our own tape.

In this manner, you can begin to see how metaprotocols can begin to compose on one another.

At the bottom most layer, we have a machine that reads bytes from the "Bitcoin" tape, which are reserved by consensus for the representation of concepts that are not important for consensus.

Today, these explicitly reserved bytes can be found in only 1 place. A transaction output that is explicitly reserved for data that will never be consensus critical.

This location is defined by what we call an OP_RETURN output. Data can be placed in this output that core developers promise will never be critical to consensus. The reason core developers did this was not necessarily to help metaprotocol developers, but it was done from the correct place, and with the right intention: to restrict the size of what we call the unspent transaction output (or "UTXO") set. This is important because the UTXO set defines a significant part of the state that the base "Bitcoin" machine maintains, governing consensus over the 1s and 0s that get added to the tape.

The second location, which appears to have become generally accepted as legitimate, or at least tolerated, was not explicitly promised by core developers to be "reserved." This location is in a location of the "Bitcoin" transaction which we bitcoiners call the "Witness." The "Witness" part of the base tape contains 1s and 0s, which the base machine uses to decide when a UTXO is allowed to be consumed.

As the "Witness" is part of the tape, but not a part of the UTXO set, placing data there has been tolerated by users and core developers. It has no effect on the memory requirements of the base machine, beyond what has already been allowed by the generally agreed upon speed at which 1s and 0s are allowed to be added to its tape. With the discovery by @casey of a concept within a witness, called an "Envelope," core developers have recognized that no amount of restrictions can be placed on the Witness, to prevent user's from reserving 1s and 0s there.

Naturally, the "Witness" is the optimal location for non-consensus critical data, having no incremental effect on the burden of running the core machine. Recognizing this basic truth, and a technical need to separate this data from the concept considered by the original machine to be a "Transaction," general consensus was laboriously reached to upgrade the core machine and allow witness 1s and 0s to be take off the original tape and added to a second, which is somewhat larger and can facilitate more throughput per second.

For this reason, bytes stored in the "Witness" are given what is called the "witness discount," making it cheaper to reserve data there than in the original explicit reserved location, the OP_RETURN, which lives only on the more expensive original tape.

The "Envelope" concept developed by @casey has one recognized, fundamental flaw. It requires two transactions to be made on the core machine's original tape, not one. This limits the scenarios where it makes sense to reserve large amounts of data in the Witness, because the cost of the 1s and 0s of the second transaction must be outweighed by the savings of reserving data there.

Recently, I was shocked to learn that there is a hidden field, in a special type of transaction, that could enable a single transaction to reserve data in the Witness. As of now, unlike an envelope, there is no way to be certain 1s and 0s placed there won't need to be used by bitcoiners in the future to implement a critical upgrade to the core machine.

This creates an extremely perilous potential future situation, because who gets to decide who is a "bitcoiner"?

Let's consider the worst case scenario. A well-intentioned developer builds an extremely powerful basic new primitive, as a metaprotocol that only exists by reserving the bytes of this hidden field. Most critically, the developer forgets to attach a flag in the first byte, which can be used by bitcoiners to upgrade the core machine, without affecting the metaprotocol.

What could happen, in the worst possible case? You could have extraordinarily valuable "real world" assets, whose lives and proof of ownership live exclusively within that slot, and whose owners have interests that are not completely aligned with the interests of today's "bitcoiners."

This is a potentially perilous situation for Bitcoin as a whole, especially if miners feel their profitability, and thus survival, depends upon the continued use of said protocol. This could eliminate what might be the best and only way to make a necessary future upgrade to the core consensus machine.

There is an extraordinarily simple solution, however, but it requires an explicit soft fork. Bitcoin core developers must add a bit flag to the first byte that can be placed in this hidden field.

If the bit flag is a 1, the bytes placed after it can be consensus critical. If the bit flag is a 0, the bytes placed after it are guaranteed to be meaningless and ignored by the core machine. In this way, the well-intentioned developer will have explicit permission to give whatever meaning they want to the 1s and 0s there.

Frankly, it somewhat alarms me that there exists this hidden potential, with enormous potential cost savings and improvements to the Bitcoin experience, that appears to be entirely unknown outside of a handful of people, aware of an issue on ord, and presumably, the core developers.

While there are safeguards today that make it difficult to get transactions mined that give meaning to the 1s and 0s in this location, it alarms me that the possibility I outlined is not explicitly prevented by the core machine. At present, it feels like the machine is design as though the act of giving meaning to 1s and 0s, that are non consensus critical, is an annoyance, irrelevant to Bitcoin's future success, when it is a fundamental primitive that already exists within Bitcoin, which can be proven can enable real world, extremely valuable use cases.

I made PR #4209 in part to suggest that for bitcoin to succeed as money, the project must accept that there are valid use cases, in the end state equilibrium that are bigger than buying coffee or groceries at a store. Money isn't just a medium of exchange. It's the fundamental form of capital, and it is self-evident, at least to many, that in the end-state equilibrium, Capital will be raised on the tape.

Being the perfect representation of money, Bitcoin will always be the most valuable form of Capital on the tape. But it must be recognized that the tape will contain other fungible and non-fungible representations of Capital. Capital is a superset of Money, and Money, in the perfect end-state, can represent no more than 50% of all Capital.

If this is not intuitive, ask yourself, "What is Capital?"

---

For this reason, I consider it consensus critical that space be reserved on the tape for Capital. Moreover, I consider it critical to consensus that Capital be prioritized as a first-class citizen. This means upgrading the core machine so that it is game theoretically consistent with the presence of Capital.

Capital on the tape does not require any active expansion of the speed at which 1s and 0s can get added. Forms of Capital that can afford to give meaning to 1s and 0s on the existing tape will naturally find a way to. Forms of Capital that cannot, will not. This process is no different than Gravity.

What Capital represents cannot be denied. It is fundamental to the human experience, but like Money, it cannot be easily defined.

ord lays the groundwork for the ability to place forms of Capital on the tape. Before ord, it was presumed impossible for new forms of Capital to spontaneously arise on the same tape as bitcoin-the-asset. The pre-requisites are clear. You need a use case that warrants the block space. You need a well-defined efficient interface. And you need an internal implementation, that is backwards compatible, with strong guarantees of future maintenance. With these fundamental concepts in mind, organic social contracts can develop, which give meaning to bytes, representing new forms of Capital.

And yet, the human experience will always have a physical component. A physical component means a Leviathan, with a monopoly on the use of force. There can be a free market of physical jurisdictions, but whatever those jurisdictions may be, there will always exist instances where Capital cannot be represented on the tape, in the same form and with same degree of organic digital native spontaneity, which reflects forms of Capital presently on it.

Like gravity, forms of Capital that we bitcoiners might not like will get added to the tape. It may take decades, even centuries, for the free market of physical jurisdictions to adopt the same basic principles that Bitcoin embodies. The process may never finish, but the pull of bitcoin-the-asset, as bitcoin-the-money, will compel Capital regardless to be placed on the tape.

---

For this reason, I'd like to kick off the process of starting this conversation. I realize it may be uncomfortable, but I know it is needed, because the principles of Bitcoin's gravity dictates it will happen regardless. The pull of bitcoin-the-perfect-representation-of-relative-capital is simply too strong.

In keeping with the tape analogy, there is an extremely basic primitive that I think could be built, upon which metaprotocols can then rely. This is an abstract piece of tape. A simple machine can be written that simply takes all places where reserved 1s and 0s can be found in a Bitcoin transaction, guaranteed to never be touched by the core machine, and ordered such that a second machine can be fed just these pieces of tape.

This layer of abstraction would not only simplify metaprotocol design. It would give maximum flexibility to end users over where they place 1s and 0s in the core machine's tape, which they choose to assign meaning. No matter where is most cost efficient, or available by consensus, a metaprotocol can be built where the forms of Capital retain their value. The OP_RETURN location is the only such location explicitly guaranteed to always be available, but that fallback is all that is required. Users could naturally gravitate toward whatever, and wherever, is the best place to put their 1s and 0s, and higher level machines can decide when and whether to be upgradable, so that new locations of tape are allowed to be added.

I think this can resolve the precarious potential dilemma I suggested above. While a soft fork on the taproot annex should be imposed, it need not be today. If all metaprotocols by default build upon a machine that simply provides pieces of tape, which can include the taproot annex, but doesn't have to, there is less of a need to place a metaprotocol that lives only there. ord can demonstrate that it is a good actor aligned with Bitcoin by raising the taproot annex concern for discussion, with a solution that already implements the implied soft fork, that can be so good and basic that every metaprotocol chooses to build on top, by default. This would not only demonstrate the legitimacy of ord and the work of its developers in the eyes of the full Bitcoin community, it would meaningfully push Bitcoin forward, in a healthy way and protective way toward what is likely the natural end-state.

Life is like a tape. Sometimes your tape rolls forward, sometimes it needs to be rolled back. It has a definite beginning, but an indefinite end. We each have our own tape, processed through our own machine, but our tapes take as input the tape of other's, and those tapes build on others still.

It is only natural that the collective human experience will one day live on a single digital tape. We can't say what will be on it, or when, or how, but like the proof of the fastest way to sort, there are certain truths we take to be provably self-evident. As bitcoiners, the existence of bitcoin on said tape is one of them.

So we must ask ourselves: What next is the most natural to get added to the tape?

[casey]

Damn this is a wild issue!

First off, very Nick Landian treatment of Capital.

https://www.youtube.com/watch?v=fiaWsgtJrNI

I don't personally like this kind of abstraction.

For one, I think there are crucially important differences between different locations where data can be stored. I see witness envelopes, OP_RETURNs, and Taproot annexes as being very different, with very different properties.

Additionally, tape locations in different places can be written by different entities, based on bitcoin consensus rules, so we have to be aware of those rules in order to interpret the tape.

So I think that when designing and building something on Bitcoin, one must consider the unique and specific qualities of these different locations, and trying to unify them under a common abstraction probably isn't worth it.

Given all that, I'm going to close this. I try to be a tinkerer, and to find concrete, practical, useful things. I try not to be an architecture astronaut, and avoid introducing abstractions where they don't have a concrete and immediate benefit.

I do think it would be worth figuring out how to standardize the ability to put unstructured data in the Taproot annex, but that's really not an ord thing, since there aren't, at present, strong reasons for us to start putting data into the annex.

One note though: I think the ideal format for the annex wouldn't use a single bit to indicate unstructured data, I think it would use a TLV format so that different uses of the annex, consensus and non-consensus, could coexist in the same transaction.

[joshdoman]

Thanks for the feedback. It was mostly a stream of consciousness, but I realize I may have been overly passionate. You're probably right. There's no need for this type of abstraction right now, and probably not even in the future. Once there's a standardized way of putting 1s and 0s in the taproot annex, that will probably become the de facto standard.

The TLV proposal is an interesting one, and you're right, that's almost certainly the best way to format annex data.