What happens if BU fails VS What happens if SegWit fails

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

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)

But of course not.  For the old nodes, B1 and B2 are simply invalid blocks.  So their height is at 460001.  If I send an invalid block to another node, I suppose he's simply going to reject it, no ?  Otherwise, I can bring down the whole bitcoin network by making 5000 successive bogus invalid blocks with erroneous hashes (not difficult) and tell the whole bitcoin network that we are 5000 blocks ahead ?   Everything comes to a grinding halt with such a simple attack ?

Of course not.  B1 and B2 are simply considered invalid blocks by old nodes.   The old nodes will all agree that they are at height 460001.  And those nodes receiving blocks B1 and B2 will reject them, and not even propagate them.  But all BU nodes will accept them, propagate them, and their counter will be at 460003.  An old node asking a BU node to send him the blocks, will conclude that this node is "confused".  Otherwise, I can bring down the whole bitcoin network with one single "confused" node 5000 fake blocks in the future.

Period.

[franky1]

But of course not.  For the old nodes, B1 and B2 are simply invalid blocks.  So their height is at 460001.  If I send an invalid block to another node, I suppose he's simply going to reject it, no ?  

LOL
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it

thus not syncing and A being stuck at 46000A1..
but the B nodes keep growing.

no way would B drop 460003 to go back to 460001
if B accept and happy with 460002B1 460003b2 they continue with it
A stuck at 460001

A then has to decide to:
continue in orphan hell of rejecting B
stay stalled by just turn node off
upgrade and join B
or ban B to not see 460003 and instead able to build on A

Otherwise, I can bring down the whole bitcoin network by making 5000 successive bogus invalid blocks with erroneous hashes (not difficult) and tell the whole bitcoin network that we are 5000 blocks ahead ?   Everything comes to a grinding halt with such a simple attack ?

now your just making up fairy tales. because they would just not be accepted either.. nothing to do with height. but about not meeting rules.

Of course not.  B1 and B2 are simply considered invalid blocks by old nodes.  

invalid to A which leaves A stuck (B accepts them so B continues)

The old nodes will all agree that they are at height 460001.

no old nodes will see its peers are at 460003. and keep trying to get it to sync to it. but then reject what it gets to be left at 460001a
leading to sync issues.
forcing the user to decide.
join B(upgrading software)
be a numbskull just remaining unsynced requesting and rejecting
ban B to grow A because if A grew A without a ban if A made 460002.. the nodes will still be looking to grab 460003B and rejecting 460002A

And those nodes receiving blocks B1 and B2 will reject them, and not even propagate them.  But all BU nodes will accept them, propagate them, and their counter will be at 460003.

now your getting it

An old node asking a BU node to send him the blocks, will conclude that this node is "confused".  Otherwise, I can bring down the whole bitcoin network with one single "confused" node 5000 fake blocks in the future.
Period.

now your getting it.

leading to sync issues for A.
forcing the user to decide.
join B(upgrading software)
be a numbskull just remaining unsynced requesting and rejecting
ban B to grow A

[dinofelis]

But of course not.  For the old nodes, B1 and B2 are simply invalid blocks.  So their height is at 460001.  If I send an invalid block to another node, I suppose he's simply going to reject it, no ?  Otherwise, I can bring down the whole bitcoin network by making 5000 successive bogus invalid blocks with erroneous hashes (not difficult) and tell the whole bitcoin network that we are 5000 blocks ahead ?   Everything comes to a grinding halt with such a simple attack ?

Of course not.  B1 and B2 are simply considered invalid blocks by old nodes.   The old nodes will all agree that they are at height 460001.  And those nodes receiving blocks B1 and B2 will reject them, and not even propagate them.  But all BU nodes will accept them, propagate them, and their counter will be at 460003.  An old node asking a BU node to send him the blocks, will conclude that this node is "confused".  Otherwise, I can bring down the whole bitcoin network with one single "confused" node 5000 fake blocks in the future.

Period.

LOL
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it
and then
A see it as invalid. but then they look over the network and see others have 460,003 so request it. then realise its B2 again.. and reject it

thus not syncing and A being stuck at 46000A1..

Of course, because the A chain is NOT ANY LONGER.  So A "being stuck at 460001" is perfectly normal, it is the longest chain that is in agreement with A's protocol.

but the B nodes keep growing.

no way would B drop 460003 to go back to 460001
if B accept and happy with 460002B1 460003b2

Of course.

A stuck at 460001

Because that was the longest A chain up to that point.

But now, an A-miner has released a second A block, built upon 460001 (because that miner, too, has an A node that has as a longest chain, the one with 460001, and has mined a block on top of it).

That A-miner now broadcasts his block 460002A2.  This is relayed by all A-type nodes.  When your "stuck" A-type node receives this block, he accepts it, and is now at 460002A2, *like he should* because that's now the longest A-compatible chain.  B nodes consider this an orphaned block, and don't include it (and most probably don't propagate it either).

A then has to decide to:
continue in orphan hell of rejecting B
stay stalled by just turn node off
upgrade and join B
or ban B to not see 460003 and instead able to build on A

Well, of course, he will do the last thing, and take block 460002A2 when it becomes available.  Nothing difficult.
That the A-node, with its longest chain up to 460001A1 was "wasting its time checking B blocks" is not a problem, it HAD the longest possible chain for him at that point.  When it receives the next A block, it adds it.  As it should.

No "orphan drama". 

A nodes build the A chain.  BU nodes build the B chain.

[bitart]

How an Average Joe (like me) can avoid to get in touch with a B type of node? Does it depend on the wallet type I use or it depends on the physical location, if there is only B type nodes around me?
As far as I understood, now there are already nodes in the system, upgraded their software to be able to produce larger blocks (but not yet produced any, because they're waiting for being majority)
What can I do if I want to ensure the safety of my coins and transactions? Can I choose a wallet that only communicate only to old A nodes?
Or wallets are just put the transactions into the pool and the mining node selects the transactions they want to mine for the fee offered?
Is it possible to check if any of my earlier transaction's blocks have been mined by a node with 'upgraded' software? Just to be on the safe side, if chain forks...
Or, the software of the node doesn't matter as long as they produce only normal size blocks?
I'm all ears...

[Senor.Bla]

How an Average Joe (like me) can avoid to get in touch with a B type of node? Does it depend on the wallet type I use or it depends on the physical location, if there is only B type nodes around me?
As far as I understood, now there are already nodes in the system, upgraded their software to be able to produce larger blocks (but not yet produced any, because they're waiting for being majority)
What can I do if I want to ensure the safety of my coins and transactions? Can I choose a wallet that only communicate only to old A nodes?
Or wallets are just put the transactions into the pool and the mining node selects the transactions they want to mine for the fee offered?
Is it possible to check if any of my earlier transaction's blocks have been mined by a node with 'upgraded' software? Just to be on the safe side, if chain forks...
Or, the software of the node doesn't matter as long as they produce only normal size blocks?
I'm all ears...

You are fin so far and if a fork occurs you'll have Bitcoins on both chains. Just make sure you have the private key or else they are not your coins anyway. Information will be everywhere if a fork happens and when you want to decide if you just want to be on one chain. Which chain this should be will be best answer then, since we will have more informations about stuff we have to anticipate/guess right now.

[franky1]

Of course, because the A chain is NOT ANY LONGER.  So A "being stuck at 460001" is perfectly normal,

your getting it

it is the longest chain that is in agreement with A's protocol.

and now you lost yourself again.
A is not the longest chain.. u just said it yourself its not.. just one sentance prior.
the only way for 460001a to be the longest chain.. is to not see any peers with 460003b.. which involves .... BANNING B nodes

but the B nodes keep growing.
no way would B drop 460003 to go back to 460001
if B accept and happy with 460002B1 460003b2

Of course.

A stuck at 460001

Because that was the longest A chain up to that point.

only if A has banned B

But now, an A-miner has released a second A block, built upon 460001 (because that miner, too, has an A node that has as a longest chain, the one with 460001, and has mined a block on top of it).

only if A has banned B
other wise A sees 460002A and 460003B and still sees 460003B as the highest height and keeps requesting what B has as they have the heighest height.
again resulting in orphans and being stuck even if 460002a exists.
still requesting 460003 because it can see 460003

That A-miner now broadcasts his block 460002A2.  This is relayed by all A-type nodes.  When your "stuck" A-type node receives this block, he accepts it, and is now at 460002A2, *like he should* because that's now the longest A-compatible chain.

unless banning B... 460002A2 is not the longest chain.

i think i am getting where your missing something.
a node doesnt know the contents of a block until it receives it and checks it.

your thinking A sees that 640003 is bad before even downloading it.
sorry but it has to download it to see what it is.

meaning every time it scans the network all it sees is 640003 is highest.
without knowing if its a 640003a or a 640003b unless it requests it to see what it is..

again to avoid getting 640003b it has to ban nodes holding 640003b

A then has to decide to:
continue in orphan hell of rejecting B
stay stalled by just turn node off
upgrade and join B
or ban B to not see 460003 and instead able to build on A

Well, of course, he will do the last thing, and take block 460002A2 when it becomes available.  Nothing difficult.
That the A-node, with its longest chain up to 460001A1

A is only longest if A is all it sees... by banning B nodes

was "wasting its time checking B blocks" is not a problem, it HAD the longest possible chain for him at that point.  When it receives the next A block, it adds it.  As it should.

No "orphan drama".  
A nodes build the A chain.  BU nodes build the B chain.

when it bans B nodes

[dinofelis]

Of course, because the A chain is NOT ANY LONGER.  So A "being stuck at 460001" is perfectly normal,

your getting it

I never said anything else.  Look at earlier posts.

it is the longest chain that is in agreement with A's protocol.

and now you lost yourself again.
A is not the longest chain.. u just said it yourself its not.. just one sentance prior.
the only way for 460001a to be the longest chain.. is to not see any peers with 460003b.. which involves .... BANNING B nodes

You are seriously confused.  Non-valid blocks don't count.  The longest chain is the longest VALID chain.

I will try to explain it in a different way.  Suppose that there are not block, but numbers.  The old protocol accepts prime numbers.  The new protocol accepts uneven numbers.  So the new protocol is a backwards compatible hard fork of the old one.

We had previously.

.... - 13 - 17 - 19 - 23

when the hard fork gets activated.

Now, the new nodes produce 25 - 27, because these are uneven numbers.

The old nodes see:

 - 13 - 17 - 19 - 23 - 25 - 27, but they see that these last two blocks are invalid.

So the longest chain, for the old nodes, is still:

  - 13 - 17 - 19 - 23 STOP.  They regularly get a 25 and a 27, but as these are not prime numbers, they reject them.  As they should.  

However, the new nodes accept:

 - 13 - 17 - 19 - 23 - 25 - 27.  That's a different chain.

My analogy breaks down at the next step, because the "29" for one chain will not be the 29 for the other, as it contains the hash of the previous one with blocks which doesn't work with numbers.

For the A nodes, "25 and 27" are not "orphaned", or whatever, they are simply INVALID blocks, and the A miners will mine upon 23, the highest block in their chain, and will build a 29a,  while the new nodes will make a 29b, built upon 27, which is the highest valid block in THEIR chain.

When old nodes receive the 29b block, they will reject it, because it is not built upon a previously valid block (it is built upon 27, which was not a previously valid block), and when new nodes receive 29a, they will think it is an orphaned block built after 23, while they are already at 27 at that point, so they orphan it and don't include it.

So each node builds its own chain correctly.

old nodes will see: - 13 - 17 - 19 - 23 - 29a  (and reject 25, 27 and 29b as invalid)
new nodes will see - 13 - 17 - 19 - 23 - 25 - 27 - 29b  (and reject 29a as orphaned)


No banning is needed.  But banning may help avoid "noise on the line".  The connections between old nodes and new nodes are useless, add some noise, but are not harmful.

If, say, the split is 75% - 25% then if each node connects randomly to 8 other nodes, he'll have on average 6 B nodes and 2 A nodes.  An A node receives only noise from B nodes, and a B node receives only noise from A nodes.  So the only links that bring useful information, is between equally minded nodes.  But the other nodes are just seen as "confused" or "behind", sending only orphaned blocks, or sending only invalid blocks.

[Senor.Bla]

Anybody here that could provide the peace of code that is in dispute? I'm not that familiar with the Bitcoin code yet, but this might help to understand. And also the question goes along, if they are different in Core and BU.

[freedomno1]

1. BU gets the support and we all hard fork to BU, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? Another fork? Can we still go to SegWit at this point? Something else?

We move to a different blockchain and have two competing coins which both can be considered Bitcoin, Bitcoin A is the BU fork while Bitcoin B is the familiar Bitcoin we had pre-fork.

On both assuming the transaction was not in the mempool and unconfirmed at that time of the fork you will have a balance on both A and B or in effect the coins are doubled and depending on if a Bitcoin exchange accepts A and B you can sell both sides of the coin or the one you believe will become the most utilized chain in the future.

Future disputes may result in code changes but probably not force another fork in the short-term as consolidation occurs around the new chain.

(Assuming a Bi-lateral fork, else .... stuff happens we don't want to discuss but sum up as Core ate it and all the history from fork on is null) Replaced with Core or the reverse with orphan blocks everywhere ...

2. SegWit gets the support and we all soft fork to SegWit, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? A hard fork? Can we still go to BU at this point? Something else?

Assuming that the BU fork moves sufficient users, demand may drop temporarily on the main chain as it moves to BU Hard Fork.

Some miners will also move and the ones remaining that operate may be the ones in favor of Segwit hence Segwit would be able to acquire consensus and a soft-fork would be approved by the remaining network unless sufficient factions still remain to not reach the soft-fork target.
Lightning activates later


3rd Scenario: Nothing happens for now.
4th Scenario: Alternative proposals that adjust the weight of each actor in Bitcoin gains support and becomes a new option.