Quote from: dinofelis on March 09, 2017, 04:15:27 PM

Quote from: franky1 on March 09, 2017, 04:02:09 PM

to avoid being left unsynced, it needs to ban the opposition so that it doesnt see the oppositions higher blockheight and also doesnt see thier own attempts getting orphaned and doesnt end up trying to grab the highest height just to orphan and remain unsynced.

Again, this is not true. A "higher block count" doesn't matter if these blocks are not valid.

If the chain contains 5 more blocks of 3 MB, and your node considers only blocks smaller than 1MB, these blocks are simply invalid. You don't consider them.

nodes see the highest block height. request the data. and then realise its a rule breaker and orphan it.
nodes see the highest block height. request the data. and then realise its a rule breaker and orphan it.
(endless orphan clusterf*ck where the node never syncs)

Quote from: dinofelis on March 09, 2017, 04:15:27 PM

You keep the last block of 1 MB as the highest one. The miners keeping with the old protocol will do the same, and build on this block. So you will now accept this next block. And the next 1 MB block. And the next and still the next. You are on the old protocol chain.

for a node to get this (lower 1mb block) it needs to sever communication with the chain thats 5blocks higher.. then it only see's the 1mb block as the highest height to then sync to that. without the orphan drama

Quote from: dinofelis on March 09, 2017, 04:15:27 PM

On the other hand, a BU node will accept these 5 extra blocks as valid. It will consider the 1MB block next to it as orphaned. and the next one and the next one. Because if BU has more hash power, the chain built on the 3 MB blocks which you consider valid is growing with more PoW. You are on the new butcoin chain. And there's no confusion. A BU node will only accept the BU chain (and orphan the old bitcoin branch). A bitcoin non-BU node will only accept the bitcoin blocks of < 1MB, and consider the other blocks as invalid blocks. Whether they communicate or not.

your thinking too 2-dimensional. one argument your only considering the rules. next argument your only considering hashrate. next argument you only considering blockheight. next your only considering pools and next your only considering nodes.

your not running multi-dimensional scenarios where all aspects interplay

bitcoin has many dimensions that all enforce each other.(as thats the masterpiece of why bitcoin consensus works) and come to the conclusion of(soft or hard):
not banning= orphans and unsynced(dead) nodes for minority
banning= no orphans and minority nodes synced to a less higher chain because you cant see the opposition, thus able to build a second chain without a fight

Quote from: dinofelis on March 09, 2017, 04:15:27 PM

But you should seriously distinguish between a soft fork and a hard fork.

i have many times. its you that over use soft and hard like there are only 2 results

Quote from: franky1 on February 27, 2017, 08:40:07 PM

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