<blockquote>
<p>How does bitcoin prevent accidental forks like this?</p>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>To reduce this risk, all serious miners join high speed links as <a href="https://bitcoinfibre.org/" rel="nofollow noreferrer">Bitcoin Fibre</a>. These are specially designed to minimize propagation delay.</p>
<p>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 &lt;1s.</p>

CC BY-SA 4.0
2020-09-05T07:35:06.470Z
Arguably, mining _is_ the effort to prevent forks - or at least to resolve them. If synchronization of validation wasn't an issue, mining wouldn't be needed.
Pieter Wuille
CC BY-SA 4.0
2020-09-05T07:39:20.563Z
@PieterWuille Absolutely, perhaps my phrasing could be better, I'll edit the answer
Raghav Sood
CC BY-SA 4.0
2020-09-05T03:19:01.920Z
2020-09-05T07:42:20.197Z
2020-09-05T07:42:20.197Z
Raghav Sood
<p>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.</p>
<p>Block propagation delays may cause chain forks, but on the other hand, individual transaction propagation delays will never do this per-se.</p>
<p>When a user sends bitcoins, this transaction is broadcast on the P2P network. Miners hear the transaction and add it to their &quot;mempool&quot;, a list of transactions waiting to be validated by being included in a block.<br />
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.<br />
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.</p>
<p>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.</p>
<p>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.</p>
<p>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 &quot;heard&quot; 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 &quot;get on a block&quot; and will likely by included in the next block validated by the miners.</p>

CC BY-SA 4.0
2021-12-20T12:25:12.770Z
2021-12-20T13:21:16.197Z
2021-12-20T13:21:16.197Z
dbkeys
<p>Block propagation delay, it looks like, is about <a href="http://bitcoinstats.com/network/propagation/" rel="nofollow noreferrer">122 seconds in some cases.</a> 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.</p>
<p><strong>Example:</strong>
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-&gt;C and A-&gt;B? How does bitcoin prevent accidental forks like this?</p>

CC BY-SA 4.0
2020-09-05T02:18:41.693Z
The link isn't working.  But if it really did take 122 seconds for blocks to propagate *between miners*, then yes, you'd expect frequent forks.  However, I don't believe for a moment that this figure is correct.  In fact, major miners set up dedicated low-latency links to one another, precisely to minimize this latency.  I would guess that in practice, the propagation delay between miners is in the tens of milliseconds.
Nate Eldredge
CC BY-SA 4.0
2020-09-05T02:20:46.080Z
If there were a fork, it'd be resolved in the usual way: in favor of whichever block is pointed to by subsequent blocks. But forks don't result in transactions getting "lost"; any transactions that were left out of the winning block can always be added in a later block, unless a conflicting transaction gets added first.
Nate Eldredge
CC BY-SA 4.0
2020-09-05T02:22:48.960Z
It's possible that it takes 122 seconds for a block to propagate to some guy in the backwoods who gets Internet via tin cans and a piece of string.  But that guy is not going to be mining to any significant extent, so no forks result from this.
Nate Eldredge
CC BY-SA 4.0
2020-09-05T03:11:01.610Z
I guess that makes sense at first, but I know that bitcoin has a staggeringly low cap for block size that could potentially drive the time between blocks down to microscopically small numbers, especially considering the ever expanding computational power at our disposal. Wouldn't relying on this seriously bottleneck bitcoin's scalability?
bluesquare
CC BY-SA 4.0
2020-09-05T03:14:10.300Z
Bitcoin doesn't "rely" on this; the system still works even if such mini-forks occur sometimes.  But it's in the economic best interest of miners to minimize this effect, which is why they invest in these networks.  Note that the (average) time between blocks is fixed by the protocol at 10 minutes, and is essentially unaffected by the block size.
Nate Eldredge
CC BY-SA 4.0
2020-09-05T03:14:56.563Z
The question of how block size limits affect the scalability of Bitcoin is an entirely separate question from the one you asked, and has been addressed many many times on this site.
Nate Eldredge
<blockchain><transaction-propagation><block-propagation-time>
How does block propagation delay not cause accidental forks?
bluesquare
# How does block propagation delay not cause accidental forks?

(Asked by: username_0 on 2020-09-05)

Block propagation delay, it looks like, is about [122 seconds in some cases.](http://bitcoinstats.com/network/propagation/) 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?

**Tags:** blockchain, transaction-propagation, block-propagation-time

> **Comments:**
> **username_1**: The link isn't working.  But if it really did take 122 seconds for blocks to propagate *between miners*, then yes, you'd expect frequent forks.  However, I don't believe for a moment that this figure is correct.  In fact, major miners set up dedicated low-latency links to one another, precisely to minimize this latency.  I would guess that in practice, the propagation delay between miners is in the tens of milliseconds.  
> **username_1**: If there were a fork, it'd be resolved in the usual way: in favor of whichever block is pointed to by subsequent blocks. But forks don't result in transactions getting "lost"; any transactions that were left out of the winning block can always be added in a later block, unless a conflicting transaction gets added first.  
> **username_1**: It's possible that it takes 122 seconds for a block to propagate to some guy in the backwoods who gets Internet via tin cans and a piece of string.  But that guy is not going to be mining to any significant extent, so no forks result from this.  
> **username_0**: I guess that makes sense at first, but I know that bitcoin has a staggeringly low cap for block size that could potentially drive the time between blocks down to microscopically small numbers, especially considering the ever expanding computational power at our disposal. Wouldn't relying on this seriously bottleneck bitcoin's scalability?  
> **username_1**: Bitcoin doesn't "rely" on this; the system still works even if such mini-forks occur sometimes.  But it's in the economic best interest of miners to minimize this effect, which is why they invest in these networks.  Note that the (average) time between blocks is fixed by the protocol at 10 minutes, and is essentially unaffected by the block size.  
> **username_1**: The question of how block size limits affect the scalability of Bitcoin is an entirely separate question from the one you asked, and has been addressed many many times on this site.  

---

## 2 answers

### Answer by username_2 on 2020-09-05. Score: 3 | Accepted answer

> 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 username_3 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](https://bitcoinfibre.org/). 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.

> **Comments:**
> **username_3**: Arguably, mining _is_ the effort to prevent forks - or at least to resolve them. If synchronization of validation wasn't an issue, mining wouldn't be needed.  
> **username_2**: @username_3 Absolutely, perhaps my phrasing could be better, I'll edit the answer  

---

### Answer by username_4 on 2021-12-20. Score: 0

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.


---

