Forking vs. Knifing

[fevir]

Hi all,

I was wondering about the following scenario:

When a node receives two valid blocks, a fork occurs. Then, when a next block is found and send to that node, the longest chain will be considered as valid. This is the process called forking.

First question, at what rate does a fork occur in Bitcoin? With thousands of nodes mining, it seems that a fork must occur on a regular basis – are there any stats on how often a fork happens?

Second, knowing that Bitcoin uses a P2P network, assume there's a single connection that connects two parts of the network (a single point of failure in a P2P network). That connection fails for 24 hours, and the two separate networks continue mining. Both are working on their own version of the blockchain. Then, a smart network engineer fixes the cable and the connection is restored. Effectively, there are two versions of the blockchain and both are valid (for each part of the network). New blocks from network A are rejected by B (and vice versa), because the longest chain rule is applied. Instead of a 'fork', we have 'knife', cutting the network in half.

Second question, how does Bitcoin deal with such an issue (though theoretically, considering it's an P2P network)?

Cheers,
Fevir

[1715156125]

1715156125

[1715156125]

1715156125

[achow101]

Hi all,

I was wondering about the following scenario:

When a node receives two valid blocks, a fork occurs. Then, when a next block is found and send to that node, the longest chain will be considered as valid. This is the process called forking.

First question, at what rate does a fork occur in Bitcoin? With thousands of nodes mining, it seems that a fork must occur on a regular basis – are there any stats on how often a fork happens?

Those are known as orphan blocks and blockchain.info has some stats on them here: https://blockchain.info/charts/n-orphaned-blocks

Second, knowing that Bitcoin uses a P2P network, assume there's a single connection that connects two parts of the network (a single point of failure in a P2P network). That connection fails for 24 hours, and the two separate networks continue mining. Both are working on their own version of the blockchain. Then, a smart network engineer fixes the cable and the connection is restored. Effectively, there are two versions of the blockchain and both are valid (for each part of the network). New blocks from network A are rejected by B (and vice versa), because the longest chain rule is applied. Instead of a 'fork', we have 'knife', cutting the network in half.

Second question, how does Bitcoin deal with such an issue (though theoretically, considering it's an P2P network)?

Cheers,
Fevir

First of all, the p2p such a scenario is unlikely given that nodes connect to more than 1 peer and given the size of the netowrk.

But theoretically if that were to happen and the chains were being built at the same rate and at the same height, upon reconnection, Bitcoin Core would detect that a hard fork had occurred and something had gone wrong. AFAIK It would alert the operator and continue to use the chain it had been (or it might go into safe mode, don't remember). There would probably be an alert sent out by the developers and then they would decide whether to roll back the blockchain back to the fork point, or choose one chain and set checkpoints into the software to make sure that is the one used. It is hard to know what will happen, and is unlikely to happen. However, Bitcoin Core does not do much when such a situation happens, it can only alert the operator that something has happened.

[fevir]

Thanks! makes sense

[edmundedgar]

There would probably be an alert sent out by the developers and then they would decide whether to roll back the blockchain back to the fork point, or choose one chain and set checkpoints into the software to make sure that is the one used.

In this situation it would be hard to avoid using the longest chain, especially if it was a significant difference. Including a checkpoint in the software would be like declaring war on the majority hashrate, and they may well respond by locking out the minority until they'd got the money they thought they were owed...

This isn't entirely academic, because the majority hashrate is in an authoritarian regime that's long been propped up by a good economy, and that economy isn't looking good. If they felt at serious risk of a revolution it's not hard to imagine them turning off access to the outside world.

I think the upshot would be that you couldn't safely use bitcoin until the situation sorted itself out.

[monsterer]

Second question, how does Bitcoin deal with such an issue (though theoretically, considering it's an P2P network)?

Basically, when the network is reunified, the shortest chain of the fork becomes orphaned and all transactions in that chain are undone.

[DannyHamilton]

Lets see what Satoshi has to say about this question...

It's hard to imagine the Internet getting segmented airtight.  It would have to be a country deliberately and totally cutting itself off from the rest of the world.

Any node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone.  It would only take one node to do it.  Anyone who wants to keep doing business would be motivated.

If the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks.  Their number of confirmations would start over.

If anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way.

It wouldn't be easy to take advantage of the segmentation to double-spend.  If it's impossible to communicate from one side to the other, how are you going to put a spend on each side?  If there is a way, then probably someone else is also using it to flow the block chain over.

You would usually know whether you're in the smaller segment.  For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment.  If you're in the smaller segment, you should assume nothing is confirmed.

[achow101]

There would probably be an alert sent out by the developers and then they would decide whether to roll back the blockchain back to the fork point, or choose one chain and set checkpoints into the software to make sure that is the one used.

In this situation it would be hard to avoid using the longest chain, especially if it was a significant difference. Including a checkpoint in the software would be like declaring war on the majority hashrate, and they may well respond by locking out the minority until they'd got the money they thought they were owed...

This isn't entirely academic, because the majority hashrate is in an authoritarian regime that's long been propped up by a good economy, and that economy isn't looking good. If they felt at serious risk of a revolution it's not hard to imagine them turning off access to the outside world.

I think the upshot would be that you couldn't safely use bitcoin until the situation sorted itself out.

Well the scenario he was describing and I was explaining was if somehow the network was a 50/50 split. Half of the hashrate worked on one fork the other half on another fork and somehow the blockchain was the exact same length. This is incredibly unlikely (odds are next to nothing) but if it somehow were to happen, it would completely screw with people.