Comment by hudon | Hacker News Reader

Comment by hudon | Hacker News Reader

It wasn't the last time that centralized decision-making saved the day. Another incident that is worth reading about if Bitcoin failures interest you is the 2013 Bitcoin fork: https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-...

Basically, a new version of Bitcoin Core software was released (v0.8) and only part of the network was running it. Then a block caused a divergence, where folks running v0.8 started mining on top of a different chain than the one mined by folks on v0.7. Amidst the chaos, 2 developers (Luke DashJr and Pieter Wuille), decided that miners should rollback to v0.7 and mine on top of the "v0.7" chain. Miners and other devs quickly fell in line.

One lesson gleaned from these two incidents (featured article and this one) is that centralized problem-solving clearly made these events less catastrophic than they would otherwise have been. If in 2013 there had been no leader to advise the crowd which chain Bitcoin should be, the divergence may have been permanent. And then people wonder why nowadays Bitcoin keeps forking, when history shows that strong leadership prevents persistent forks. A persistent chain fork is not a technical failure, it is a leadership failure.

Which raises the question: If strong leadership is needed to define the meta-consensus, what use is it that the technical consensus is decentralized?

Not sure if this is entirely right but I think technical decentralization depends on its participants making conscious decisions to react to events, but that doesn't happen and somehow you need to assign higher weight (centralization) to certain participants (core developers) to correct a few things.

Don't "hard" changes require network consensus to be enacted?

As in if every one who uses bitcoin decided that changes suggested by leadership are wrong, and not in the best interest of the network, they choose not to update their client or they don't verify transactions containing the change?

It takes for core developers years of great and conservative technical leadership to get to the point where I would trust them on the few points where a quick decision is needed. For example I'm glad that Luke came up with the idea of the segwit soft fork, but I will never forget his messing with Bitcoin Gentoo packages.

Technical consensus provides an important backup / tie-breaker when meta-consensus isn't clear.

This has happened multiple times in the past with Bitcoin, most recently with Bitcoin Cash vs. Bitcoin Core. The user-base is split, there is lots of propaganda on both sides. However the technical consensus yields a single chain (Bitcoin Core).

Actually there were 2 persistent bitcoin chains to emerge from that conflict, one led by Bitcoin Core’s consensus rules and one led by Bitcoin Cash’s consensus rules. Nothing technical prevented the fork. And to claim one is more “bitcoin” than the other is moot. In fact the argument of which bitcoin chain is what Satoshi would have wanted is still being argued about every single day...

True both are still around, but a user can simply choose the fork with the longest chain (most PoW).

This is important because all other metrics such as choosing based on message boards, market cap, etc. can be more easily gamed.

there can be no immediate decentralisation the way you want to put it. The moment an OSS system is being implemented there is a main contributor and a core team of devs. It would take years for a system to be completely independent. Bitcoin is approaching towards this goal. But to think that decentralisation is useless because the devs along with the miners and users decided by consensus that a bug was indeed a bug is the wrong approach.

Reply on news.ycombinator.com