pull down to refresh
43 sats \ 12 replies \ @tomlaies 13 Jun 2022 \ parent \ on: Who's the owner of the Bitcoin Github repo? How did they become the owner? bitcoin
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.
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
reply
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