Don’t break user space!

“Mauro, shut up! It’s a bug in the kernel. It’s okay. How long have you been an administrator? And you *still* haven’t learned the first rule of kernel maintenance? If the change causes the user program to crash, it is a bug in the kernel. We never blame user programs. How difficult can it be to understand this?” -Linus Torvalds

Don’t destroy user space. This is Linus Torvald’s golden rule for Linux kernel development. For those of you reading this who are unfamiliar with the specifics of Linux or operating systems in general, the kernel is the heart and soul of the operating system. The kernel actually manages the hardware, performs computing tasks by moving bits between storage and RAM, between RAM and CPU, and manages all the little devices and parts of the physical computer that need to be controlled at the hardware level.

Any application or program written for an operating system must interact with the kernel. When you download Photoshop or Telegram, everything the program does essentially boils down to a kernel call. “Kernel, please process what I just entered and send it to the server over the network connection.” “Kernel, please take the color changes I applied to this pitch out of RAM, send them to the CPU for modification, and then put them back in RAM.”

In a somewhat similar way to Bitcoin, when the kernel changes, the developer’s main goal is to ensure that existing applications that assume a particular way of interacting with the kernel are not broken by the kernel change. Doesn’t Bitcoin and the need to maintain backward compatibility for network consensus upgrades sound very familiar?

“Seriously. How hard is it to understand these rules? We especially don’t compromise user space with TOTAL CRAP. Your entire email is so _horribly_ wrong, and I’m angry because the patch that caused the problem was such garbage .The whole patch is hugely broken – they add a crazy error code (ENOENT), and then add a few places to fix it because it’s so weird (“ret == -ENOENT ? -EINVAL : ret”).

It’s a shame that they then try to make an *excuse* for breaking userspace and blame some external program *used* to make it work. That’s not how we work. Fix your damn “compliance tools.” Because it’s obviously broken. And modify your approach to kernel programming.” -Linus Torvalds

Linux is one of the most important, if not the most important open source projects in the world. Android runs on Linux, and half (if not more) of its backend infrastructure runs on Linux. Embedded systems that control all kinds of computerized things in the background of your life aren’t even considered running on Linux. The world literally runs on Linux. While it didn’t take over the desktop like many autistic Linux users would have liked, it quietly ate up almost everything in the background without anyone noticing.

All of these applications and programs that people use in their daily lives rely on the assumption that Linux kernel developers will not break backwards compatibility in new versions of the kernel so that the applications can continue to work. Otherwise, running applications will either have to continue using an older version of the kernel or bear the burden of changing the application to interact with breaking changes in the kernel.

The path most likely to succeed for Bitcoin is a very similar path. It will simply become a platform built on top of financial applications and tools that most people who use it will not realize or even consider that “Bitcoin ate the world.” In a similar vein to Linux, the golden rule of “don’t break user space” applies tenfold. The problem is that the nature of Bitcoin as a distributed consensus system rather than a single local kernel running on one person’s computer significantly changes what “user space destruction” means.

It’s not just developers who can break user space, users themselves can break user space. The entire final year of Ordinals, Inscriptions and BRC-20 tokens should definitely prove this. This presents a very serious challenge from a developer’s perspective, given the mantra “don’t break user space”. Many Bitcoin users in this space do not like Ordinals and are upset that their use cases are being disrupted by the network traffic Ordinals users are generating. Both groups are users.

So how do developers face this problem? One user group is infringing on another user group’s user space. Enacting a change that prohibits the use of ordinal numbers or inscriptions would explicitly violate the command not to break user space. I’m sure people will want to say “Taproot broke userspace!” In response to this dilemma, however, it was not. Enabling Taproot and allowing witness data as large as the entire block size did not break the use of existing applications or those built on top of Bitcoin. All it did was open the door for new applications and use cases.

So what should we do here? When people try and filter consensus changes, such as by creating inscriptions or trading ordinal numbers, it is a fundamental violation of the maxim “don’t break user space”. If you do nothing, one class of users can invade another class’s user space. There is fundamentally no solution to this problem other than implementing features that allow user classes that violate the Golden Rule or have their current user space broken to adapt to the new reality of the network and maintain and use executable versions of their applications. example.

Not violating Bitcoin’s user space is critical to its continued success and functionality, but it’s not as simple as “don’t change anything.” Dynamic changes in user behavior that do not require changes to the actual protocol itself can ultimately have the same effect as disruptive changes to the protocol. Should developers choose which applications’ user space is broken in order to preserve the user space of other applications? I would say no. Furthermore, anyone who defends such behavior by developers is asking them to act in a way that is irresponsible and harmful to users of the system. So what is the answer here?

There is no answer other than continuing to add protocol improvements that allow applications that were broken due to certain user actions to work when there is an urgent change in user behavior. Otherwise, you are effectively asking developers to abandon the golden rule and play kingmaker as to what use cases can be built on top of Bitcoin.

If we go that route, what are we actually doing here? I can’t tell you what we are doing at that point, but I can tell you that we are no longer building a decentralized and neutral system.