1

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?

6
  • 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. Sep 5, 2020 at 2:18
  • 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. Sep 5, 2020 at 2:20
  • 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. Sep 5, 2020 at 2:22
  • 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
    Sep 5, 2020 at 3:11
  • 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. Sep 5, 2020 at 3:14

2 Answers 2

3

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.

2
  • 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. Sep 5, 2020 at 7:35
  • @PieterWuille Absolutely, perhaps my phrasing could be better, I'll edit the answer Sep 5, 2020 at 7:39
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.