And Ethereum is good for something: to remind us the hard fork is something that needs carefully prepared - politically, PR-wise, call it as you wish.
Hard fork is not a good solution, it can split the bitcoin network into two or more just like ETH and ETC.
a hard fork is not the exact same as ethereum..
even soft forks can cause intentional splits.
ethereum was an intentional split
to save repeating myself
in short:
soft=only pools vote
hard=nodes and pools vote.
then there are sub categories of good or bad of each
softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
if you want to talk about the ethereum style of for. that was a hard BILATERAL(intentional) split.
but also remember there is code in bip 9 to allow a soft bilateral(intentional) split too.
soft=only pools vote
hard=nodes and pools vote.
then there are sub categories of good or bad of each
softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
if you want to talk about the ethereum style of for. that was a hard BILATERAL(intentional) split.
but also remember there is code in bip 9 to allow a soft bilateral(intentional) split too.
yep gmaxwell confirms even in a soft(pool only) event bilateral splits can happen too
If there is some reason when the users of Bitcoin would rather have it activate at 90% (e.g. lets just imagine some altcoin publicly raised money to block an important improvement to Bitcoin) then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.
and when active. segwit pools will still actively ignore non-segwit pools
https://bitcoincore.org/en/2016/10/28/segwit-costs/
Quote
Miners could simply use software that does not recognise segwit rules (such as earlier versions of Bitcoin Core) to mine blocks on top of a chain that has activated segwit. This would be a hard-fork as far as segwit-aware software is concerned, and those blocks would consequently be ignored by Bitcoin users using segwit-aware validating nodes. If there are sufficiently many users using segwit nodes, such a hard-fork would be no more effective than introducing a new alt coin.
this is them talking about doing bilateral splits in a soft (pool only) flagging event.ethereum was not consensus. it was bilateral. --oppose-dao-fork (forcing nodes to BAN opposing nodes and avoid consensus)
I really was not aware of that.
So, is there a way to make the fork consensus and avoid a bilateral split?
The way I understand it now is, that the outcome of two permanent chains would have to be put into the source code and is not a matter of agreement or disagreement.
