Topic: Forking vs. Knifing (Read 1000 times)

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.

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.

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

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.

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