Updates & Forks - Discussion

This happens when two miners on different geographical locations find a block at approximately the same time and due to distance either of the blocks had time to propagate to the other miner thus creating a split in the chain.
When this happens nodes will accept both blocks and other miners will begin to mine on the block they received first. Once a new block is found it will be appended to one of these blocks and because the chain now has more PoW (is longer) it is considered to be the valid chain due to the longest chain rule and the other block will become stale and its txs returned to the mempool. :slight_smile:

2 Likes

I understand the “what” but Im not sure I understand the “why”. If a new update is issued (and I am not sure where updates come from yet) and the update were to increase the block size from 1mB to 2mB this would make previously invalid blocks valid. According the this lesson this would be a hard fork that would cause a split in the block chain, community. From this day forward you have two separate block chains going forward each with its own community and resources being divided from the once single chain. But Why? Why is this update not propagated to all the nodes and the chain is healed and goes on.
If a new rule is issued that makes valid blocks invalid, all the nodes will eventually update and the chain will be healed and the one chain continues to go on.

2 Likes

As you mentioned: If all nodes update. But what if not all nodes update like most nodes didn’t update to Bitcoin cash when the hardfork occurred and so we now have two separate chains.
As for why, its simply because some people wanted bigger blocks and others wanted segwit. :slight_smile:

1 Like

How does a node accept or decline an update? Does the user see the proposal on the software and choose to accept or decline?

If There is only one node that doesn’t accept an update that makes previously invalid blocks valid… is there a hard fork between every other node and the one?

The node must be updated by the time the update takes effect. All nodes that won’t update will not accept the update.

Yes. :slight_smile:

As we have learned, the Miners will take first the transaction with the highest fees to create the block.
So I guess the chances are quite high, that we have the same transaction processed in two blocks in the event of an accidental fork. The shorter chain will be obsolete and the transactions goes back to the Mempool.

a) But what happens with the transactions which are included in both chains? I guess they can not be pushed back to the Mempool even they are as well part of the shorter chain!

b) What happens if two miners create the absolute same Block (identical)? I guess its not a big coincident that two miners pick the same transaction (according the fees) but then as well solve the puzzle with the same nonce number which would end in an identical hash!

So does that mean the updated nodes would have a harder time mining and would decrease their chance at block rewards?

If the tx is in both chains than it remains confirmed and is not returned to the mempool.

That can’t happen because each miner will create a block with their own coinbase therefore even if all the transactions in the block are the same the coinbase will be different. :slight_smile:

1 Like

If you are talking about hard forks, the updated rules usually don’t effect the mining algo (unless the hard fork specifically changes it). In any case the two chains would eventually have a difficulty adjustment and it would be set according to the hash power of the network the miners belong to. :slight_smile:

Filip,

Seeing that we you should always wait 6 blocks to confirm a transaction. Does that mean you should really never trust the transaction is verified until 60 minutes has passed? 10 per block, 6 blocks to verify. In my personal experience, like sending BTC from an exchange to my cold storage, usually I know within 10 or 15 minutes I see it in my wallet.

Thanks.

Accidental forks happen very rarely, the rule is in place in case they do happen. If you ever deposited funds on an exchange you probably noticed that you are not allowed to use the funds after some confirmations pass.
Nothing prevents you though to spend that UTXO in the very next block and if you’re dealing with small balances its not such a great of a concern. However if you’re selling a Lambo to someone, you might want to wait that period before handing the keys. :stuck_out_tongue:
The balance in your wallet will appear as soon as it gets confirmed or even as soon as the wallet sees the tx in the mempool, this more depends on how UI is implemented to display balances. :slight_smile:

1 Like

Hello, I’ve a question, the thing with the forks, has something with the confirmation of the tx?
I mean, 6 people has to confirm the transaction,if one confirmed first and later two people confirmed at the same time, doesn’t get 3 people confirmed, instead of two?

Does it have something to do with the subject or it just an exitential dubt?

Cheers!

The transaction would only be confirmed 2 times because the two blocks are competing for a place in the blockchain at the same height.
Also at the moment accidental forks actually occur there is no way of actually knowing a competing block exists on the other side of the world (until they actually propagate through the network). So for all intents and purposes the tx is confirmed 2 times just on different blocks by different nodes. Until it gets resolved. :slight_smile:

1 Like

Thanks for solving my question!

H Filip,

Just to be clear on my understanding: Using the example of the changed Consensus Rule from 1 mb to 2mb blocks being allowed, it might be easier to say a block which would have been previously rejected (i.e. 2 mb) is now allowed, but this is not in any way retroactive - only blocks being appended post the rule change correct?

Thanks,
Joel

Yes, there is a set block height set in the code when the new rules go into effect. All blocks up to that rule are treated by the old rules. :slight_smile:

1 Like

How is it determined if there will be a hard or soft fork?

The community decides on what block height specific changes will take effect and the ones that want to switch must have their nodes updated for the rules to take effect on their nodes. :slight_smile:

hello , i have a question concerning hard forks:

let’s assume that
1-old rule : 1 mB /block
2-new rule : 2mB/block
3-the network splits to : 75% will continue mining with 1mB size , and 25% will update to the new rule 2mN/block

since the majority continues mining with old rules , the blocks of the classic chain will be solved faster and the chain will be longer than the new chain .
and since the new rules are an expantion of the old consensus rules ,
then automatically the -2mB- miners will ignore their chain , and aknowledge the classic longer chain (even after the difficulty adjustment 2016blocks )

so we avoided a hard fork , even so 100% of miners didn’t update?

hello, i want to correct my mistake(quiz):

if 2 miners (1st in usa , 2nd in china) solve the block at the same time , wouldn’t they include the Txs which are in the mempool of the nodes near them geographically first ?
if so , wouldn’t that cause a different contents in each version of the mined block?
thank you !

image