Topic: What happens if BU fails VS What happens if SegWit fails (Read 6384 times)

your getting it

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


only if A has banned B

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


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 is only longest if A is all it sees... by banning B nodes



when it bans B nodes

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.

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

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.


Of course.


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


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.

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


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.

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


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

now your getting it
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

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.

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

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.

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.

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

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.

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.

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


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.


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

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

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.

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.

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)

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

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.