Bitcoin _: Focus On The Building Blocks, Not The Wild Geese

Everything built on top of Bitcoin that you are aware of today is because of the primitives that Bitcoin supports. 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 was ever designed specifically for a single application, i.e. to build one program. They are designed to support basic primitives, like mathematical operations to manipulate data, or creating basic data structures to store data in a certain way, or operations to iterate through data as you manipulate it.

Basic primitives are designed in such a way that developers can decide how to use them in order to create an actual application or program. The core design of the language doesn’t necessarily focus on what people will do with it, just that the primitives of the language can’t be combined in a way that will either 1) fail to accomplish what the developer is trying to accomplish without them understanding why, or 2) accomplish what the developer is trying to do in a way that is detrimental to the end user.

No one designs a programming language thinking from the outset “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 goal of what the developer is building, not low level technical details like how primitives are combined).

Bitcoin is no different than other programming languages except in one respect, what it means for a certain combination of primitives to be detrimental to end users. Bitcoin has two properties that general computer applications don’t, the blockchain and what is uted on it must be fully verified by all users running a full node, and the entire progression of the is secured by financial incentives that must remain in balance. Other than these extra considerations, is like any other programming language, it should include any primitives that allow developers to build useful things for users that cannot be combined in ways that are detrimental to users.

All of the conversations around softforks to add covenants (new primitives) have devolved, at least in the public square, to ridiculous demands of what they will be used for. That is both not a possible thing to do, and also not the important thing to focus on. What will be built with is tangential to the risks that need to be analyzed, how things built interact with the base layer is the major risk. What costs will it impose, and how can those be constrained? (This is a huge part of the Great Restoration proposal from Rusty). How can those costs on the base layer skew incentives? This is a big part of the risk of MEV.

These questions can be analyzed without focusing obsessively over every possible thing that can be built with a primitive. Primitives can be constrained at the base layer in terms of verification cost and complexity. Most importantly, in terms of incentives, what new primitives enable can be compared with things that are already possible to build today. If new primitives simply improve the trust model for end users of s that can already be built that have an influence on the incentives, without materially worsening the influence they have on those incentives, then there is no real new risk introduced.

These conversations need to start focusing on what really matters, new functionality versus end user harm. They have derailed almost completely, again in the public square, not technical circles, into arguments over whether end users should be allowed to do things or not. That is not the conversation that matters. What matters is providing valuable functionality to end users without creating detrimental consequences.

People need to focus on the primitives, and not the wild geese they hear in the distance

This article is a Take*. Opinions expressed are entirely the author’s and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.*