Bitcoin Forum

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 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.

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.

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.  :)

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"?   

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.

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.

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 (https://bitcointalk.org/index.php?topic=195.msg1611#msg1611) who has spent a reasonable amount of time doing serious engineering for a distributed consensus system.

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.

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.

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

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 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.

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

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?

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.


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.

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.

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.

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

I`m not very familar with Core and all this stuff,but different implementations are good because of the
decentralization.Competition always brings better results than a monopoly.
Bitcoin Unlimited doesn`t stop btc growth.

No. Satoshi did not even have the project on Github originally. Gavin took over the project after Satoshi disappeared since he was the most experienced and active contributor at the time. I have found no evidence for Satoshi handing anything over except for Gavin's own statements. There is no indication from Satoshi that there was any plan for a "line of succession".

A precise definition of the consensus rules are necessary. Everyone must be following the exact same consensus rules, with its bugs, intricacies, and undefined behavior, in order to not have any accidental hard forks. The 2013 accidental hard fork is an example of such failure of different consensus implementations. On paper, all nodes were following the same rules. But in implementation, one version of the implementation had a bug which in turn caused an accidental chain fork. If everyone follows precisely the same rules, then this cannot happen. The only way for everyone to follow precisely the same rules is for every node to be share the same consensus implementation.

Ah, nice to know !


This is actually only true for mining pool node software, as they are the only ones producing the block chain.  All the others can only download what the miner nodes produce or stop and not download it.  So the de facto protocol is the protocol that is compatible with the consensus chain that is produced by the miners ; whether that corresponds to any written document or not and whether that corresponds to any non-mining node or not.  If all miner pool nodes follow the same protocol, then only one chain is produced, which you can read with a "compatible browser" or which stops when that "browser cannot understand the only chain around".  Here, browser is any full node, or light wallet.

No, all full nodes matter and all full nodes are what define the consensus rules. You cannot have just the miners define what consensus is since they then have the ability to change it at will to fit their own agenda. Full nodes enforce that miners are following the same consensus rules by rejecting invalid blocks. Full nodes matter just as much as mining nodes as they determine what everyone else accepts as valid.

You can't just be compatible with the consensus rules, you must use the exact same rules with its bugs, intricacies, and undefined behavior. If you are just compatible, that means that the implementation is different and should that have a bug or do just one thing slightly differently, can cause a chain fork. The entire goal of consensus is to avoid chain forks.

Having multiple implementations of non-mining nodes is still problematic since a bug in one implementation means that people using that implementation can be forked off of the network either by a malicious entity or just accidentally.

nope

satoshi was working on sourceforge right up to when he left december 2010

gavin however had his own repo on github thats started something like june 2010.

when satoshi left, gavin was deemed the main go to guy so people started using his github repo, which he opened up to other people to use aswell. he actually said in 2012-13ish that in a couple years he may move onto other projects
which he eventually did by giving the main maintainer keys to laanwj

gavin continued as just a contributor until core guys decided to cut gavin off due to the craig wright drama with a pretence that gavin "must have got hacked"

but if everyone was following the exact same code.. EVERYONE gets affected if there was a bug
EG the 2013 event happened because everyone was virtually core managed..


however imagine if there were some 0.8 (leveldb) nodes and btcd(wrote in GO and leveldb storage) the network would continue and make blocks and only the 0.7(which would have been less majority, if more diversity existed)) would have been left unsynced. and it would have been far far easier to just say "hey 0.7 time to upgrade"

by having diversity, only the non rule following nodes get kicked off the network or cant sync.
EG assert bug was not a network wide bug because of diversity

thus bitcoin continues due to diversity and only the problem code implementation would stop.

diverse decentralised peer network has its reasons to be diverse and decentralised.

---

the only advantage of everyone centralizing the exact same code line for line. is to make changes easily without veto because everyone would be forced to change without choice.. which also has its own risks and exploitability by doing this.

Yes, yes, I know that that is being said, but the logical error in this reasoning is that what you put forward as a desired goal of a system is taken as a logical technical consequence of said system.  This leaves the logical possibility that the system is not doing what was the desired goal, aside.
The technical fact is that if there is only one block chain out there, made by miners who agree mutually on a given protocol, and hence, don't produce a competing chain, but only build upon each-other's blocks, then other nodes can only decide to download, or not download that chain, but that's all there is around.  

This is like as if there was a single web server, making HTML pages with a certain protocol, and you deciding that your browser is going to read pages that satisfy another protocol.  Ok, you can point your browser to that server, and your browser will refuse to load the page.  And you get a blanc page.  Because there's nothing else your browser can download that could satisfy him.

A non-mining node can download a chain, and verify whether it agrees to the protocol rules on which it is built ; and if it is not satisfied, it stops loading that chain.  But there's no other chain around.  So it just gives the user a "blank page" as wallet.

The kind of reasoning is like "as our technology has as an aim that this rocket flies to the moon, and as our rocket is using propellers, propellers can fly rockets to the moon".  We've left out the logical possibility that our rocket will not fly as designed.  This is the logical equivalent of "as we want full nodes to be in control of the protocol, they are in control of the protocol".   However, as gmaxwell pointed out, the protocol is not what we write on paper, but what *actually happens in nature*.  And what *actually happens in nature* is about 20 mining pools making a unique chain, and nobody else does.  So that chain is what defines the protocol, and hence, whatever software those 20 pools use, is what defines the protocol, because that's the only one really out there in nature.


Only miners can cause a fork.   A non-mining full node can accept the only chain in town, or not accept it and stop.