No, the consensus at the moment is literally what Core does (which is not all defined), there is more than zero cases of separate implementations having accidental forks because they didn't do exactly what Core does.
The kernel library should fix this, but it is taking very long and won't be ready any time soon.
No. In bitcoin consensus emerges from what nodes choose to run not from what Core ships. The power rests with the network, not the developers.
Except you can't run code unless you are confident it is compatible with what everyone else is running or risk forks which is not acceptable for businesses or most users.
And since there is no spec, no one can run anything that isn't based on Core.
Again, Core is aware of that and that is why the kernel library exists, but it is not ready.
No. You're conflating practical dominance with enforced monopoly. Core is the reference because of trust and audit history not coercion. Nothing stops an alt client from matching consensus behavior (see Knots, Libbitcoin). Core’s dominance remains voluntary not structural or enforced.
Coercion is irrelevant in software anyway, no one is coercing anyone to not fork away at the extreme.
But the lack of neither spec nor extractable kernel, makes running anything but bitcoind not feasible.
Don't take it from me, I already heared at least one core dev describing the kernel library as necessary to reduce the pressure and liability on the Core team.
An ossified kernel, one day, will make Core much less mission critical to Bitcoin, as just another client, probably not even the most popular, while consensus remaining safe.
I am not just saying this to be argumentative, I am deeply in favor of reference implementations vs spec and beps and nips.
But that position HAS to be combined with as simple reference implementation as possible so people can use it while still being able to customise it to serve their needs.
Again, Core itself understand this which is why the kernel is necessary
I agree that libbitcoinkernel will reduce Core’s centrality over time and that an ossified kernel is a good step but claiming non-Core clients are 'not feasible' is wrong. Knots, BTCD, and Libbitcoin exist today and function because feasibility isn't the blocker while trust, audit depth, and adoption are.
But what are people trusting and auditing? It is mainly consensus.
Knots don't count it is just Core with patches, and Libbitcoin is only compatible with Core until it is not. I don't know about BTCD but is that the one where it actually had a fork because it failed to replicate some undocumented Core behaviour? Or was that something else?
At the end of the day, Core is absurdly unwieldy that no one is using it in any mobile device, which is where all payments happen, and they can't optimize for every use case.
I want innovative clients to do their things in different environments, while all knowing that given the same chain of blocks, they will all reach the same conclusion of say UTXO set.
Or at least given the same block they all can be confident they will validate it the same way.
So far the only way to do that was the libbitcoinconsensus which is now deprecated.
You’re right that shared consensus assurance matters but claiming non-Core clients are unfeasible ignores that BTCD, Libbitcoin, and even non-Core forks have validated the chain. BTCD’s historical fork incident proves the point as the network not Core enforced consensus, correcting the client. Core reflects consensus it doesn’t define it. Again I'm all for multiple clients but you cannot define Core as a monopoly.
