3 ms·
This misrepresents the tight interlock between client and specification. Suppose that there is a flaw discovered in Bitcoin that requires a protocol change. In
by ezyang 15y ago
This misrepresents the tight interlock between client and specification.
Suppose that there is a flaw discovered in Bitcoin that requires a protocol change. In a classic software system, the worst you'd have to worry about is a backwards incompatible protocol change; Bitcoin is designed with very little wriggle room in this respect. But furthermore, with Bitcoin, you have to worry about a change which existing Bitcoin clients will reject: for example, if you wanted to increase the reward given to miners.
You can fork the protocol, but you can't fork the economy. This is true in normal projects, and doubly true for Bitcoin.
- weavejester 15y agoI'm not sure I understand your point. Yes, in order for a Bitcoin fork to succeed, you'd have to convince the majority of clients to use the new protocol. However, once you gained a majority, the Bitcoins generated by the old protocol would fall in value relative to the Bitcoins generated with the new protocol. If your Bitcoins are worth $100 using the new protocol, but only $50 using the old protocol, there's a strong financial incentive to start using the new client so you can sell your bitcoins at a higher rate and to a larger audience.
- ezyang 15y agoYes. I argue this "convincing" process is at the very least a centralized process, and at the worst deeply problematic.
- weavejester 15y agoYes, it's centralised (to a degree), but when people talk about decentralised protocols, they usually mean that the protocol itself is decentralised. There's still usually an official or de-facto standard maintained by a relatively small group of people. Your argument that Bitcoin is not decentralised could easily be applied to any P2P protocol. I don't think there's any P2P system around, except perhaps natural language, which has a decentralised specification.