Bitcoin Stack Exchange is a question and answer site for Bitcoin users, developers, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I've read bitcoin content everywhere on the internet and nobody has yet demystified the fact that different versions of bitcoin core are working simultaneously. I know how soft forks work and how they are backward compatible and the don't break consensus. But nobody has come up with an explanation that how much of the bitcoin software can be custom-written or It can't be custom-written?
Please explain in terms of powerful solo miners and pool miners.
Forget Bitcoin for a second, instead imagine a network of nodes that passes around data packets that say Hello World!, followed by the current GMT date. To be a part of the network you just need to transmit such messages, but transmitting a different or improperly formatted message will get you banned.
So to join this network, all you need to do is to write a simple program that creates a message which reads Hello World!, and then the date. The choice of programming language doesn't matter much, neither does the method of discerning what the date is. Even the most newbie developer could write a program that would successfully maintain a position in the network, as long as they follow the rules.
Notice that in this example, what matters is the output, not how we arrived at it.
Back to the bitcoin network:
But nobody has come up with an explanation that how much of the bitcoin software can be custom-written or it can't be custom-written?
All of it can be custom written. On the bitcoin network there are many different versions of bitcoin-core running, as well as some other full-node implementations such as btcd or bitcoin-knots. For mining it is the same. Each different implementation can be an entirely different codebase, written in a different language, by different developers. What is important is the output of that codebase:
For bitcoin full-nodes, the desired outcome is that the node will stay in consensus with all other nodes about the current state of the network. Broadly speaking, this means following along with all 'consensus rules'.
For miners, the desired outcome is that they will be working to create what the network of full nodes will view as a valid block. A new block must conform to many rules in order to be seen as valid, so again the implementation's output will obviously have to respect those rules. Note that a miner will need to be running a full node to do so, in addition to running some code that actually constructs and hashes block candidates.
Pragmatically speaking, it is much easier to write a custom miner implementation, as there are less rules that must be strictly followed to achieve the desired outcome (ignoring the dependancy on a full node for network status information, of course).
Note that there is no way to check or enforce that other nodes on the network are running some specific code, even if you asked, they could just give a false answer. What does matter is the ability of those nodes to all stay in consensus - it is perhaps easier to maintain this if all nodes are running the same codebase, but it is not strictly necessary.
