Hacker News Reader

Comment by apatters | Hacker News Reader

It seems that these problems fundamentally boil down to there being a very small number of people (the five Bitcoin Core developers) who control the destiny of Bitcoin, and who don't represent users of the currency at large.

For a currency which purports to be open, transparent, and free from institutional control, this seems like a huge deficiency. Consider that the Federal Reserve's Board of Governors has seven members, all of whom possess decades of experience in fiscal policy, are nominated by the President, and are confirmed by the Senate. These are experts in the field who are selected by a nominally democratic process.

And Bitcoin wants to replace this with five random devs that most of us have never heard of?

I'm hardly a fan of the Federal Reserve or the US monetary system. But how exactly is Bitcoin offering a more transparent, open, and democratic currency when it can be hijacked by five people?

View on HN

Well, Bitcoin is even less democratic than that - all of the rules were set by only one person, Satoshi Nakamoto. Bitcoin Core has since added additional constraints (which get voted on by miners), but has only in one case ever relaxed any constraints (a fix to a database bug, which was universally uncontroversial).

Bitcoin Core is really more of a process and a community than it is any specific group of people. There's no set criteria for "being a Core dev" - it is simply the set of people who discuss on the mailing list, send patches to GitHub and participate in the consensus-building process. In my experience, the influence of community members grows organically based on technical competency, domain expertise, track record and personal trust relations between community members - not on some appeal to authority or an organized hierarchical power structure.

The decision making process is based on an IETF-like[0] consensus-driven approach, where a very high threshold of rough consensus within the technical community is required for making changes to the protocol. This hardens the protocol rules and helps protect the development process from hasty decisions, political forces and tyranny of the majority situations - with the price of a slower development process and reduced innovation. Overall, I personally think that stability and resistant to change are good things, and prefer to be wrong on the side of defaulting to no-op when there's no consensus, rather than be wrong on the side of making harmful changes.

[0] "We reject kings, presidents and voting. We believe in rough consensus and running code" -- David Clark, The Tao of IETF https://www.ietf.org/tao.html

Based on several years (well, ok, decades; happy birthday, me) experience, I no longer believe in rough consensus.

The people who have the power to merge patches have de-facto veto power over any community.

If the people entrusted with gauging consensus among the technical community and merging non-controversial patches only would show signs of bad faith or try to undermine the open consensus-driven process, the ecosystem would displace them with a new set of maintainers.

You have to remember that at the end of the day, Bitcoin Core is only able to write code and propose it for adoption by the wider ecosystem. The only code that matters in practice is the one being ran by network nodes. As we're seeing with Classic/XT/Unlimited today, competing teams can indeed emerge and try to build community support to alternative protocols.

There are much more than five Bitcoin Core developers.

Reply on news.ycombinator.com