How does block propagation delay not cause accidental forks?

Question

Block propagation delay, it looks like, is about 122 seconds in some cases. If another block is formed before the first block is completed, wouldn't this accidentally create a fork? How would this fork be resolved? Someone's transactions are bound to get lost.

Example: Let's start with a block A. Say block B was just completed, and is now being propagated. If, during that delay, someone made a transaction and a new block C was created before block B reached them, wouldn't their blockchain become forked, with A->C and A->B? How does bitcoin prevent accidental forks like this?

Answer 1

How does bitcoin prevent accidental forks like this?

It doesn't. Bitcoin make little effort to prevent forks at a technical level, instead relying on the fact that when a fork does happen, it can be resolved by waiting for additional blocks and picking the chain with the most work.

As Pieter mentioned, the mining mechanism itself prevents long term forks. The act of mining extends one chain beyond the other, reducing the shorter chain to a temporary and now discarded fork.

For miners specifically, they put in a lot of effort to avoid this - mining on even a minor fork is inherently risky, as they could lose their blocks if the other side of the fork wins, thus losing the block rewards.

To reduce this risk, all serious miners join high speed links as Bitcoin Fibre. These are specially designed to minimize propagation delay.

No serious mining operation will be looking at propagation delays of 122 seconds - those would only be happening at nodes run by people with absolutely abysmal peering and internet access. For the vast majority of nodes, blocks are received in a few seconds, and for miners, usually in <1s.

Answer 2

Forks do happen. As an example, take it to an extreme ... if one section of the internet were out of communication with the rest of the world, a chain fork would certainly happen, as this isolated segment would hear nothing from elsewhere and miners on that segment would validate different blocks than the rest of the network. Only when connectivity were restored would the longest fork be retained as the official, definitive one.

Block propagation delays may cause chain forks, but on the other hand, individual transaction propagation delays will never do this per-se.

When a user sends bitcoins, this transaction is broadcast on the P2P network. Miners hear the transaction and add it to their "mempool", a list of transactions waiting to be validated by being included in a block.
I recall reading that it takes on average no more than 12 seconds for a transaction broadcast to reach all the nodes in the network.
Since, on average, bitcoin blocks are added to the chain every 10 minutes, there is usually plenty of time for transactions to be assembled by miners onto their block: the one they are competing to validate and be added to the chain by consensus of their peers.

The larger concern for users is that they offer a large enough fee for the miners such that they are not elbowed out of the limited block space ( 1 Mb in bitcoin ) by higher-fee paying transactions.

Once a transaction is included in a validated block, which is added to the blockchain by consensus of the majority of miners, barring any longer chain forks, that block will be official and final.

Transactions that were not included in the latest block, (either because the block first filled up with higher fee paying transactions or because they were not "heard" by the miner by the time the miner's block was validated and added to the chain) will still be in the 'mempool', the list of transactions waiting to "get on a block" and will likely by included in the next block validated by the miners.