Satoshi Nakamoto Made a Bunch of Mistakes

Introduction

Bitcoin is a great invention, and some of us have been heavily influenced by it, and it will never be forgotten. Unfortunately, due primarily to the maximum block size, Bitcoin is not useful, and instead has become merely a religion based on arbitrary technical parameters.

Satoshi Nakamoto made some brilliant decisions, but he also made a bunch of mistakes. By leaving the project in 2011, with no one in a position to make decisions in his absence, it has become impossible to move forward with Bitcoin. Fortunately, it is possible to learn from these mistakes and do better with a new blockchain.

What’s Great About Bitcoin?

This article is not designed to insult Bitcoin or Satoshi Nakamoto. Bitcoin’s ideas have been very influential, and I remain convinced that these ideas will become mainstream in the future.

Bitcoin’s greatest influence can be summarized as:

Proving that digital cash can work in the real world without a trusted central authority.
Giving us “Nakamoto consensus,” which is consensus based on proof-of-work, which is now very common in the cryptocurrency industry.
For giving us the transaction structure with multiple inputs and outputs with a predicate inside (“Script”) which is now very common in the cryptocurrency industry.

This list is not comprehensive. Other articles and books have sung the virtues of Bitcoin. However, in this article I want to chart out some of the mistakes with Bitcoin, so that we can learn from them and do better in the future.

Mistake 1: Maximum Block Size

The maximum block size is famous. There was a war in 2017 over whether the maximum block size would or would not be removed, and the result is that it was not removed. This means transaction volume hit a cap in 2017 and has not increased since then.

Some argue the Lightning Network, or some other “L2”, will enable Bitcoin to scale. But these solutions have fundamental issues, including:

In order for someone to open a channel to a new user, they must fund the channel with more money than they send. This increases the difficulty of onboarding, which is already one of the biggest problems.
The 1 MB block size is not big enough (by a factor of 1000+) even if an L2 is widely adopted to be a mainstream payment system.
Everyone who runs an L2 node is (arguably) a money transmitter, with a far higher regulatory burden than running a Bitcoin node.

This is not a comprehensive list of the faults of L2. The biggest fault is easily observed: L2 has been discussed for at least 10 years, and arguably the entire history of Bitcoin (“payment channels”), but has never been proven to work reliably with users. Anyone who researches L2 will quickly discover this obvious fact that L2 has simply failed in the real world.

Mistake 2: Leaving the Project

By adding in the maximum block size, and then leaving, Satoshi Nakamoto left a leadership gap that no one else was ever able to fill. Thus, it has proven impossible to make any changes to the consensus protocol of Bitcoin. Again, some proponents think this is a virtue (“it’s decentralized!”), but to those of us building applications, it is a fatal flaw. Bitcoin simply cannot be used for anything other than speculation and there is no one with enough authority over the project to change that. If no one takes a leadership role and commands an increase to the maximum block size (“exactly this amount, on exactly this schedule”), then Bitcoin will continue to be useless for applications. Such commanding leadership seems all but impossible given the current culture of Bitcoin.

Mistake 3: Encoding Errors

The maximum block size and lack of leadership are not the only mistakes. Off the top of my head, I can think of several encoding issues that would not have been made if Bitcoin were designed today.

Bitcoin used little endian instead of big endian, and, relatedly, arbitrarily reversed hashes when displayed, which are mistakes no experienced network engineer would ever make. These decisions simply lead to bugs for developers and have no added benefit. Bitcoin should have used big endian encoding like every other network protocol.
Signatures and public keys originally had multiple encodings, which enables transaction malleability. They should only have one fixed, minimal encoding.
Variable sized integers also had multiple encodings and should also only tolerate fixed minimal encodings.
Scripts also had multiple encodings, which left insufficient room for the last pushdata, and should also only have one fixed, minimal encoding.

Mistake 4: Change Fees

Bitcoin has “transaction fees”, which I think are better called “change fees”, where if the inputs add up to more than the outputs, the remainder is a fee paid to whoever mines that transaction. This is not a good way to pay mines, for the following reasons:

It means the user does not have a relationship with the mine, as would normally be the case in any business relationship. The user pays a random mine, forcing all mines to be a commodity and making it impossible for mines to create added value.
It means fees are unpredictable, complicating the user experience.
It complicates the algorithm for building a transaction, which is annoying for developers and sometimes users.
It has led to the current “fee market” where transaction fees are outrageously high.

The solution is simple: Instead of putting a fee in a transaction that goes to a random mine, the user should sign up with a mine (or a wallet who does this on their behalf, like any economic supply chain) and pay a fee directly to that mine. This would make fees predictable and would allow mines to create added value for users because the users know who the mine is.

Presumably Satoshi wanted mines to be anonymous and thus he included no information designed to identify mines in the protocol. But mines can’t be anonymous in practice because they are discoverable through network analysis. It would be more helpful to have identifying information about the mine in the protocol so they can communicate with each other and to users and so that users can develop relationships with good mines.

Mistake 5: Slow Transactions and Reorgs

Bitcoin seems to have been designed for instant, irreversible transactions. That is how the original software was designed and operated. Unfortunately, that has changed over time due to the presence of the maximum block size. Today, nodes allow “replace by fee”, meaning transactions are not reliable until they are confirmed. In fact, thanks to the presence of reorgs, transactions must be confirmed multiple times to be reliable. This means transactions are extremely slow. They are also expensive (unpredictably so). This is a death knell to all applications except speculation.

These problems could be easily fixed with small changes. That can be done on other blockchains, or on Bitcoin if only someone with enough authority could get the change through:

Put a domain name in each block so that mines can communicate authentically.
Have mines vote on each transaction and each block after they are validated.
After the vote passes, from known recent mines, the transactions are as good as confirmed.
Do the same thing with blocks.

This would allow for instant transactions and would only require small technical changes to the Bitcoin protocol. It would also make reorgs impossible, simplifying all application development. Unfortunately, because this was not thought of in advance, and there is no one in position to change Bitcoin, it is impossible to make these changes.

Conclusion

Bitcoin is a remarkable invention that deserves a place in the history books. Unfortunately, it simply is not useful in its current configuration. The maximum block size is the most fatal issue, but there are other issues as well.

I see no path forward other than to create a new blockchain that is free from these errors. In summary, the changes needed are:

Governance changes: Bridge authority and leadership with decentralization. The best role model here is the internet. The internet is mostly decentralized, with some centralized aspects, and has proven to be useful and to scale. The path forward is with permissionless protocols, businesses who profit, and non-profit organizations with the authority to make decisions that affect all businesses and users, so that things can change when needed.
Technical changes: Make the technical changes to the protocol necessary to have: Unlimited room to grow, instant transactions, low fees, and have the capacity to make other changes that might only become apparent with time.