Bitcoin Forum
December 12, 2017, 05:41:09 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9]  All
  Print  
Author Topic: What happens if BU fails VS What happens if SegWit fails  (Read 6184 times)
dinofelis
Hero Member
*****
Offline Offline

Activity: 714


View Profile
March 09, 2017, 07:43:02 PM
 #161

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.
1513057269
Hero Member
*
Offline Offline

Posts: 1513057269

View Profile Personal Message (Offline)

Ignore
1513057269
Reply with quote  #2

1513057269
Report to moderator
1513057269
Hero Member
*
Offline Offline

Posts: 1513057269

View Profile Personal Message (Offline)

Ignore
1513057269
Reply with quote  #2

1513057269
Report to moderator
1513057269
Hero Member
*
Offline Offline

Posts: 1513057269

View Profile Personal Message (Offline)

Ignore
1513057269
Reply with quote  #2

1513057269
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513057269
Hero Member
*
Offline Offline

Posts: 1513057269

View Profile Personal Message (Offline)

Ignore
1513057269
Reply with quote  #2

1513057269
Report to moderator
1513057269
Hero Member
*
Offline Offline

Posts: 1513057269

View Profile Personal Message (Offline)

Ignore
1513057269
Reply with quote  #2

1513057269
Report to moderator
franky1
Legendary
*
Offline Offline

Activity: 1876



View Profile
March 09, 2017, 09:21:57 PM
 #162

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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Don't take any information given on this forum on face value. Please do your own due diligence & respect what is written here as both opinion & information gleaned from experience. If you wish to seek legal FACTUAL advice, then seek the guidance of a LEGAL specialist.
dinofelis
Hero Member
*****
Offline Offline

Activity: 714


View Profile
March 09, 2017, 09:31:57 PM
 #163


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.

Quote
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.

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

Quote
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
Hero Member
*****
Offline Offline

Activity: 700


View Profile
March 09, 2017, 09:56:32 PM
 #164

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
Sr. Member
****
Offline Offline

Activity: 280


View Profile
March 09, 2017, 10:01:39 PM
 #165

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
Legendary
*
Offline Offline

Activity: 1876



View Profile
March 09, 2017, 10:03:39 PM
 #166

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

Quote from: franky1
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.
Quote from: franky1
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

Quote from: franky1
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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Don't take any information given on this forum on face value. Please do your own due diligence & respect what is written here as both opinion & information gleaned from experience. If you wish to seek legal FACTUAL advice, then seek the guidance of a LEGAL specialist.
dinofelis
Hero Member
*****
Offline Offline

Activity: 714


View Profile
March 10, 2017, 06:12:43 AM
 #167

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.

Quote
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
Sr. Member
****
Offline Offline

Activity: 280


View Profile
March 10, 2017, 07:42:08 AM
 #168

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
Legendary
*
Offline Offline

Activity: 1372


Activity: 9001 == OP


View Profile WWW
March 10, 2017, 07:52:05 AM
 #169

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.
Pages: « 1 2 3 4 5 6 7 8 [9]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!