It's not the Bitcoin Repo, it's the repo of "Bitcoin Core" which is only one implementation of Bitcoin. It is very prominent because it is the direct descendant to the original code by Satoshi Nakamoto.
Unfortunately it is way to prominent in the Bitcoin world to the point where people use it synonymously with "Bitcoin" itself.
reply
Prominent Bitcoiners will proclaim that Bitcoin development is entirely decentralized, but then those same Bitcoiners will viciously attack any competing client thus ensuring that Bitcoin development remains centralized around a single github repo. It's a pretty huge flaw in the system imo. The community should do everything we can to support alternate clients.
reply
Well, the Software on Bitcoin Nodes that doesn't auto update and users actively chose is very much decentralized. And the way BIPs become protocol is very decentralized.
But Bitcoin would be much better if nodes were 1/3 Bitcoin core, 1/3 a Java implementation (Java because lots of programmers are fluent in Java which would be very in the spirit of Bitcoin imo - let's call this imaginary implementation jBitcoin), and 1/3 goBitcoin - an imaginary implementation written in go or something.
reply
I agree with that. Inertia is maybe one of Bitcoins biggest strengths. Nevertheless, there is a subset of miners who will run virtually anything released by Core, with no care for its substance. I would love to see Core try to introduce an obvious but non fatal bug, just to see what percentage of the network would run it. It would be an interesting experiment to see just how much control they actually have over the network, and how many of the miners are actually paying attention.
reply
THIS! I feel like the more people get involved with Bitcoin and apps/OSes are released to make running nodes easier, the less people actually care or check the validity of the underlying software. I bet you no one checks whether the Bitcoin Core code running on arguably the most popular node system (Umbrel) is valid.
reply
verifying docker images is virtually impossible if not build by yourself
reply
Correct. Part of the reason I hate docker and don't use it. I understand it's benefits and appeal but I personally stay away from it no matter how irrational my aversion may be.
reply
well you can build Docker Containers yourrself using the source code instead of using an image
No, it is a very bad idea to devote efforts in an alternative client because not only will we spread scarce development resource, but also it would be much more difficult to ensure that subtle consensus bugs don't get introduced while working on several clients at the same time. Different programming languages have different quirks that could cause undefined behaviors, and that's how you get an accidental chain split.
This idea is not new, in fact Satoshi himself dismissed it with pretty much the same arguments I'm putting forward here. I'm surprised to see this point being brought up again and again. It's one of the several not very intuitive and unique things about Bitcoin I guess ¯_(ツ)_/¯
reply
"... many consider this form of competition risky, as it may increase the chance of unplanned chain splits, caused accidentally by different consensus rules. The alternative client needs to match the consensus behaviour of the software users currently run, even matching bugs or unintended behaviour in the majority client." -Bitmex Research
reply
Really unnecessary fud. Of course several implementations can be coded with high quality that conform to protocol rules.
reply
You forget this \
reply
I agree, I see a lot of ETH devs on Twitter talking about huge amounts of tech debt. The way I understand it the current Bitcoin Core implementation in C++ has been very optimized, though I found this SO article about different implementations:
reply
To decentralize we either need to leave GitHub and leave it's maintainer/owner model and move to torrent
Or introduce several implementations that adhere to strict protocol definitions. Of course other implementations need to be battle tested and run extensive extensive unit testing and quality control.
It's either one or the other. But the current centralized position of a few dozen people is unacceptable in the long term.
reply
Github is just a coordination tool, which can be switched at any time. Git itself is decentralized already.
I agree that admin control of the github repo could be seen as "centralization" by some, but you have to consider that you don't have to download and run every new release that is put on that website.
The consensus rules will work just fine for you if you ran an older client. Hence the importance of avoiding changes that break consensus rules, AKA hard forks.
reply
Here's a great article, by Jameson Lopp, describing the history of the Bitcoin repo before it was Bitcoin Core and before it was on github, through the 2018 date of the article.
I do know that Wladimir has since left his role as lead maintainer. About github repo, he wrote this:
It’s not clear whether github can be trusted to act in our interest in the long run. Although issues and PRs are backed up through the API, having to move somewhere else could give significant interruption in development. And hopping from provider to provider would be awful—ideally the whole thing would not rely on a central server at all. For this I’ve been watching the radicle project, a P2P distributed code collaboration platform. It’s not quite there yet, but seems promising.
reply
This is very interesting. Funny how difficult it is for a decentralized system to ensure it remains decentralized throughout the whole vertical of the system.
reply
Don't confuse control of the bitcoin core github repo, or even control of Bitcoin Core as controlling the bitcoin protocol.
The code running on my node is all that matters. If they release something I do not agree with, I can reject it and continue running the existing software on my node, or run some other implementation (such as Bitcoin Knots, which is a fork of Bitcoin Core but currently supports is compatible by following the same protocol rules). That is why Bitcoin Core development is so careful to ensure they only make changes welcomed by the near unanimous consent from the "economic nodes".
reply
This brings up another question: If enough node operators and miners use prebuilt OSes where they don't verify the signatures of the bitcoin core software included, could it be possible for the developers of those OSes to inject code and then steer Bitcoin in a different direction? I guess this would be a sort of 51% attack. Although I guess depending on the code injected, it would create a discrepancy between some operators and others which would eventually raise enough eyebrows to cause further investigation into the matter.
reply
Luke Dashjr did exactly this with Gentoo, adding address blacklisting to bitcoind.
reply
Whaa? Do you have any links or resources that goes into more detail on this? I'm curious.
reply
This was quite a while ago and I'm going off memory, but I found this - https://bugs.gentoo.org/531634
He did so with the intention of blacklisting certain "spammers" (his words) which included SatoshiDICE which at the time was extremely popular. Very slippery slope imo.
reply
thank you for digging this up! This part of Bitcoin's history is close to being forgotten!
I think the bitcoin GitHub "organization" owns the repo, and several folks are admins/maintainers.
reply