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?

  • 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 Sep 5 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. – Nate Eldredge Sep 5 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. – Nate Eldredge Sep 5 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? – Chirag Kawediya Sep 5 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. – Nate Eldredge Sep 5 at 3:14
2

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.

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

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.