Everything built on Bitcoin that you know today goes back to the primitives powered by Bitcoin Script. What do I mean by primitives? The basic components of a programming language that you can use to build actual applications to do things. No programming language has ever been designed specifically for a single application, i.e. to build a single program. They are designed to support basic primitives, such as mathematical operations to manipulate data, create basic data structures to store data in a particular way, or iterate through data as it is processed.
Basic primitives are designed in such a way that developers can specify how they will be used to create an actual application or program. The fundamental design of a language is not necessarily focused on what people will do with it, just that the fundamentals of the language cannot be integrated in a way that either 1) fails to accomplish what the developer is trying to accomplish without them understanding why, or 2) accomplishes what the developer is trying to do in a way that harms the end user.
No one designs a programming language thinking from the beginning, “Oh, we want to enable developers to do A, B, and C, but completely prevent them from doing X, Y, and Z.” (For more technical readers here, what I’m referring to here is the intent of what the developer is building, not low-level technical details like how to integrate primitives.)
Bitcoin Script differs from other programming languages only in one respect, which is what it means for a certain set of primitives to be harmful to end users. Bitcoin has two properties that general computer applications do not have: the blockchain and what is executed on it must be fully verified by all users running a full node, and the full progress of the system is secured by financial incentives that must remain balanced. Beyond these additional considerations, a script, like any other programming language, should include any primitives that allow developers to build things that are useful to users that cannot be combined in ways that harm users.
All the talk about soft forks of adding covenants (new primitives), at least in the public arena, has turned into ridiculous demands about what they will be used for. This is not possible to do, nor is it the important thing to focus on. What will be built using the script is incidental to risks that need to be analyzed, and how the built objects interact with the base class is the main risk. What costs will you charge, and how can they be restricted? (This is a big part of Rusty’s great text recovery proposal.) How might these costs to the base layer distort incentives? This is a big part of the risk of MEV.
These questions can be analyzed without focusing obsessively on everything that can be built primitively. Primitives in the base layer can be limited in terms of verification cost and complexity. More importantly, in terms of incentives, what the new primitives enable is comparable to things that can already be built today. If new primitives simply improved the trust model of end-users of systems that can already be built and that have an impact on the system’s incentives, without appreciably worsening their impact on those incentives, there would be no real new risk.
These conversations need to start focusing on what really matters, i.e. new functionality versus harm to the end user. They have almost completely derailed, again in the public arena, rather than in technical circles, into an argument about whether or not end users should be allowed to do things. This is not the conversation that matters. What matters is providing valuable functionality to end users without causing harmful consequences.
People need to focus on the primitives, not on the wild geese they hear in the distance.
This article is a takes. The opinions expressed are entirely those of the author and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.