One thousand sats to each of the best answers where best means treating the question asker with respect and providing a nuanced and factual layout of the relevant game theory. Many of us have answered this question for ourselves, but if someone could have answered this question for you, what answer would you have wished to hear?
A friend DM'd me:
Are the bitcoin network maintainers (Wladimir van der Laan + Pieter Wuille, Marco Falke, Michael Ford, Jonas Schnelli and Samuel Dobson) a common topic in bitcoin convos? Specifically is that group's influence viewed as a network risk since they kind of represent a centralized power to the network?
I have my own response to these questions, but I thought we all would collectively provide a more exhaustive answer and build a repository of answers for future-coiners.
1,000 sats paid 7 times
k00b's bounties
To me it plays out like this gif, exchanges, devs, wallets, users etc... everyone happy :)
Until someone does something new, then the guns go up.
If the change is good for bitcoin the guns go down, we laugh it off (guns in hand)
If it's bad for bitcoin...someone's getting shot, and someone new will take their place
reply
I wouldn't say better. There's nothing better than a meme.
reply
Short answer: Yes.
Realistic answer: Still safer than most 99% (possibly 100%), most non-open-source projects.
The whole infrastructure around Bitcoin makes it difficult to bypass the "core idea".
Let's compare.... It is easier to fool the end user when everyone knows the code or in a closed project where only de devs know what are they doing?
If you are worried about centralization on Bitcoin... Well, I got bad news about everything else...
reply
It is harder to fool the end-user when everyone can see the code. I'm not worried about the centralization of Bitcoin right now, but I might be in the future :). The most important thing is to keep moving towards maximum decentralization, if that's possible. I don't know if this is the US saying, but the saying here is 'The road is made by walking'
reply
deleted by author
reply
deleted by author
reply
This isn't discussed much that I've ever seen.
The devs are not normally considered a risk because people in the btc community over-index on the technical structures in the ecosystem, and under-index on the social structures. What gets merged in the code is the result of human judgment, and judgment is a social product. The opinions we all have are the result of social processes.
The mantra of DYOR ignores the fact that the R comes from someplace -- it comes from the ideas that are laying around. So which ideas are lying around? In many cases they come from idea intermediaries, since people are famously reluctant to think for themselves.
I think this means that, while exerting significant influence over core development is a kind of quasi-centralization risk, the nature of the 'risk' is worth thinking about. Specifically, it's hard to decouple 'risk' from 'influence' and as social primates, we will never be free from influence.
reply
The biggest threat to Bitcoin is capture dev capture. Done right you won't make changes to the code that people disagree with immediately. You will make small, incremental changes that seem insignificant in the grand scheme. Shift the overton window, boil the frogs.
Ultimately the rules of the network are underpinned by social consensus, and there has been no point in history where mass social consent is invulnerable to manipulation. Being aware of this is critical to defending Bitcoin over the span of decades to hundreds of years.
reply
This is a good point but based on your comment it sounds like we (plebs) are the weak point of attack, not the devs. IE us not putting pressure on devs. The users of bitcoin not being diligent. Which is a good point.
reply
No one is more aware of the centralization risk than Bitcoin Core developers themselves. The project as a whole takes regular actions to distribute and minimize this risk and has been doing so ever since Satoshi vanished.
Lead maintainer Wladimir van der Laan retired recently[^1]. They are not replacing him with a new "lead maintainer", instead opting to operate in a leaderless fashion going forward. Pieter Wuille has also distanced himself from the perception that he is a leader among Bitcoin Core developers, going so far as to remove himself as a maintainer.[^2] Even in the realm of release signing the Bitcoin Core project has moved in a direction of greater decentralization, removing the static list of release signers in favor of a rotating cast of characters[^3].
Accusing "Bitcoin Core" of being a centralized group is a bit of a reach, in my opinion. Several contributors come to mind as contentious figures who rub a lot of other contributors the wrong way. I will not name them but ask anyone who follows Bitcoin Core and they can certainly corroborate this characterization. These figures are not ostracized or excluded from contributing to the protocol or mailing list, their contributions are merged and help to make bitcoin stronger, just as all contributors do.
I think there are many more and far larger threats to bitcoin than the developers. Between frivolous lawsuits, hostile legal regimes, and regulatory protocol capture I don't ever lose sleep that the developers themselves will materially harm the project.
reply
My lovely wife had this same question a while back. Its a sign of thinking more deeply about bitcoin and incentives.
The short answer is yes, they are a risk. There are many risks besides this one but this is a good one to think about.
The bitcoin core maintainers could go rogue or just change the project in some way that I do not like. We have seen how this plays out. The block size wars were an example of an effort to change the code. It resulted in a code fork to a new project. That project has largely failed in its goal to gain dominance. Why? Because people that run nodes chose to stay with the small block version of bitcoin. Node operators choose which release to run. Node operators are a check on the power of the maintainers and you can see that the maintainers are aware of this with how they take time to consider changes.
Lets talk about incentives. Are maintainers incentivized to make unpopular changes? No. If they have significant bags they will lose value if they increase distrust in the network by doing something shady. I believe this is a huge reason why bitcoin is so resistant to changes.
Lets say that some state actor gets control over one or a few maintainers. They get them to do something shady. Well, unless we get lazy and don't review the code as a community that could be a huge issue. I do think this is unlikely. We see open source projects getting slammed for code changes that have far less impact than bitcoin. If a coder were to do something sly to the code base I believe it would get called out very quickly. There are far to many developers who are incentivized to defend their wealth. A state actor would need to have leverage on a large number of devs, not just maintainers. I do not believe any state actor is this driven or organized. These same states can't stop much weaker actors doing things they don't like. I really think this is NOT the way to attack bitcoin
I believe the way states will attack bitcoin is at the edges. Attacking users by criminalizing our behavior. They may go after maintainers but I don't think they will try to mod the code. I think it is more likely they try to make contributing risky and impossible to do without anonymity. The good news is that I don't think this will happen in all states at the same time. If the US tries to do this their adversaries will be incentivized to support or at least "allow" bitcoin development and usage.
IMO the greatest risk to bitcoin is us. The plebs. We can't be weak, scared, or dumb. We have to remain vigilant and determined to be free. Not just for ourselves but for our descendants. These days I almost exclusively talk to younger people about bitcoin vs. people my age and older. I'm in my 40s. Younger folks seem to be much more open to the ideas and they will benefit from bitcoin more than we will.
reply
Let's assume the worst case scenario: 100% of all current contributers to Bitcoin Core (hereafter Core) has been convinced by some government to try to subvert Bitcoin. This means that all future releases of Core would have some sort of a malicious changes to it.
First, most nodes are running old versions of Core. Subverting future releases of Core could only affect new nodes/users. And new nodes/users could easily run old versions of Core, which woudl happen the instant the subversion were discovered.
Second, the most useful subversions are the most likely to be found. For instance, if a new release of Core would send some of a user's BTC to a government-controlled address, then that would become visible within hours of being released. Users would complain on Github, Reddit, Twitter, Facebook, Stacker News, IRC, Nostr, and many other places.
Third, for any subversions to work, they must be kept hidden. And hiding bugs in an open source project only works if people don't care about the project. Core's development affects people's livelihoods and fortuntes, so a lot of people are scouring it's code for bugs. Moreover, those seeking to steal BTC look for code to exploit. If a backdoor were added to Core, it would be taken advantage of quickly, thus exposing the subversion.
Fourth, if the subversion(s) were discovered, the Core devs would be treated like criminals forever. And others would scour the Core source code to find any possible subversions. It would be somewhat like when the OpenBSD devs started LibreSSL, because OpenSSL had made too many mistakes over the years -- except the OpenSSL devs weren't obviously beig malicious.
Fifth, the changes that the Core devs can actually make to Bitcoin itself are quite small. Soft-forks and hard forks only affect new versions of Bitcoin Core. The rest of the old versions of Core would not follow either.
Sixth, mining pool companies care a great deal about the integrity of Bitcoin. They will not risk losing customers (i.e. the people with mining hardware) by going along with a hard fork created by Core devs.
Finally, consumers (i.e. individuals spending their own money) are the ultimate deciding factor. When a hard fork occurs, consumers will buy one one side of the fork and sell on the other side of the fork. The miners/pools will mine on the side that has the highest price (presumably after a few days). Fortunately, a lot of consumers don't even hear about hard forks until long after one side has been abandoned. For a hard fork to be successful, there must already be a culture of users constantly updating to the latest version (like Monero). Bitcoin users tend to run old versions of Bitcoin Core.
If you need clarification on any of the above, let me know. Corrections are also welcome.
reply
Here's my answer: This isn't a common topic in the Bitcoin community. It's a fundamental issue that could be discussed more. But people who know about this topic know that hundreds of developers contribute to Bitcoin Core. One of the maintainers' jobs, who have the GitHub keys, is to update Bitcoin Core with proposed changes. I think this topic isn't debated more because miners and full node operators only update Bitcoin Core if they want to. So, if the maintainers make a shit, the miners and full node operators have the final say.
reply
My answer if I received the DM:
No it is not a common topic in conversations for me. Much like how I don't know or talk about the authors and maintainers of TCP/IP, POTS, or SMTP.
These are very useful protocols that I use every minute of every day but it is just part of the Technology stack for me.
reply
Bitcoin Core is overrated. I mean it's great, and it deserves a lot of praise, and the people working on it are super geniuses... But it's overrated in the sense that a lot of people mistakenly think that Core is essential to Bitcoin. It isn't. It's just one implementation of the Bitcoin protocol. There are competing implementations to Core... I think Luke maintains one called BitcoinKnots. There's also at least 2 implementations in Rust.
If the individual developers working on Core go off the reservation and start acting against the best interest of Bitcoin, people will just switch to another Bitcoin implementation... And by "switch" I mean both node runners will switch and also the funding and grants will move.
Anyways, that's my 2 sats.
reply
I think Luke maintains one called BitcoinKnots. There's also at least 2 implementations in Rust.
A very important difference between Luke's Knots and the Rust implementations is that Knots shares all the same consensus-related source code with Bitcoin Core. The Rust implementations are total rewrites. Threre's a long, long, history of people attempting to rewrite Bitcoin Core in other languages and failing. Computer science just isn't ready to get the levels of compatibility necessary between code bases necessary for Bitcoin to function.
This means that while Knots is a potential alternative to Core, the Rust implementations (and all other rewrites) just aren't. If miners started using them, we'd get massive consensus failures.
reply
Fair enough. Yeah maybe my previous post was too hand-wavy... AFAIK there is no implementation with bitwise symmetry to Core's consensus.
I guess if Core went rogue there would be disruption to global consensus, but my overall point is that theoretically there's nothing that stops everyone from abandoning core and migrating to an existing or a new alternative in the future.
I think there's even compelling reasons why Core should be abandoned in the future for a memory safe alternative like a rust implementation because of security reasons alone. I think ~30%+ of CVEs are memory safety issues, which a Rust implementation (with its own consensus engine) would be immune to by default.
reply
Bitcoin Core has a good track record with memory safety. So its not clear that Rust would be worth the risk of consensus failures in this case. But maybe. Certainly if you are going to take the risk, Rust would be maybe the only language worth switching to from C++.
reply
deleted by author
reply
It may be brought up but at the end of the day they can propose as many changes as they want. It doesn't mean anyone has to enforce those rules in consensus. My node=my rules=my interests. Combined with the protocol being open source, anyone can develop & code onto the network. But if the incentive isn't there then no harm no foul. Its almost easier for the US Congress to balance a budget than it is to get bitcoiners to agree to change the network. Just my opinion
reply
It's worth reflecting that Bitcoin has historically had this problem, and dealt with it: Singularly with Gavin Andresen - Satoshi's chosen successor - having his commit rights taken off him; and collectively with big-block developers going elsewhere.
reply
I used to think a lot about that and I think it is a risk because they can get paid to force a malicious change or steal, but now I think people should run their own node and reject anything stupid that's being proposed and never trust anybody. Bitcoin is perfect, I know that will put me on the ossify camp but I think that's the right choice, this is my opinion and I could be wrong
reply
First, bitcoin is decentralized, no one knows the identity of the person who created it. No one in particular controls bitcoin. This group has nothing to do with the evolution or otherwise of bitcoin, bitcoin is made to evolve over time.
reply
They have to reach a consensus before any action is taken so NO
reply
The core devs are not a centralization risk because they're only a part of the network comprising the Bitcoin consensus (agreement between people on a fixed set of rules). They can influence or make changes as much as they want but that doesn't mean the other parts of the network will go along.
reply
If software 1 is the only software used in the network (or used by the very large majority of the nodes) and whatever decision its developers make ends up being run by the nodes, then the answer is Yes.
The trick here is to be sure there are multiple implementations and all progress in the network rules is achieved by rough consensus (you will never please everyone) between developers, validating nodes and miners.
Miners and nodes can always reject to upgrade to newer versions, but if there's no alternative software that they can rely on, progress will stall. The open-source nature of the Bitcoin Core code helps mitigate this risk.
reply
More people running alternative patched versions of Core, like Bitcoin Knots, reduces that centralization risk.
reply