Nostr Web Client

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.

Nuh 6mo ago

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.

Reply to this note

Please Login to reply.

Discussion

Nuh 6mo ago

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

Vortex | CTV | LNHANCE 6mo ago

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.

Nuh 6mo ago

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.

Vortex | CTV | LNHANCE 6mo ago

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.