Everything built on bitcoin that you know today is due to the primitives that bitcoin Script supports. What do I mean by primitive? The basic components of a programming language that you can use to create real applications to do things. No programming language was ever designed specifically for a single application, that is, for building a program. They are designed to support basic primitives, such as mathematical operations to manipulate data, or creating basic data structures to store data in a certain way, or operations to iterate through data while manipulating it.
Basic primitives are designed in such a way that developers can decide how to use them to create a real application or program. The core design of the language isn't necessarily focused on what people will do with it, it's just that the language's primitives can't be combined in a way that 1) doesn't achieve what the developer is trying to achieve without them understanding why, or 2) achieve what the developer is trying to do in a way that is harmful to the end user.
No one designs a programming language thinking from the beginning: “Oh, we want to allow developers to do A, B, and C, but completely prevent them from doing x, Y, and Z.” (For more technical readers, I'm referring to the goal of what the developer is building, not low-level technical details like how primitives are combined.)
bitcoin Script is no different from other programming languages except in one respect: meaning that a certain combination of primitives is harmful to end users. bitcoin has two properties that general computing applications do not have: the blockchain and what runs on it must be fully verified by all users running a full node, and all progression of the system is ensured by financial incentives that must stay in balance. Aside from these additional considerations, Script is like any other programming language: it must include primitives that allow developers to create things useful to users that cannot be combined in ways that are harmful to users.
All the talk about softforks adding conventions (new primitives) has degenerated, at least in the public sphere, into ridiculous demands about what they will be used for. This is not something possible to do and it is also not something important to focus on. What will be built with Script is tangential to the risks that must be analyzed; the way the built things interact with the base layer is the biggest risk. What costs will it impose and how can they be limited? (This is a big part of Rusty's Great Script Restoration proposal.) How can those costs at the base layer skew incentives? This is a big part of the risk of MEV.
These questions can be analyzed without obsessively focusing on everything possible that can be built with a primitive. Primitives may be limited at the base layer in terms of cost and verification complexity. Most importantly, in terms of incentives, what the new primitives allow can be compared to things that are already possible to build today. If the new primitives simply improve the trust model for end users of systems that can already be built and who have influence on the incentives of the system, without materially worsening the influence they have on those incentives, then no real new risk is introduced.
These conversations need to start focusing on what really matters: new features versus harm to the end user. They have almost completely derailed, again in the public sphere, not in technical circles, in discussions about whether end users should be allowed to do things or not. That's not the conversation that matters. What matters is providing valuable functionality to end users without creating harmful consequences.
People need to focus on the primitives and not the wild geese they hear in the distance.
This article is a Carry. The opinions expressed are entirely those of the author and do not necessarily reflect those of btc Inc or bitcoin Magazine.
