I Can Fix Bitcoin Syndrome

Most so called “shitcoins” get started by a person who thinks “I can fix Bitcoin”. Usually, these people act out of pure hybris and very little understanding. They create a new coin instead of developing on Bitcoin because they do not understand the compromises deliberately taken by Satoshi and the early core devs and think they can do better. What, however, when the “I Can Fix Bitcoin Syndrome” befalls an actual Bitcoin core dev?

The block size wars are a prime example. The most prominent dev saw himself as the heir of Satoshi and assumed that this meant he could dictate Bitcoin’s course. Had he prevailed, then—without hyperbole—the Bitcoin experiment would have failed. Luckily, the vigilant cyber hornets swarmed out and prevented the big blockers from succeeding.

Even if one battle is won, the war is never over. New BIPs are constantly being proposed. Some look promising, some lunatic, but whatever is suggested, whoever suggests it, the duty of toxic maximalists is to scrutinize every proposal and fight most of them.

The point that is so hard to understand about Bitcoin is that it is already very close to a theoretical maximum. Every ledger has a trilemma that cannot be solved, but only compromised on. You must decide if you want to have security, decentralization, or scalability. You can only ever maximize two.

Envision it like building a character in a video game. Every one of the three skills can have a maximum of 21 points allocated, and you can allocate a total of 42 points.

Satoshi Nakamoto chose to give 21 to Security and 21 to Decentralization. Thus, necessarily having awful scalability.

This is a feature, not a bug. Thanks to second layer concepts like Lightning, Liquid, Fedimint and co. Bitcoin can have its cake and eat it too. The main layer has maximum security and decentralization, which are necessary to make it an accurate, reliable money.
The layers built on top can (within certain constraints) reshuffle the points, while not compromising on the layer 1.

Lightning, for example, sacrifices decentralization to enable scalability, while still retaining most of the security, especially the security to not inflate the money supply, which is the No. 1 key issue a money needs to have.

So, whenever someone proposes a new update to Bitcoin’s main layer, you need to ask yourself:

Does it change the tradeoffs?

If it does change the security or decentralization of L1, it must be vehemently rejected.

Even if it doesn’t change the tradeoffs, the next question is:
Is it needed to scale layer 2 to 8 billion users?

On this question, my opinion is that since the taproot update, it has to always be answered “NO”. We have all the necessary tools to scale to 8 billion or even more users. Sure, it may not be convenient for the L2 devs, but out of constraint arises creativity. In the long run, creative workarounds to given constraints often yield better results than working with a blank slate.

Yes, I know it’s tempting to “just have this little update to L1”. But every update is a gigantic risk because it brings with it untold new bug and attack vector risks. Thus, at this point, L1 should be only touched if a bug is discovered, or if the update is necessary to defend against an attack.

If we accept any major changes or new features on L1, they need extraordinary proof of both the necessity and safety. I am currently not aware of a single proposal that meets these criteria.

If all the node runners, stick to this principle, stay vigilant and aggressive, then we have a chance of turning Bitcoin into a real-world Sword of Gryffindor.

For those who are not Harry Potter fans, the Sword is Goblin-made, which gives it the ability to repel everything that could damage it, yet still be absorbing things that strengthen it.

The key fact you need to understand for making this happen is this:

Bitcoin core devs are not our friends.

We may admire them, we may donate to them, but we must never consider them our allies.

The core devs are humans. And even worse, they are software developers. All developers love to tinker and improve code, add new features and remove old ones. So by profession, core devs are not really suitable to be working on Bitcoin. As strange as it may sound, Bitcoin is not an ordinary piece of software, and it should not be treated as one.

Now, since core devs, of course, are the only people who have the skills to fix bugs on bitcoin, we obviously need their work and should reward it. We must, nevertheless, be as critical of their work as a father who is judging the opposing player who just scored a point against his son.

Since we can never precisely know when and which core devs have succumbed to I Can Fix Bitcoin Syndrome, we need to assume they all have and mistrust every single line of code they write.