What happens if BU fails VS What happens if SegWit fails

[franky1]

1. BU does not cause bilateral fork. LEARN CONSENSUS

Yes it does cause a split. You are mistaken.

He is mistaken, but for different reasons. BU is a unilateral split. If, after BU pulls the trigger on their hard fork, the Core chain ever overtakes the BU chain, all BU coins will be permanently destroyed and all transactions involving them will be forever invalid. Mass panic will ensue and their altcoin will be worthless. That's why Core devs are begging BU to make their fork bilateral, but they won't listen (or they pretend not to listen because they don't have the competence to implement a bilateral fork).

if BU pulls the trigger.. it would do it with majority NODE (over50%) and majority hash(over 50%)
it wont trigger without consensus.

also all that occurs is a orphan  which will inevitably and naturally find a single chain.
at a small majority (say 51-60%) just means clusterf*ck of orphan drama.
at a high majority (say 80-95%) just means less orphan drama
at superhigh majority (say 95%) just meand bearable amount of orphan drama, slightly above what happens daily anyway

just taking longer(more orphans) with lower amount of majority to get a single reliable chain

the only way to get the 2 chains to independantly survive is to intentionally ban communications with the opposition. which is what happened in ethereum

oh and emphasis on majority.. which also bursts your bubble of core overtaking lol (learn consensus please)

[dinofelis]

People don't seem to understand the fundamentals of crypto !

If you *remove the 21M coin limit* your chain is NOT COMPATIBLE with bitcoin, so of course it will not be bitcoin.  You have invalid blocks according to bitcoin's protocol !  You have simply produced an altcoin that is not recognized by the bitcoin protocol.

What about removing the *1 MB block size limit*?

Well, then you ALSO create an (incompatible) alt coin.  That's what a hard fork is: to create an alt coin.  

Nobody is "trying to harm" anything.  Consensus mechanism, nothing else.

I don't think you are informed on the background of these actors nor their motivations.

But that is part of the "consensus mechanism".  Having different motives, and wanting to "pull the blanket to your side" is exactly what the distributed consensus mechanism is about.  The impossibility of collusion over "pulling the blanket to your side" is exactly the origin of the immutability.  As one cannot agree on WHICH SCAM to propagate, no scam is propagated: immutability.

Distributed TRUSTLESS consensus is the putting together of sufficiently many and diverse scammers, that they cannot agree upon a single scam.  That is the essence of distributed consensus, providing you with immutability.

[dinofelis]

1. BU does not cause bilateral fork. LEARN CONSENSUS

Yes it does cause a split. You are mistaken.

He is mistaken, but for different reasons. BU is a unilateral split. If, after BU pulls the trigger on their hard fork, the Core chain ever overtakes the BU chain, all BU coins will be permanently destroyed and all transactions involving them will be forever invalid. Mass panic will ensue and their altcoin will be worthless. That's why Core devs are begging BU to make their fork bilateral, but they won't listen (or they pretend not to listen because they don't have the competence to implement a bilateral fork).

if BU pulls the trigger.. it would do it with majority NODE (over50%) and majority hash(over 50%)
it wont trigger without consensus.

You are seriously confused about this aspect.  There is no "majority hash rate consensus" between INCOMPATIBLE CHAINS.  The only thing you do with your 51% hash rate is to produce INVALID BLOCKS wrt the original protocol.  So this PoW doesn't matter, the blocks are invalid.  If you produce 1.5 MB blocks with a PoW that is more than 10 times all the PoW that ever went into bitcoin, then these blocks doesn't count because they are simply INVALID.  The old protocol simply rejects them (in the same way as if they were containing wrong signatures in the transactions).  The only valid blocks (wrt the old protocol) are those, mined with the 49% hash rate of the miners sticking to the old protocol.

But the new protocol can continue building on its own chain with bigger blocks.  

Of course, as long as BU accepts also old-protocol blocks, they need 51% of the hash rate, or the old chain (which is VALID under the new BU protocol if they don't protect themselves) will take over.  In fact, in this case, you can see the old protocol as a soft fork from the BU protocol, which can IMPOSE its will when it is majority.  In order to avoid that, BU should make the old protocol invalid too, so that ONLY BU blocks are compatible with BU.  Maybe they could flip a little-endian/big-endian convention somewhere, so that both are fully incompatible.  Otherwise, they risk at any moment to be killed by the "soft fork" of the old protocol.

[AliceWonderMiscreations]

1. BU does not cause bilateral fork. LEARN CONSENSUS

Yes it does cause a split. You are mistaken.

He is mistaken, but for different reasons. BU is a unilateral split. If, after BU pulls the trigger on their hard fork, the Core chain ever overtakes the BU chain, all BU coins will be permanently destroyed and all transactions involving them will be forever invalid. Mass panic will ensue and their altcoin will be worthless. That's why Core devs are begging BU to make their fork bilateral, but they won't listen (or they pretend not to listen because they don't have the competence to implement a bilateral fork).

if BU pulls the trigger.. it would do it with majority NODE (over50%) and majority hash(over 50%)
it wont trigger without consensus.

You are seriously confused about this aspect.  There is no "majority hash rate consensus" between INCOMPATIBLE CHAINS.  The only thing you do with your 51% hash rate is to produce INVALID BLOCKS wrt the original protocol.  So this PoW doesn't matter, the blocks are invalid.  If you produce 1.5 MB blocks with a PoW that is more than 10 times all the PoW that ever went into bitcoin, then these blocks doesn't count because they are simply INVALID.  The old protocol simply rejects them (in the same way as if they were containing wrong signatures in the transactions).  The only valid blocks (wrt the old protocol) are those, mined with the 49% hash rate of the miners sticking to the old protocol.

But the new protocol can continue building on its own chain with bigger blocks.  

Non BU blocks are still 100% compatible with BU so if BU doesn't have more than 50% of hash power, the fork will fail untless BU miners intentionally filter the non BU nodes. The only way for a fork to be successful is if the BU miners mine a block > 1 MB and have 51%+ of the hash power. Personally I'll wait until 18 blocks longer before I really consider the fork successful.

[franky1]

Well, then you ALSO create an (incompatible) alt coin.  That's what a hard fork is: to create an alt coin. 

nope.
your over using the umbrella term hard fork but not understanding the categories within the hard vs soft.
save rewriting to repeat myself

in short
soft=pools only
hard= NODES then pools
save repeating myself:

below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split
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 only blockstream lovers stopped reading the doomsday scripts on reddit and the fake promise sales pitches.. and instead learned bitcoin especially consensus and bitcoins natural safeguard of consensus via orphans.. they would actually help themselves more and start giving real support to the community. rather than just kissing blockstream ass.

note to all blockstream loving doomsdayers
learn consensus

[dinofelis]

Non BU blocks are still 100% compatible with BU so if BU doesn't have more than 50% of hash power, the fork will fail untless BU miners intentionally filter the non BU nodes. The only way for a fork to be successful is if the BU miners mine a block > 1 MB and have 51%+ of the hash power. Personally I'll wait until 18 blocks longer before I really consider the fork successful.

Yes, you are right (see the edit of my previous post).  This "backward compatibility" of BU with respect to the standard protocol makes that the standard protocol is a soft fork of BU.  Then they expose themselves AT ANY MOMENT to be orphaned, even 6 months later, if ever the BU fork falls beneat 51% hash rate.  Then you will get the bitcoin chain orphaned 6 months behind, because from the first >1MB onwards, the soft fork is not compatible any more, and this will be the last valid block on the chain.  Major clusterfuck !

The only safe way of making the BU hard fork, is by making it incompatible with the old protocol.  If they don't do this, and they "pull the trigger", this will be a major disaster on the chain.

[franky1]

You are seriously confused about this aspect.  There is no "majority hash rate consensus" between INCOMPATIBLE CHAINS.  The only thing you do with your 51% hash rate is to produce INVALID BLOCKS wrt the original protocol.  So this PoW doesn't matter, the blocks are invalid.  If you produce 1.5 MB blocks with a PoW that is more than 10 times all the PoW that ever went into bitcoin, then these blocks doesn't count because they are simply INVALID.  The old protocol simply rejects them (in the same way as if they were containing wrong signatures in the transactions).  The only valid blocks (wrt the old protocol) are those, mined with the 49% hash rate of the miners sticking to the old protocol.

But the new protocol can continue building on its own chain with bigger blocks.  

Of course, as long as BU accepts also old-protocol blocks, they need 51% of the hash rate, or the old chain (which is VALID under the new BU protocol if they don't protect themselves) will take over.  In fact, in this case, you can see the old protocol as a soft fork from the BU protocol, which can IMPOSE its will when it is majority.  In order to avoid that, BU should make the old protocol invalid too, so that ONLY BU blocks are compatible with BU.  Maybe they could flip a little-endian/big-endian convention somewhere, so that both are fully incompatible.  Otherwise, they risk at any moment to be killed by the "soft fork" of the old protocol.

Non BU blocks are still 100% compatible with BU so if BU doesn't have more than 50% of hash power, the fork will fail untless BU miners intentionally filter the non BU nodes. The only way for a fork to be successful is if the BU miners mine a block > 1 MB and have 51%+ of the hash power. Personally I'll wait until 18 blocks longer before I really consider the fork successful.

Yes, you are right (see the edit of my previous post).  This "backward compatibility" of BU with respect to the standard protocol makes that the standard protocol is a soft fork of BU.  Then they expose themselves AT ANY MOMENT to be orphaned, even 6 months later, if ever the BU fork falls beneat 51% hash rate.  Then you will get the bitcoin chain orphaned 6 months behind, because from the first >1MB onwards, the soft fork is not compatible any more, and this will be the last valid block on the chain.  Major clusterfuck !

The only safe way of making the BU hard fork, is by making it incompatible with the old protocol.  If they don't do this, and they "pull the trigger", this will be a major disaster on the chain.

YOUR FORGETTING NODES aswell as POOL
learn real consensus

also your forgetting without banning communications. the minority see the blockheight. but then orphan it because the rules dont match.
then see the blockheight.. but then orphan it because the rules dont match.
then see the blockheight.. but then orphan it because the rules dont match.
then see the blockheight.. but then orphan it because the rules dont match.
endlessly.

BU wont ban the other community nodes.. only blockstream would ban the community nodes.
and that would only happen if blockstream were minority. because the community wont trigger unless they had majority.

and thats what blockstream fears.. losing their control where by the dozen other independant node brands continue.

remember and learn consensus

The only safe way of making the BU hard consensus, is by high majority  If they don't do this, and they "pull the trigger", this will be a major disaster on the chain. with orphans. which eventually settles down to a single chain
leading to the minority either:
not syncing and just orphaning everything (dead in the water)
having to change their own protocol to match(re-joining the consensus community)
intentionally banning away from the majority to not see the higher blockheight and orphans to then build ontop of their MINORITY

FTFY

[AliceWonderMiscreations]

If a fork appears, I suspect we'll quickly see a new version of core with support for bigger blocks because they still want SegWit. So a BU fork may result in an actual compromise.

[dinofelis]

Well, then you ALSO create an (incompatible) alt coin.  That's what a hard fork is: to create an alt coin. 

nope.
your over using the umbrella term hard fork but not understanding the categories within the hard vs soft.
save rewriting to repeat myself

in short
soft=pools only
hard= NODES then pools
save repeating myself:

below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split
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

You are simply wrong on this.

A hard fork without a strong consensus ALWAYS leads to two coins.

A soft fork with a majority consensus amongst miners ALWAYS imposes its rules and one chain emerges.

A hard fork is defined as a modification in the protocol, so that new blocks under the hard fork are not valid under the old protocol.  You still have two cases: the hard fork can be backward compatible, so that blocks under the old protocol are still valid under the new protocol (call it a backward compatible hard fork), or you can have a genuine hard fork that is entirely incompatible.

A soft fork is defined as a modification in the protocol, so that new blocks under the soft fork are still valid under the old protocol, but that blocks under the old protocol aren't valid any more under the new protocol.

Case of a soft fork:
- if a minority of miners adopts it, not really an effect.
- if a majority of miners adopts it, it is IMPOSED UPON the others.  A single chain is always the result.  The user has no choice.

Case of a full hard fork:
- from the moment a non-negligible fraction of the miners adopts it, TWO COINS emerge.  The market will split the market cap over the two coins, and miners will follow that ratio.  It is possible that the market entirely kills one of the coins, or that essentially ALL miners adopt it: ---> consensus is preserved.  ONLY IN THIS CASE, a single chain emerges (the "alt coin" in case of full consensus).

Case of a backward compatible hard fork:
the old protocol can be seen as a soft fork from the hard fork.  
- As such, as long as the old protocol remains a majority, this "soft fork" remains imposed, the hard fork cannot happen.  
- if the hard fork is majority, it can split the chain into two coins, like a full hard fork.
However, if the hard fork loses majority, the second chain becomes a major orphan, and is taken over by the old protocol chain (can be six months later)  --> super cluster fuck.

[dinofelis]

YOUR FORGETTING NODES aswell as POOL
learn real consensus

Non-mining-related nodes don't matter.   Transactions will reach mining nodes/pools.  Non-mining nodes are only interesting for its owner, to see the block chain for himself, and verify its validity without having to trust another full node.  But full nodes that do not relate to mining don't matter in the consensus mechanism.

Everybody can fire up 100 000 nodes on amazon if he/she wants to.

What does matter, are users.  They 'vote with their money' and determine market cap.

[franky1]

Non-mining-related nodes don't matter.   Transactions will reach mining nodes/pools.  Non-mining nodes are only interesting for its owner, to see the block chain for himself, and verify its validity without having to trust another full node.  But full nodes that do not relate to mining don't matter in the consensus mechanism.

What does matter, are users.  They 'vote with their money' and determine market cap.

you have been sold alot of BS
1. exchanges are the nodes. if they orphan block X.. your TX in that block doesnt exist = you cant spend because they dont see it
2. if a friend is using a node and you pay that friend. if they orphan block X.. your tx in that block doesnt exist  = you cant spend because they dont see it

with each node calling out the blockheight. they all grab data from the highest block height. if that blockheight is blocks of rules that dont match
then they orphan those blocks. and end up unsynced.

the only way to sync is either change your rules to rejoin the majority.
or.
BAN the majority to not see the block height to not be endlessly clusterfu*ked to then start building on a minority that you can accept.
if you dont ban. your minority is not treated as a valid chain due to it not having the height.

its a security feature.
otherwise someone could copy the blockchain. kill off say 2 years of blockheight and then just build ontop of it.(at a healthier difficulty) and then build their own chain
but that requires not communicating with the rest of the network by banning the nodes following the highest blockheight, so that the blockheight mechanism doesnt kill off the minority due to the minority height reject mechanism.

like i said many times it involves intentionally banning nodes to not see a bigger height. otherwise orphan games begin fighting over the rules

[AngryDwarf]

Non-mining-related nodes don't matter.   Transactions will reach mining nodes/pools.  Non-mining nodes are only interesting for its owner, to see the block chain for himself, and verify its validity without having to trust another full node.  But full nodes that do not relate to mining don't matter in the consensus mechanism.

What does matter, are users.  They 'vote with their money' and determine market cap.

you have been sold alot of BS
1. exchanges are the nodes. if they orphan block X.. your TX in that block doesnt exist = you cant spend because they dont see it
2. if a friend is using a node and you pay that friend. if they orphan block X.. your tx in that block doesnt exist  = you cant spend because they dont see it

with each node calling out the blockheight. they all grab data from the highest block height. if that blockheight is blocks of rules that dont match
then they orphan those blocks. and end up unsynced.

the only way to sync is either change your rules to rejoin the majority.
or.
BAN the majority to not see the block height to not be endlessly clusterfu*ked to then start building on a minority that you can accept.
if you dont ban. your minority is not treated as a valid chain due to it not having the height.

its a security feature.
otherwise someone could copy the blockchain. kill off say 2 years of blockheight and then just build ontop of it.(at a healthier difficulty) and then build their own chain
but that requires not communicating with the rest of the network by banning the nodes following the highest blockheight, so that the blockheight mechanism doesnt kill off the minority due to the minority height reject mechanism.

like i said many times it involves intentionally banning nodes to not see a bigger height. otherwise orphan games begin fighting over the rules

Such a mass banning of the nodes would effectively be creating a private network, would it not? (Although coordination levels would probably have to be 100% to prevent leaking between networks through a node)

[dinofelis]

Non-mining-related nodes don't matter.   Transactions will reach mining nodes/pools.  Non-mining nodes are only interesting for its owner, to see the block chain for himself, and verify its validity without having to trust another full node.  But full nodes that do not relate to mining don't matter in the consensus mechanism.

What does matter, are users.  They 'vote with their money' and determine market cap.

you have been sold alot of BS
1. exchanges are the nodes. if they orphan block X.. your TX in that block doesnt exist = you cant spend because they dont see it
2. if a friend is using a node and you pay that friend. if they orphan block X.. your tx in that block doesnt exist  = you cant spend because they dont see it

You are talking about USERS, not "nodes".   Again, we have to distinguish several cases.  Suppose that we have a full hard fork (not backwards compatible).  If my friend, or my exchange, is using a "node only compatible with variant X", then it simply means they are only accepting COIN X.  If I try to pay them with coin Y, it won't work of course.  That's like as if I tried to pay a bitcoin user with Ethereum.  So the full hard fork case is easy: we're simply talking about different COINS.

Now, suppose that we talk about a soft fork.  If the soft fork has a majority amongst miners, that soft fork is simply imposed upon all miners.  Simply because every non-soft forked miner will always produce orphaned blocks, because they are considered invalid by the majority of miners.  So his only chance of getting accepted blocks on the longest chain, is also to apply the soft fork conditions.  The users nor the nodes have anything to say about it, because there's only ONE CHAIN.  They accept it, or they come to a grinding halt.  A soft fork with a majority of miners is IMPOSED upon everybody: the minority miners, the users, and the nodes.  Nodes with both protocols will accept the chain, and it *doesn't matter* what protocol they run.

Now, suppose that the soft fork is in a minority amongst miners.  That means that the majority of miners will regularly put blocks on the chain that are not accepted by the soft fork, but this will be *the only chain* that is available.  If your node is running soft-forked software, then it will simply REJECT the sole chain that exists.  But no acceptable chain will be around.  Because majority-non-soft-forked miners will still add blocks to the longest chain, and the "pure soft fork chain" will not exist.  So your node COMES TO A GRINDING HALT if it is soft-forked.  

The case of the backward-compatible hard fork looks more involved.  As long as the hard fork has a majority of mining hash rate, BOTH COINS exist.  If you want to pay a friend in "hard forked coin", you have to send "hard forked coin".  It is ANOTHER coin (an alt coin), and of course if you try to send him your original coin, it will not work.  Idem for an exchange.  A hard fork that remains a majority is similar to a full hard fork: TWO COINS exist now with separate block chains, transactions, wallets and everything.  If an exchange, a user, .... only decides to use ONE of the coins, then you have to use THAT COIN to pay him.

It becomes a major cluster fuck if the hard fork that had majority, loses this majority (determined by MARKET CAP, and miners that will follow to optimize their block rewards).  After a while, the old chain will become the longest one, and because the hard fork is backward compatible, the former hard forked chain STOPS and is orphaned.  Every wallet there is then simply LOST, and all transactions on that chain are REVERSED.

[dinofelis]

Such a mass banning of the nodes would effectively be creating a private network, would it not? (Although coordination levels would probably have to be 100% to prevent leaking between networks through a node)

Which is impossible.  Valid transactions on one network will ALWAYS end up reaching the miners on the other network if these transactions are also valid there.  We saw this with ETC/ETH.  Miners on the other network have all incentive to process these transactions to collect the fees in *their* coin.  In the end, they go and READ THE OTHER public BLOCK CHAIN to get the transactions on their chain.

[franky1]

dinofelis

you cant have 2 chains that inter communicate. the nodes would orphan one chain off and the network then follows the chain with the highest height

they would need to ban each other. meaning you get to spend coins on Y while holding onto coins on X, without having to worry about spending coins on Y being broadcast to also spend it on X

thats why eth and etc dont co mingle.


for instance clams is a clone of BTC.. but ever since they banned communication with btc to create the alt, the transactions i do on btc do not end up in a block on clams.(even if the tx data is the same and the UTXO is the same) they dont broadcast between each other because they intentionally banned communication with btc.

if clams was to inter connect to see the tx's being relayed. then the clusterf*ck of orphans would occur because thats a consensus safety mechanism. leading to there being just one chain and a clusterf*ck of orphans fighting over who can or cannot get to be the next block ontop of the blockheight.
where by the pools and nodes are not building ontop of height say 400k if they see that there is a 460k height available they would build ontop of the heighest height and the network will accept the highest height

this is why even in segwits softfork, segwit will intentionally ban opposing pools and nodes to avoid the orphan drama and chance of segwit blocks being orphaned out. maning blockstream cause an intentional split. not simply by having hash. but BANNONG BLOCKS AND NODES that are opposing them

it isnt just a simple 'trigger date/% achieved' and thats it.
there is more to it then that

[dinofelis]

dinofelis

you cant have 2 chains that inter communicate. the nodes would orphan one chain off and the network then follows the chain with the highest height

You are entirely confused over this.  With a full hard fork, you have 2 chains, 2 coins.  Call them X and Y.  A node running protocol X, will recognize chain X as valid, and will consider chain Y as invalid.  So this node will only accept chain X, and its wallet will show you your holdings in coin X.  A node running protocol Y will recognize chain Y as valid, and will consider chain X as invalid.  This node will only accept chain Y, and its wallet will shwo you your holdings of coin Y.

Whether one chain has more PoW or not doesn't matter to a node for which that chain is invalid.

they would need to ban each other. meaning you get to spend coins on Y while holding onto coins on X, without having to worry about spending coins on Y being broadcast to also spend it on X

thats why eth and etc dont co mingle.

They don't co-mingle, NOT BECAUSE THEY BAN EACH OTHER.  But because transactions of ETH are not valid on the ETC chain and vice versa.

There WAS a problem when people transacted on the ETC chain, and generated also a valid transaction on the ETH chain, because they used pre-fork UTXO.  This transaction got included in the ETH chain too, and these people had against their wishes, also transacted their ETH holdings.  With ETH this could be solved with a smart contract.  Bitcoin can't do that.  But what you can do, is to obtain some freshly mined coins on one chain, or on the other, and mix them in your transactions.  Then, these coins exist only on one chain, and this transaction is only valid on one chain.  Mere mortals can't do this, but exchanges can.  They only need to make a transaction with some dust included from one after-split coinbase or the other to split the pre-fork coin into an X-coin and a Y-coin.

for instance clams is a clone of BTC.. but ever since they banned communication with btc to create the alt, the transactions i do on btc do not end up in a block on clams.(even if the tx data is the same and the UTXO is the same) they dont broadcast between each other because they intentionally banned communication with btc.

That is ridiculous.  I don't know clams.  But if clams wanted, it could install a bitcoin full node, READ THE BITCOIN BLOCK CHAIN, and include all transactions on the chain in its chain, because the signatures are, according to your saying, correct.

if clams was to inter connect to see the tx's being relayed. then the clusterf*ck of orphans would occur because thats a consensus safety mechanism. leading to there being just one chain and a clusterf*ck of orphans fighting over who can or cannot get to be the next block ontop of the blockheight.

This is again, ridiculous as a safety technique.  Of course clams can see these transactions, they are on a fucking public block chain !

[dinofelis]

this is why even in segwits softfork, segwit will intentionally ban opposing pools and nodes to avoid the orphan drama and chance of segwit blocks being orphaned out

No, this is a normal SOFT fork mechanism.  OF COURSE it 'bans' non-soft-fork blocks: they are INVALID according to the softfork protocol.  That's proper to a soft fork.

A soft fork never makes two chains.  It simply orphans the prongs of the minority if it has a majority.  This has nothing to do with nodes and so on, only with miners.  If a majority of miners applies a soft fork (no matter what soft fork, just ANY extra condition on top of the normal protocol) then minority miners will always get orphaned, until they join the majority, and no matter what node software you run, you will only get the soft fork valid chain.

For instance, if the soft fork simply consists in "including a transaction from Joe's address is considered invalid", and if a majority of miners applies this condition, then the chain that EVERYBODY will see, will never contain a transaction from Joe.  Those minority miners that do accept Joe's transaction, will make blocks that get orphaned by the majority.  So minority miners can chose not to make blocks that contain Joe's transaction (and hence, "apply the soft fork") and be included, or systematically get orphaned.  So in the end, only a chain without Joe's transactions will be available.  Whether or not people run nodes with or without this restriction, doesn't matter.  They will only get a chain without Joe's transaction.

Segwit is the same.

[Lauda]

Do tell me what happens when a BU blocked (not just signaling) is mined with e.g. 1.5 MB block size.

if consensus is not reached.. its orphaned. end of.. in the trash in 3 seconds. no drama no fuss

You have misunderstood the question. I was implying what happens once they have e.g. majority hashrate, which they think alone is sufficient enough to define Bitcoin.

He is mistaken, but for different reasons. BU is a unilateral split. If, after BU pulls the trigger on their hard fork, the Core chain ever overtakes the BU chain, all BU coins will be permanently destroyed and all transactions involving them will be forever invalid. Mass panic will ensue and their altcoin will be worthless. That's why Core devs are begging BU to make their fork bilateral, but they won't listen (or they pretend not to listen because they don't have the competence to implement a bilateral fork).

Oh, that's for the explanation. I just haven't thought about it that much to come to such a realization.

if BU pulls the trigger.. it would do it with majority NODE (over50%) and majority hash(over 50%)
it wont trigger without consensus.

You are seriously confused about this aspect.  There is no "majority hash rate consensus" between INCOMPATIBLE CHAINS.  The only thing you do with your 51% hash rate is to produce INVALID BLOCKS wrt the original protocol.  So this PoW doesn't matter, the blocks are invalid.  If you produce 1.5 MB blocks with a PoW that is more than 10 times all the PoW that ever went into bitcoin, then these blocks doesn't count because they are simply INVALID.  The old protocol simply rejects them (in the same way as if they were containing wrong signatures in the transactions).  The only valid blocks (wrt the old protocol) are those, mined with the 49% hash rate of the miners sticking to the old protocol.

He is most certainly confused and has a flawed understanding of Bitcoin. I can't seem to recall something in my thought process so I thought I'd ask. We know that blocks bigger than 1 MB from chain B would surely get orphaned on chain A. However, what about blocks from chain A being relayed to chain B (considering this would be a 'unilateral split')? I don't see why 1 MB blocks from chain A would get orphaned on chain B under current conditions. Care to elaborate?
Update: I completely forgot about hashPrev. I need some sleep.

[dinofelis]

He is most certainly confused and has a flawed understanding of Bitcoin. I can't seem to recall something in my thought process so I thought I'd ask. We know that blocks bigger than 1 MB from chain B would surely get orphaned on chain A. However, what about blocks from chain A being relayed to chain B (considering this would be a 'unilateral split')? I don't see why 1 MB blocks from chain A would get orphaned on chain B under current conditions. Care to elaborate?

This is where an unilateral split gets tricky, and why BU needs majority hash rate.

Let us say that block A1 is the last common block ( A's are less than 1MB).  BU pulls the trigger at that moment.  What does that mean ?  They mine at least ONE B block, bigger than 1 MB: B1.

We now have: for BU nodes: A1 - B1
However, for old nodes: only A1 (B1 is invalid).

BU has more hash rate.  It now builds a B2.
For BU nodes: A1 - B1 - B2
for old nodes: A1 (both other blocks are invalid).

Now, a "minority miner" mines A2, built on top of A1 (B1 and B2 are invalid blocks for him).

For BU nodes:  2 chains: A1 - B1 - B2  OR: A1 - A2.  First chain has more PoW ("is longer"), so winning chain: A1 - B1 - B2

for old nodes: A1 - A2 (other blocks are invalid)

As BU *has more hash rate* this will continue.

At no point, an "A" miner will build upon the B chain (invalid blocks), and at every point, the BU nodes will see more PoW in the B chain.

But, but, but, drama and catastrophy.  If BU now becomes minority hash.

We have:

A1 - B1 - B2 - B3 - B4 ..... B250

A1 - A2 ..... - A100

For a while, everything goes still well.  But A having more hash rate, it will grow faster.

So after a while, we have:

A1 - B1 - B2 ..... B500
A1 - A2 ..... A-501

BOING!!!

Now, for the BU miners, the A chain is the longest.  They will add their new block to the A chain:

A1 - ...   A-501 - B502

But for the (majority hash rate) A miners, this is an invalid block.

They will also mine an A502 block.  
And then an A503 one on top of that.  B502 gets orphaned.

Next, the BU miners still find:

A1.... A501-A502-A503 a valid and longest chain.

They will add B504 on top of it...

But the A miners will outcompete them with A504 and A505.  B504 gets orphaned....


And the B chain is dead.
Everything that happened on the B chain is as if it never happened.

Unless the B miners decide to implement something that makes it a bilateral split.  A soft fork on B is thinkable, that A doesn't have.

[franky1]

He is most certainly confused and has a flawed understanding of Bitcoin. I can't seem to recall something in my thought process so I thought I'd ask. We know that blocks bigger than 1 MB from chain B would surely get orphaned on chain A. However, what about blocks from chain A being relayed to chain B (considering this would be a 'unilateral split')? I don't see why 1 MB blocks from chain A would get orphaned on chain B under current conditions. Care to elaborate?

This is where an unilateral split gets tricky, and why BU needs majority hash rate.

Let us say that block A1 is the last common block ( A's are less than 1MB).  BU pulls the trigger at that moment.  What does that mean ?  They mine at least ONE B block, bigger than 1 MB: B1.

We now have: for BU nodes: A1 - B1
However, for old nodes: only A1 (B1 is invalid).

BU has more hash rate.  It now builds a B2.
For BU nodes: A1 - B1 - B2
for old nodes: A1 (both other blocks are invalid).

Now, a "minority miner" mines A2, built on top of A1 (B1 and B2 are invalid blocks for him).

this is where your 2-dimensional thinking falls apart.
at this point . without A banning communication with the network
lets use blockheight numbers

For BU nodes: 460,001A1 - 460,002B1 - 460,003B2
for old nodes: 460,001A1 - 460,002A2

ALL nodes will still see 460003 and ask to get it to sync to highest height.
old nodes get the data. and reject it.
old nodes get the data. and reject it.
old nodes get the data. and reject it.
old nodes get the data. and reject it.
(endless orphan drama for minority and not syncing)

to get the old nodes to see 460,002A2 to sync.. they have to avoid seeing 460,003B2 by banning communication.or to get the majority(hashpower to get height) by pushing passed 460,003B2 so that there was a 460,001A1 - 460,002A2 - 460,003A3 - 460,004A4

in which case
ALL nodes  see
460,001A1 - 460,002A2 - 460,003A3 - 460,004A4 as the height
and BU orphan their  - 460,002B1 - 460,003B2 and go with
460,001A1 - 460,002A2 - 460,003A3 - 460,004A4 as the height

because A rules are acceptable to BU.

now.. this is the thing your also forgetting.
although BU 'could' trigger at low majority. POOLS wont trigger with low majority because they know the orphan risk of their own blocks is increased. so they wont trigger unless they know the risk of losing their block reward was little to non.

meaning it will take alot of effort of the minority to try to overtake the majority because the majority would be significantly higher

this is why as of today and for the last 2 years of being on the network, BU has NOT:
banned communication with the network - because they dont want an altcoin (they laughed in gmaxwells face when gmaxwell begged them to 'f**k off'
triggered at low hashrate - because they dont want high orphan risk
this is why as of today and for the last 2 years of being on the network, XT has NOT:
banned communication with the network - because they dont want an altcoin (they laughed in gmaxwells face when gmaxwell begged them to 'f**k off'
triggered at low hashrate - because they dont want high orphan risk
this is why as of today and for the last 2 years of being on the network, classic has NOT:
banned communication with the network - because they dont want an altcoin (they laughed in gmaxwells face when gmaxwell begged them to 'f**k off'
triggered at low hashrate - because they dont want high orphan risk
they want high consensus and will only trigger with high safe consensus

which blockstream is scared of. and has been crying, pleading, fudding, fake doomsdaying, bait and switching, playing victim card of.
while secretly(now public) knowing its only blockstream that will bilaterally split to keep their segwit rules alive (as an alt) rather than just giving up and saying the community just doesnt want it.(if consensus is not reached). or creating the altcoin if consensus is reached to ensure their chain is not overtaken