“Mauro, shut up! It's a kernel bug. How long have you been a maintainer? And you *still* haven't learned the first rule of kernel maintenance? If a change causes user programs to crash, it's a kernel bug. We never blame user programs. How hard it is to understand This? -Linus Torvalds
Doesn't break up user space. This is the golden rule established by Linus Torvald for Linux kernel development. For those of you reading this article who are not familiar with the nature of Linux, or operating systems in general, the kernel is the heart and soul of the operating system. The kernel is what actually manages the hardware, moving bits between storage and RAM, and between RAM and the CPU as it computes things, all the little hardware and bits in the actual computer that need to be controlled over Hardware level.
Every application or program written for an operating system must interact with the kernel. When you download Photoshop or Telegram, all it does is basically call the kernel. “Hey kernel, take what you just wrote, process it, and send it over the network connection to the server.” “Hey kernel, take the color shift you made on this, take it out of RAM, send it to the CPU to tweak it, and then put it back in RAM.”
When the kernel is changed, in a manner somewhat similar to Bitcoin, the main goal of developers is to ensure that existing applications that assume a certain way of interacting with the kernel are not broken by a change in the kernel. Sounds very familiar with Bitcoin and the need to maintain backward compatibility for network consensus upgrades, doesn't it?
“Seriously. How hard is this rule to understand? We especially don't break userspace with TOTAL CRAP. I'm angry, because your entire email was horribly wrong, and the patch that broke things was patently crap. The whole patch is incredibly broken.” It adds a crazy error code (ENOENT), and because it's so crazy, it adds a few places to fix it (“ret == -ENOENT ? -EINVAL : ret”).
The fact that you then try to make *excuses* to break the user space, and blame it on some external software that *used* to work, is shameful. This is not how we work. Fix your Compliance Tool, because it's clearly broken. And fix your approach to kernel programming.” -Linus Torvalds
Linux is one of the most important, if not the most important, open source projects in the entire world. Android runs on Linux, and half (if not more) of the back-end infrastructure runs on Linux. Embedded systems that control all sorts of computerized things in the background of your life that you might not even think about running on Linux. The world literally runs on Linux. It may not have taken over the desktop like many autistic Linux users wanted to see happen, but it quietly ate almost everything else in the background without anyone noticing.
All 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 to allow their applications to continue working. Otherwise, any running applications must continue to use older versions of the kernel or bear the burden of changing their applications to react to the radical change in the kernel.
The most likely path to success for Bitcoin is a very similar one, where it simply becomes a platform on which financial applications and tools are built in such a way that most people using them don't realize or think that “Bitcoin ate the world.” Similarly 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 machine, dramatically changes what it means to “break user space.”
It's not just developers who can hack user space, users themselves can hack user space. The entire past year of BRC-20 arrangements, inscriptions, and tokens should make that clear conclusively. This presents a very serious quandary when looking at the “don't break user space” mantra from a developer's point of view. As much as many Bitcoin users in the industry do not like Ordinals, and are annoyed that their use cases are disrupted by the network traffic generated by Ordinals users, Both groups are users.
How do developers face this problem? One group of users divides user space for another group of users. To make a change that prevents the use of arrangements or patterns explicitly violates the mandates of not breaking the user space. I'm sure people want to say “Taproot broke userspace!” In response to this dilemma, but it did not. Activating Taproot, and allowing witness data to be as large as the entire block size, did not break any pre-existing applications or uses built around Bitcoin. All it did was open the door to new applications and use cases.
So what do we do here? Trying to filter out people making patterns or trading ordinal numbers, or hacking through a consensus change, is a fundamental violation of the “don't break user space” principle. Doing nothing allows one class of users to break into the user space of another class of users. There is no fundamental solution to this problem other than violating the Golden Rule, or implementing a function that allows the class of users whose user space is now broken to adapt to the new realities of the network and maintain a viable copy of their applications and use cases.
Not infiltrating Bitcoin's user space is crucial to its continued success and functionality, but it's not as simple as “don't change anything.” Dynamic changes in user behavior, which do not require any change in the actual protocol itself, can have the same impact at the end of the day as a radical change in the protocol. Are developers supposed to pick and choose the user space of broken apps to preserve another app's user space? I would say no, and I would go so far as to say that anyone calling for such behavior from developers is asking them to act irresponsibly and in a way that harms system users. So what is the answer here?
There is no solution but to move forward and continue adding improvements to the protocol that allow applications that crash due to the behavior of some users to work in the presence of emergency changes in user behavior. Otherwise, you're asking developers to ditch the golden rule and actively play with the kingmakers in terms of viable use cases based on Bitcoin.
If we go that route, what are we actually doing here? I can't tell you what we're doing at this point, but I can tell you that we're not building a distributed, neutral system anymore.
