Topic: Nakamoto consensus will be tested. (Read 127 times)
Everyone seems to have their own favourite technology, or feature set that they want to see added to BCH. I for one, think that we should endeavour to support changes that don't change the base protocol. While yes, since we have forked away, there is the proclivity to now add all sorts of proposed protocol changes. Well, because we have shown that it IS possible.
It has come time where the Bitcoin Cash community is now on the cusp of its first test of Nakamoto consensus. For those of you who don't know Nakamoto consensus is the term used to describe the way of deciding which fork chain in case of a competing one, wins out.
This is simply a matter of which one is longer, or contains the most proof of work. The first hard fork which broke BCH away from BTC, Nakamoto consensus was not allowed to occur because simply the communities did not want consensus. They wanted to split away.
However, since that first "Independance fork" there has been a subsequent upgrade hard fork in May of 2018 which executed without any fanfare or drama. That was because there was developer consensus on what was going to be in the upgrade. However, this November will be different.
This November will be the first hard fork upgrade in which the developer groups are not in agreement with what should be in the upgrade, and thus, this will be the first contentious upgrade. (note, not a contentious FORK, which is a splitting of the chain) This contentious upgrade will mean that the clients will start gathering support leading up to the upgrade flag date, and hopefully a majority will form around one client or the other. And if that does not happen, on the fork date, there will be a temporary 'hash vote' where the side which has the most hashpower will run the longest chain, and the minority chain will suffer delayed confirmations, which should presumably incentivize miners and businesses on the minority fork to upgrade to join the majority.
This is how Nakamoto consensus works, and we have not seen it happen in reality yet. To this date NC is still just a theoretical process, as it has yet to be tested on a contentious upgrade where the majority chain may try to deliberately prevent the minority chain from persisting.
This is capitalist competition in its most raw form, more pure, and most fair.
The contenders are already preparing for the 'election' date. And like American election campaigns, the media war is starting already. The contenders are:
Bitcoin ABC: the client that gave birth to the independence fork, started as a fork of Bitcoin Core client with an adjustable block cap. They are proposing to put in some experimental features which may have some possible future scaling potentials, but strangely are holding off on upping the hard cap limit default of 32mb.
They want to also add a new opcode DSV which has some potential uses in oracles and supporting 2nd layer token networks.
Bitcoin Unlimited: The original 'big block' client, at one point had 38% support of hashpower and almost defeated Segwit, before a series careless bugs and the New York Agreement for Segwit2x eroded all the hashpower support for the 'segwit blockers'. T
hey currently are aiming to support both ABC and SV feature sets as a configurable setting, ideal for neutrals
Bitcoin SV: the new kid on the block, whose goals are to bring Bitcoin back to the original working economic model, and prioritizes proven scaling methods over new features or experimental ones. They set the hard cap limit to 128mb, and also add back the remainder of the original Bitcoin basic opcodes.
If you own hashpower, it would be in your best interests to research which one you support and make sure you run that client starting the month before the fork day (October).
This is simply a matter of which one is longer, or contains the most proof of work. The first hard fork which broke BCH away from BTC, Nakamoto consensus was not allowed to occur because simply the communities did not want consensus. They wanted to split away.
However, since that first "Independance fork" there has been a subsequent upgrade hard fork in May of 2018 which executed without any fanfare or drama. That was because there was developer consensus on what was going to be in the upgrade. However, this November will be different.
This November will be the first hard fork upgrade in which the developer groups are not in agreement with what should be in the upgrade, and thus, this will be the first contentious upgrade. (note, not a contentious FORK, which is a splitting of the chain) This contentious upgrade will mean that the clients will start gathering support leading up to the upgrade flag date, and hopefully a majority will form around one client or the other. And if that does not happen, on the fork date, there will be a temporary 'hash vote' where the side which has the most hashpower will run the longest chain, and the minority chain will suffer delayed confirmations, which should presumably incentivize miners and businesses on the minority fork to upgrade to join the majority.
This is how Nakamoto consensus works, and we have not seen it happen in reality yet. To this date NC is still just a theoretical process, as it has yet to be tested on a contentious upgrade where the majority chain may try to deliberately prevent the minority chain from persisting.
This is capitalist competition in its most raw form, more pure, and most fair.
The contenders are already preparing for the 'election' date. And like American election campaigns, the media war is starting already. The contenders are:
Bitcoin ABC: the client that gave birth to the independence fork, started as a fork of Bitcoin Core client with an adjustable block cap. They are proposing to put in some experimental features which may have some possible future scaling potentials, but strangely are holding off on upping the hard cap limit default of 32mb.
They want to also add a new opcode DSV which has some potential uses in oracles and supporting 2nd layer token networks.
Bitcoin Unlimited: The original 'big block' client, at one point had 38% support of hashpower and almost defeated Segwit, before a series careless bugs and the New York Agreement for Segwit2x eroded all the hashpower support for the 'segwit blockers'. T
hey currently are aiming to support both ABC and SV feature sets as a configurable setting, ideal for neutrals
Bitcoin SV: the new kid on the block, whose goals are to bring Bitcoin back to the original working economic model, and prioritizes proven scaling methods over new features or experimental ones. They set the hard cap limit to 128mb, and also add back the remainder of the original Bitcoin basic opcodes.
If you own hashpower, it would be in your best interests to research which one you support and make sure you run that client starting the month before the fork day (October).
Jump to: