In this article, Gwern discusses why Bitcoin is ugly and not elegant. If you think about how computer scientists design things, they prefer to build beautiful and deterministic systems, particularly cryptographers. Cryptography is about symmetrical math and clean code. It’s elegant. And then there is Bitcoin…it’s not elegant enough for a cryptographer nor is it deterministic enough for a computer scientist, but in practice, it still works.
What’s wrong with Bitcoin is that it’s ugly. It is not elegant. It’s clever to define your bitcoin balance as whatever hash tree is longer, has won more races to find a new block, but it’s ugly to make your network’s security depend solely on having more brute-force computing power than your opponents, ugly to need now and in perpetuity at least half the processing power just to avoid double-spending. It’s clever to have a P2P network distributing updated blocks which can be cheaply & independently checked, but there are tons of ugly edge cases which Satoshi has not proven (in the sense that most cryptosystems have security proofs) to be safe and he himself says that what happens will be a coin flip at some points.
Guarantees of Byzantine resilience? Loosely sketched out and left for future work. Incentive-compatible? Well… maybe . Anonymity? Punted on in favor of pseudonymity; maybe someone can add real anonymity later. Guarantees of transactions being finalized? None, the user is just supposed to check their copy of the blockchain. Consistent APIs? Forget about it, there’s not even a standard, it’s all implementation-defined (if you write a client, it’d better be bugward compatibility with Satoshi’s client). Moon math? Nah, it’s basic public-key crypto plus a lot of imperative stack-machine bit-twiddling. Space efficiency? A straightforward blockchain and on-disk storage takes priority over any fancy compression or datastructure schemes. Fast transactions? You can use zero-conf and if that’s not good enough for buying coffee, maybe someone can come up with something using the smart contract features. And so on.
Clearly, the Bitcoin whitepaper is grossly under-specified. There’s not a single mathematical proof in it and a lot was left in the air. Yet, despite all its gaping holes, it seemed to work…
There’s many other examples of “Worse is Better” that I can think of:
- We’re seeing the same thing with Solidity. Solidity is a programming language to build Ethereum smart contracts. It is by far the ugliest programming language you’ve ever used. It is so inefficient and so insecure. But there’s so much developer interest in it (e.g. compared to “better” smart contract languages provided by Tezos, EOS, and other smart contract platforms)
It’s interesting to see how the ugly solution often wins over the more elegant ones. They barely work in the early days. Maybe one of the reasons they win is because they solve a problem at right time in the minimally viable way and win over users, and then becomes impossible to unseat because of network effects and the Lindy effect?
What do you think? Why did Bitcoin succeed despite being ugly? Was it timing? Was it that it solved a real problem? Was it that it was more practical to implement?
[check out this video discussion we had about this topic for more context]