Is diversity in bitcoin client implementations a good or a bad thing?

[Peter R]

Some people argue that there should be one dominant "reference" client (e.g., Core) and everyone should run that.  Others argue that there should be multiple competing implementation (e.g., Core, Classic, BTCd, Bcoin, Unlimited, XT).  What do you think?

[olushakes]

It will be better if you do more by explaining what you really mean by these two positions you have put forward to be discussed if you want more comment and the reason is because not everybody is computer savy or understand all the technical jargon that goes on in the bitcoin world including myself which I have a feeling occupies a larger percentage of the population. So, do well to come down to our level for easy communication.

Some people argue that there should be one dominant "reference" client (e.g., Core) and everyone should run that.  Others argue that there should be multiple competing implementation (e.g., Core, Classic, BTCd, Bcoin, Unlimited, XT).  What do you think?

[odolvlobo]

Multiple implementations are necessary. If one implementation goes down or has a bug, then only the users of that implementation are affected. If there are many implementations then the effect of one implementation having a problem is minimal.

The fact is that there are already many implementations currently running. This site (https://bitnodes.21.co/nodes/) lists 83 different implementations that are currently in use. Unfortunately, they are mostly versions of Bitcoin Core, so they all tend to have the same flaws.

Also, there is an important flaw in the single implementation argument. Whenever the single implementation is updated, a new implementation that could create an accidental fork is published. You can't avoid accidental forks by using a single implementation if you want to upgrade it. In fact, there already has been an accidental fork caused by a Bitcoin Core update.

[panju1]

Some people argue that there should be one dominant "reference" client (e.g., Core) and everyone should run that.  Others argue that there should be multiple competing implementation (e.g., Core, Classic, BTCd, Bcoin, Unlimited, XT).  What do you think?

When the underlying code is open source, it is invariable that there are multiple reference clients. It is a good thing, because features and reliability of different implementations is different. To each, his own. 

[HabBear]

Diversity is good for almost everything, why not for Bitcoin client implementation? (Honest question here.)

To your exact question, is it proven that running multiple Bitcoin clients (or having them in existence) "is critical...to avoid accidental forks"?   

[Herbert2020]

correct me if i am wrong but i believe using the world "bitcoin client implementations" is not what you really mean. "client" implies different nodes/wallets or any other project name but working on the same consensus. these implementations you named (e.g., Core, Classic, BTCd, Bcoin, Unlimited, XT) are not implementing bitcoin they are changing bitcoin.

so my answer is:
implementing the same consensus but with different names hence creating different clients is a good thing. being open source it helps people who don't understand one programming language (e.g. c++ that core uses) use another that they understand or feel more conformable with.

as for implementation of different consensus and "changing bitcoin" that is what classic, unlimited,... are doing. it is still a good thing but as long as there aren't more things in the background. shady things that can destroy bitcoin or cause irreparable damage, and in the end as long as they do a proper fork with an overwhelming majority meaning more than 90% support from miners, users, nodes, services,... that can be a good thing to move forward.

[AngryDwarf]

Some people argue that there should be one dominant "reference" client (e.g., Core) and everyone should run that.  Others argue that there should be multiple competing implementation (e.g., Core, Classic, BTCd, Bcoin, Unlimited, XT).  What do you think?

I think there should be a well defined and documented protocol. Competing implementations provide technical innovation on how to efficiently implement that protocol. A "reference" client should not define the protocol, otherwise the protocol is ill-defined due to the possibility of unintended implementation of bugs which then define the protocol.

[gmaxwell]

If one implementation goes down or has a bug, then only the users of that implementation are affected.

This is true for many things but not for consensus systems.

In a consensus system with multiple major implementations if _any_ implementation has an issue everyone has an issue-- and if there is just a "disagreement" but none are objectively wrong, then there is still an issue.

The reason for this is that for a consensus system the primary purpose is to be consistent, so any inconsistency is a failure, regardless of whom is "right" vs "wrong" or even an otherwise harmless difference.  Inconsistency immediately creates an opportunity for funds theft, when you think a state is final but it really isn't and it gets reversed.

An implementation is a _precise_ definition.  A pile of paper is not, or to the extent that it is precise it's still not that relevant: if paper says X and the network does Y, then Y it is, you can't generally just undo Y later without undoing transactions that people thought were final and irreversible.  Good specs are useful to aid understanding and analysis, but cannot define the network because they cannot control its action from moment to moment.

The implications are clear to anyone who has spent a reasonable amount of time doing serious engineering for a distributed consensus system.

[dinofelis]

I think it is necessary, in order to separate the protocol and the software, because otherwise, the software defines the protocol, and the authors of the software are then also the masters of the protocol, giving "hidden power" to the software writers of the "official client".

Of course, that depends on how one sees the protocol.  One can admit that the protocol is whatever the software writers decide it is, and can change it to their desires.  If that is explicitly stated, then of course, there can only be one implementation, and one has explicitly taken the view that the protocol is whatever the software does: a kind of "smart contract" thing, but which is not immutable, but modifiable by one team.

However, in as much as one thinks of a crypto currency as a protocol graved in stone that is essentially never to change, and implements true immutability, then the only way to have this immutability of the protocol is by having a lot of competing implementations, that can never settle on any agreement of change by their mutual antagonism, in the same way that miners cannot settle on a modification of the block chain history, by their mutual antagonism.

I would like to add that "immutability of the block chain" with a mutable protocol, is meaningless, as we saw with ethereum.  If you can change the protocol, you can change the meaning of the past block chain and the rights it grants, so even if the binary data remain the same, the mutable protocol can do anything with it.  Hell, a mutable protocol could even take away Satoshi's stash in principle.  So in as much as immutability means something, the protocol too, has to remain immutable, which can only be established if there is such a big zoo of software implementations, that any agreement on change is impossible (except maybe for obvious bug fixes that affect no economic relationship).

That said, what matters is not the user client, it is the miner software that defines the protocol, because they are the ones that make the chain, and, as gmaxwell said, the currency protocol is whatever the miner pools decide it is in practice by making a chain according to their mutually agreed-upon rules and protocol, unless a user subset agrees upon forking away and changing to PoS or another PoW algorithm (but that only shifts the power to another set of miners).

User clients have to adapt to whatever the miners make as a block chain.  This is a bit like web browsers: user web browsers must adapt to the protocol that web servers use.  Except that here, there's only one "web server": the block chain made by the consortium of miners (about 20 pools, of which 5 have majority).  If your "browser" doesn't understand the protocol of that "web server" it will give you faulty information, or it will indicate that the page is not valid ; it will emit transactions that will not be recognized by the "web server" (the block chain makers).  So the only thing to do, is to use a compatible browser.

But of course there is a feedback: in as much as a web server wants to serve pages that are "looked at", block chain makers want to make a block chain on which users want to buy tokens.  So web servers will make pages that can be looked at by browsers, and block chain makers will make a block chain that will be used by token-buyers.

[amacar2]

I think its bad thing to have multiple client for bitcoin but as bitcoin is open source, everybody have freedom to come up with their own version and developer team.

I would rather support only one client (core) than trusting any new dev teams.

[gringoprivelege]

Some people argue that there should be one dominant "reference" client (e.g., Core) and everyone should run that.  Others argue that there should be multiple competing implementation (e.g., Core, Classic, BTCd, Bcoin, Unlimited, XT).  What do you think?

It should be decentralized/spread out so if one fails, the others still work effectively.

[AngryDwarf]

So is there some kind of succession bloodline to who is the rightful heir and dictator of the bitcoin reference implementation since Satoshi left? Is it the last claimant left when all others have been put to the sword or banished from the land of bitcoin?

[dinofelis]

So is there some kind of succession bloodline to who is the rightful heir and dictator of the bitcoin reference implementation since Satoshi left? Is it the last claimant left when all others have been put to the sword or banished from the land of bitcoin?

I thought that Satoshi gave the github keys to Gavin ?

[Renji Abarai]

I think its a good thing, so that we will have a choice for which implementation is better. The more it is diverse the more innovation we can choose,the more better services we can try and the most stable one we can used.

[AngryDwarf]

So is there some kind of succession bloodline to who is the rightful heir and dictator of the bitcoin reference implementation since Satoshi left? Is it the last claimant left when all others have been put to the sword or banished from the land of bitcoin?

I thought that Satoshi gave the github keys to Gavin ?

I though Gavin had been banished from the land of bitcoin. Someone changed the locks on the keep.

[Kprawn]

So is there some kind of succession bloodline to who is the rightful heir and dictator of the bitcoin reference implementation since Satoshi left? Is it the last claimant left when all others have been put to the sword or banished from the land of bitcoin?

I thought that Satoshi gave the github keys to Gavin ?

It was taken away, when it became clear that he could not be trusted to make good decisions. https://www.cryptocoinsnews.com/bitcoin-chief-scientist-gavin-andersons-github-commit-access-removed/

I quote : " The decision to revoke Andersen’s admin-level privileges is undeniably tied in with his unequivocal assertion that Craig Wright is, in

fact, Satoshi Nakamoto. "

Some might say, it was a excuse to get rid of him, but why should he be trusted... if he makes bad calls like that?

[odolvlobo]

If one implementation goes down or has a bug, then only the users of that implementation are affected.

This is true for many things but not for consensus systems.

In a consensus system with multiple major implementations if _any_ implementation has an issue everyone has an issue-- and if there is just a "disagreement" but none are objectively wrong, then there is still an issue.

When Bitcoin.com mined a 1+ MB block because of a bug in their code, who was affected? When people found and exploited bugs in the BU client, who were affected?

You wrote, "in a consensus system with multiple major implementations, ..." My ideal is a consensus system without multiple major implementations. As I wrote earlier, there are 83 different implementation being used right now and yet Bitcoin is humming along. The real problem is that a few of them dominate the rest, and a person striving to make Bitcoin more robust would be working to eliminate the dominance of any particular implementation because that implementation is a point of failure.

The reason for this is that for a consensus system the primary purpose is to be consistent, so any inconsistency is a failure, regardless of whom is "right" vs "wrong" or even an otherwise harmless difference.  Inconsistency immediately creates an opportunity for funds theft, when you think a state is final but it really isn't and it gets reversed.

An implementation is a _precise_ definition.  A pile of paper is not, or to the extent that it is precise it's still not that relevant: if paper says X and the network does Y, then Y it is, you can't generally just undo Y later without undoing transactions that people thought were final and irreversible.  Good specs are useful to aid understanding and analysis, but cannot define the network because they cannot control its action from moment to moment.

It is true that an implementation is a precise definition, but is such a precise definition necessary? You write as if Bitcoin does not have a mechanism for resolving disputes between nodes, but it does of course.

[mining1]

I do not own any bitcoin so i am trying to be as objective as possible. I don't like bitcoin, because it has no clear development path, can't scale and it is centralized in china, which is extremely bad. That being said, client diversity is a positive thing, it's about decentralization after all.

To understand why, look at ethereum; it has several client implementation. Last fall, it was ddos-ed, and one implementation held on it's feet pretty well, and that was parity's implementation. The same people that are behind the new bitcoin's parity implementation. The only downside is, when client hardforks to further upgrade, a split can happen. But that's no real threat to the network, just a few hours of uncertainty at most. Clearly the benefit beats the risk.

Arguing for one implementation basically goes against what a public blockchain stands for. Unless everyone or almost everyone wants that, but it's clearly not the case here.

[spin]

Multiple implementations of the consensus logic will lead to forks eventually.  One of the two is bound to become inconsistent with the other at some point and this will result in a fork.  The presence of forks (or the possibility of presence of forks) reduces the security of bitcoin as you have to be careful when you receive money as you need to be very sure that you've received money on the right fork and/or that there is no fork.

How long the forks last depend on the nature of the difference, popularity of the clients and probably the reaction times of the miners as well.

[dinofelis]

So is there some kind of succession bloodline to who is the rightful heir and dictator of the bitcoin reference implementation since Satoshi left? Is it the last claimant left when all others have been put to the sword or banished from the land of bitcoin?

I thought that Satoshi gave the github keys to Gavin ?

It was taken away, when it became clear that he could not be trusted to make good decisions. https://www.cryptocoinsnews.com/bitcoin-chief-scientist-gavin-andersons-github-commit-access-removed/

I quote : " The decision to revoke Andersen’s admin-level privileges is undeniably tied in with his unequivocal assertion that Craig Wright is, in

fact, Satoshi Nakamoto. "

Some might say, it was a excuse to get rid of him, but why should he be trusted... if he makes bad calls like that?

Ok, but the point is: there IS a succession blood line.