Client diversity - why isn't it an issue for Bitcoin?

[buwaytress]

Hey all, a rare post here but I wanted to get some opinions.

Am working on a (low-tech) piece on client diversity -- somewhat of an old discussion in Ethereum and perhaps with renewed debate owing to the January outages of two clients, which led to minimal impact, only because of a collective 15% odd share of total clients in use.

A completely different network (PoS possibly the major difference of relevance) of course, but I wonder if there ever has been any discussion or similar concern for a client supermajority in the Bitcoin network? Cursory web searches don't throw up much at me, though the 2010 value overflow appears (to me, at least) an example of how a lack of client diversity in Bitcoin could lead to network failure.

I suspect it isn't an issue for Bitcoin, but I can only guess it's because the network and Bitcoin Core itself is highly fault tolerant, or is extremely agile in detecting and patching. In any case, far better than in 2010.

Geth's 46% or so client share in Ethereum seems to be a big worry but pales to Bitcoin Core's 98% dominance.

Hoping for some light shed on why this comparison, and Bitcoin client diversity, is irrelevant?

[vjudeu]

but I wonder if there ever has been any discussion or similar concern for a client supermajority in the Bitcoin network?

Yes, even Satoshi expressed his opinion about that:

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

Bitcoin Core's 98% dominance.

Note that:

1. Even if someone uses some modified version of Bitcoin Core, most node runners do not bother to change the default client name into something else.
2. If someone changes that name, it is usually done in brackets, so it is still identified as Bitcoin Core.
3. There are different versions of Bitcoin Core in use. Some article about it: https://blog.lopp.net/when-do-bitcoin-node-operators-upgrade/
4. Even if someone is running his own client, it usually is still connected to some Bitcoin Core node, just to be sure, that it will be "bugward-compatible". Because sometimes you may feel a need to "fix" something, and then find out, that your "fix" is actually a hard-fork (and then, you are for example mining bad blocks, which are always rejected; or you don't accept the strongest chain as valid, because you reject for example a block with transaction containing SIGHASH_SINGLE bug).

[DaveF]

Going to also put out there 2 things.

1) We tend to be paranoid, so even if someone or some group does come up with another client, it's tough to get people to move because who wants to run software that controls money that has not been as battle tested as core.

And

2) If I put together a team and came out with a different client and people used it and it was popular.....Then what, is there a business plan or are people donating their time? If it's worked on as a best effort thing how does the project keep up with core. And so on.

Yes, it's possible, but it's probably never going to happen.

And, to answer the question why is it not an issue. The answer is simple, because nothing has gone horribly wrong yet so we keep using it.

-Dave

[buwaytress]

but I wonder if there ever has been any discussion or similar concern for a client supermajority in the Bitcoin network?

Yes, even Satoshi expressed his opinion about that:

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

Thank you for sharing that information and quote. I'm not able to say if an alternative implementation of Bitcoin is today as big a menace as he/they imagined it to be -- and if there was a comment about client diversity in relation to the overflow bug since satoshi was still around at the time? Zero-day attacks targeting Core seem to me pretty menacing...

I'm just thinking from a simplistic view of attack surface. It's not about rewriting the code but using a different language altogether (which seems to be the Ethereum client approach, multiple languages, even some I don't recognise). In the same way having 20k nodes improves redundancy, forcing a would-be attacker to create a weapon for all clients in multiple languages just makes it that much harder for a successful attack.

Bitcoin Core's 98% dominance.

Note that:

1. Even if someone uses some modified version of Bitcoin Core, most node runners do not bother to change the default client name into something else.
2. If someone changes that name, it is usually done in brackets, so it is still identified as Bitcoin Core.
3. There are different versions of Bitcoin Core in use. Some article about it: https://blog.lopp.net/when-do-bitcoin-node-operators-upgrade/
4. Even if someone is running his own client, it usually is still connected to some Bitcoin Core node, just to be sure, that it will be "bugward-compatible". Because sometimes you may feel a need to "fix" something, and then find out, that your "fix" is actually a hard-fork (and then, you are for example mining bad blocks, which are always rejected; or you don't accept the strongest chain as valid, because you reject for example a block with transaction containing SIGHASH_SINGLE bug).

That I didn't know. I'm wondering if there is any source that keeps track of versions connected in a way I could see? I've come across mentions from Dashjr about tens of thousands more clients running but not connected in a way we could reach them. Could these also be very different versions of Core? And do they count at all then?

If you were to guess, adjusting for modified versions, what would you think is a more accurate client share of Bitcoin Core?

I found something else from Lopp's blog: https://blog.lopp.net/2022-bitcoin-node-performance-tests/
So it does appear there are at least 2 working clients in 2022 that the Coindance link I shared didn't detect. Minus the clones, that's a total of 9 working clients that aren't Bitcoin Core and not in C++.

1) We tend to be paranoid, so even if someone or some group does come up with another client, it's tough to get people to move because who wants to run software that controls money that has not been as battle tested as core.

Appreciate your response! Certainly seems to be an agreement in Ethereum that most people go for the majority simply because they are "lazy". I can relate, SPV-wise, I chose Electrum and never bothered to switch. I feel confident and assured with it, but don't really have evidence about others that should confirm my lack of confidence and assurance in them.

What makes more sense to me is that Geth also receives the most attention and funding from Ethereum Foundation, so logically, should be the most battle-tested and robust. That to me mirrors the situation with Bitcoin Core.

2) If I put together a team and came out with a different client and people used it and it was popular.....Then what, is there a business plan or are people donating their time? If it's worked on as a best effort thing how does the project keep up with core. And so on.

Isn't this how many of the clients in link above started out though? I presume most of them were voluntary, and yeah, some look dead already, but if enough people found them useful, or a new audience found them accessible (let's say, I'm just thinking out loud, a client twice as easy to use than Core).

Yes, it's possible, but it's probably never going to happen.

And, to answer the question why is it not an issue. The answer is simple, because nothing has gone horribly wrong yet so we keep using it.

I suppose even if something does go horribly wrong, the situation won't change?

[vjudeu]

I'm wondering if there is any source that keeps track of versions connected in a way I could see?

https://bitnodes.io/dashboard/#user-agents

I've come across mentions from Dashjr about tens of thousands more clients running but not connected in a way we could reach them.

If you have a server, then your node can be reached from the outside. But if you have just a regular connection via some ISP, then you probably share your IP with thousands of people. And then, you cannot "just open a port in your router", because it will be opened in your local WiFi network, but nowhere else. Usually, you won't run a server from your home, by using just IPv4. And a large part of the Internet is still running on that, and this is not going to change soon, for many reasons.

Could these also be very different versions of Core? And do they count at all then?

If you are running some well-connected node, then it can be seen in some global statistics. Also, nodes used by developers are placed in the source code as initial seeders. So, the answer to your question is quite simple: you run a node, you accept some incoming connections, and then you can get some statistics. If some node can connect to you, but you cannot connect to them, then it is probably a regular client, not located on any VPS or anything like that. Which usually means, that this particular user is just running Bitcoin Core from some home computer, with standard Internet settings, without any servers, and additional services like HTTP or SMTP. And there are more such operators, than those, who are willing to invest time and money, to buy some VPS, and setup a node, which can accept incoming connections, and be online 24/7.

If you were to guess, adjusting for modified versions, what would you think is a more accurate client share of Bitcoin Core?

I don't know. The last time I was running a vanilla, unmodified Bitcoin Core, was probably something around 2020. Since then, I always use slightly tweaked version of Core, but I don't change User Agent into "special version, made by vjudeu" or anything like that. It just has those ".99" version endings, indicating that it was compiled from source code, usually from the master branch, also with some pull requests merged, and that's it.

Isn't this how many of the clients in link above started out though?

You are in a different position, if there is no competition. When Bitcoin was released, back in 2009, Satoshi didn't have to think about "other clients" at that time. Also, he didn't have to think about "altcoins" at all, because there was no other chains. The traffic on the main chain was so low, that nobody really needed to compete with what already existed.

Today, the whole situation is different. If someone is going to release a new client, then it looks like trying to create another operating system, capable of handling EXE format, and competing with Microsoft. It is of course possible, but unlikely to succeed. There are projects like Wine or ReactOS, which are developed for years, and can handle old files, sometimes better than new OSes, which dropped some legacy code, but that's it. You don't see that many stores, where you can buy "a new laptop with ReactOS" or "a new gaming laptop with Linux and Wine".

let's say, I'm just thinking out loud, a client twice as easy to use than Core

It depends, what do you want to create. There are still a lot of features, which are already present, but which have less support, than they could have. One of those examples is related to sighashes. You still cannot make a new transaction, see it like you can do so in block explorers, and pick custom sighashes, by having highlighted those parts of the transaction, which are going to be signed. And in the same way, you don't have a nice, built-in GUI for the Script, where you could execute contracts step-by-step, and design them from graphical interface. You cannot put "OP_2 OP_SHA256", click "run", and get "OP_PUSH_32 dbc1b4c900ffe48d575b5da5c638040125f65db0fe3e24494b76ea986457d986" as a result.

Also, if you want to do something unusual, then you are going to write some new code anyway. And then, if it works in Core, then you can usually move forward, and just use it. But if you have another client, then you usually have to test both: your client, and Core, just to make sure, that your client is still compatible.

Anyway, Bitcoin is still more software-developer-friendly, than user-friendly. And again, it is not going to change soon. Recently, I saw that for example in testnet3 and testnet4: if you can write custom code, then you are in a much better position, than other miners. For example: the choice between ASIC-based and CPU-based mining is built into test networks, by picking between two difficulties in your block headers. But most users don't even know, that the consensus allow them to make that choice in the first place, and they think they have to sit idle for 20 minutes.

[ABCbits]

Cursory web searches don't throw up much at me, though the 2010 value overflow appears (to me, at least) an example of how a lack of client diversity in Bitcoin could lead to network failure.

I think you didn't find this page, https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures.

or a new audience found them accessible (let's say, I'm just thinking out loud, a client twice as easy to use than Core).

In past i tried 2 different full node (gocoin and bcoin), but Bitcoin Core remains most accessible option. Bitcoin Core also remain full node with fastest IBD/initial sync. So there's no reason to use other full node software, unless you care about diversity or develop something with specific needs.

[buwaytress]

Appreciate the responses, vjudeu, thank you.

Does help me to understand a bit more on the behaviour of nodes, and how Core isn't actually the Core I'm assuming (though for practical purposes probably they all do the same thing). And confirms somewhat my thoughts on Core being more dev than user friendly. Not sure that will ever change, though I feel it is important if we want to expand diversity in node operators too (or is it?).

Overall omewhat gives me a bit more context about the topic, though I feel still, I don't have quite enough to answer "why client diversity isn't an issue for Bitcoin"!

Cursory web searches don't throw up much at me, though the 2010 value overflow appears (to me, at least) an example of how a lack of client diversity in Bitcoin could lead to network failure.

I think you didn't find this page, https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures.

Does seem to further back the case or need for client diversity though, no? =)

[vjudeu]

still, I don't have quite enough to answer "why client diversity isn't an issue for Bitcoin"!

Maybe this page will help a little bit: https://ncase.me/trust/

If you understand, why CopyCat wins so often, then you may understand, why there are not that much different clients. And you will probably also understand, why many altcoins are so similar to the original design. Or also maybe why testnet reached so huge success, by being so similar to mainnet, and altering only small, simple rules, and leaving everything else unmodified.

[ABCbits]

Cursory web searches don't throw up much at me, though the 2010 value overflow appears (to me, at least) an example of how a lack of client diversity in Bitcoin could lead to network failure.

I think you didn't find this page, https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures.

Does seem to further back the case or need for client diversity though, no? =)

I would say yes. Few of the CVE happened on mainnet, which had to be fixed by making block from specific height (which violate Bitcoin protocol) invalid. Such action would be less tolerated today and would harm Bitcoin reputation.

[BlackHatCoiner]

Why would it be an issue? If you don't like things like standard rules, then you can opt-in to Bitcoin Knots which comes with optimal expert control, and which allows you to change local settings such as these. If you don't like using Bitcoin Core as a wallet, then simply pick one of the many wallet software like Sparrow and use that to connect directly to your Bitcoin node.

[NotATether]

Simply put, Ethereum moves fast and breaks things more often. So having a lot of clients is good for them in case someone accidentally breaks the protocol with a bad commit.

However, Bitcoin doesn't need other clients because the devs spend a lot of time debating and testing new changes before they are merged. This greatly minimizes the number of faults that get inside Core.

[alexeyneu]

it IS a problem. I can review their windows client because i'm windows programmer myself. They use things from windows 98 samples and do not have a clue about it , no one there knew that std::ifstream constructor supports wide strings so they ask a guy to write a replacement and he failed to do so. I'll not be impressed when this blockchain will stuck

[vjudeu]

I'll not be impressed when this blockchain will stuck

Of course it will, for example because of casting time-related data types: https://bitcointalk.org/index.php?topic=5365359.msg58166985#msg58166985

However, it seems to be fixed in some new versions, so I guess people will upgrade from 22.0, long before 2038.

In the same way, I expect all miners will apply BIP-42 before 2214: https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki#compatibility

They use things from windows 98 samples and do not have a clue about it

You are basically repeating Nick Szabo's argument, that you have to fully specify the architecture, and Script should work somehow like "x86" (or some universal version of that). However, Satoshi just ignored it, and released Bitcoin, without knowing about for example DER encoding or compressed public keys. And we have, what we have. If there are mistakes, they can be fixed. We don't need "a perfect JVM" for the Script from the start. Even TapScript can show you, that the whole scripting language can be upgraded, if needed.

https://unenumerated.blogspot.com/2005/12/bit-gold.html

The main problem with all these schemes is that proof of work schemes depend on computer architecture, not just an abstract mathematics based on an abstract "compute cycle." (I wrote about this obscurely several years ago.) Thus, it might be possible to be a very low cost producer (by several orders of magnitude) and swamp the market with bit gold. However, since bit gold is timestamped, the time created as well as the mathematical difficulty of the work can be automatically proven. From this, it can usually be inferred what the cost of producing during that time period was.

Also, that paragraph alone is a strong indication, that Nick Szabo is not Satoshi.

Edit: If you wonder, how Bitcoin could look like, if it would be created by Nick Szabo, then imagine having "x86-like" (or JVM-like) machine code, instead of Script. And if he would care about Turing-incompleteness-on-purpose, then imagine having "jmp" instruction, which can only jump forward, and never backward, so you can have "if", but not "while".

And if it would be strictly connected with hardware, then it is more likely to be x86-like, than JVM-like. Then, when you have a Script, you load it, just like some EXE or DLL, and just execute it. Before running, you could make some checks, like "is there no while loop", or things like that. Or: you can have a timeout, or other mechanism, like "consume up to N cycles", but the first version could just do raw "load and execute binary blob".

And again: note that Nick Szabo thought about things like that, before thinking about "explosion of special cases". He actually started from architecture-based-Script, and didn't even mention about having enums for each transaction type (while Satoshi did those things in exactly reversed order).

[NotATether]

I'll not be impressed when this blockchain will stuck

Of course it will, for example because of casting time-related data types: https://bitcointalk.org/index.php?topic=5365359.msg58166985#msg58166985

However, it seems to be fixed in some new versions, so I guess people will upgrade from 22.0, long before 2038.

That is actually insane. It means all of the standardness rules and protocol upgrades that have been added in 22.0 and below like Segwit, Taproot, RBF, locktime and so on, will all be active on 100% of nodes by 2038.

At that point everyone will have to update their nodes, and then the only reason why people would not e.g. support segwit addresses by then will be out of laziness than any technical limitation.

[alexeyneu]

win98 stuff i mean use of _T() which means you're not sure os supports unicode.  In assembler you can copy code forward then do far jmp