Occurrence of micro forks

[Tym]

It might happen that two miners find a new block at almost the same time. Due to the latency in the network some nodes receive block A first, while some other nodes receive block B first.

Assuming that more future blocks are refer to A as a predecessor, A will be part of the longest chain, while B is referred to as an orphan block. I was trying to figure out how often such a scenario takes place.
I found this graph on blockchain.com: https://www.blockchain.com/charts/n-orphaned-blocks (select All Time and Raw Values)


I have multiple questions:

• Can someone verify the correctness of this chart?
• If it is correct, why do such micro forks only occur between 2014-2018?
• I thought such a scenario would happen way more often.. Why not?
• I'm operating a full node. Can I verify the numer of orphan blocks by myself? (Are they stored by my node)?
• Are there any good references on this topic?

Thanks for your answers in advance!
Cheers Tym

[1713435351]

1713435351

[1713435351]

1713435351

[1713435351]

1713435351

[1713435351]

1713435351

[ranochigo]

Assuming that more future blocks are refer to A as a predecessor, A will be part of the longest chain, while B is referred to as an orphan block. I was trying to figure out how often such a scenario takes place.
I found this graph on blockchain.com: https://www.blockchain.com/charts/n-orphaned-blocks (select All Time and Raw Values)

It's a stale block. They are not orphaned blocks as the preceding block is known. Stale blocks are often referred to as orphan blocks but that'll be the wrong term to use.

Can someone verify the correctness of this chart?

You can't. Stale blocks are often poorly propagated as nodes do not propagate competing blocks at the same height once they have seen either of them. To answer your question; it's not accurate, BitMex just recorded a stale block yesterday and it isn't reflected on the chart.

If it is correct, why do such micro forks only occur between 2014-2018?
I thought such a scenario would happen way more often.. Why not?

The spike that you see in 2015 is mainly due to the SPV mining fiasco that happened around that time, where an invalid block was mined and miners continued to build on that chain due to the fact that they didn't validate the block before mining on it and thus accounting for that spike in stale blocks. The reason why the stale blocks happens much less often, but still happens occasionally is due to the implementation of compact block[1] which relays the blocks way faster than before and it was introduced a Core version in late 2016, IIRC[2]. If the mining pools are well connected to each other, as they should, they could avoid mining on the wrong chain and losing their block rewards. Selfish mining could contribute to stale blocks but I'm not sure if that has happened yet.

I'm operating a full node. Can I verify the numer of orphan blocks by myself? (Are they stored by my node)?

You have to be running a node for the entire duration to record down any stale blocks that has been relayed to you. You'll find it hard to record the accurate number of stales without quite a few nodes and/or a well connected node. You can probably run quite a few nodes and just issue getchaintip to each of them from a central server and note any discrepancy between the responses. That's probably how forkmonitor.info is doing it as well, but at a more refined level probably.

[1] https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki
[2] https://github.com/bitcoin/bitcoin/blob/c7ad94428ab6f54661d7a5441e1fdd0ebf034903/doc/release-notes/release-notes-0.13.0.md

[vjudeu]

IIRC, Bitcoin Core store such blocks, even though you need to access the blk*.dat directly.

You don't have to. Using "getchaintips" command is enough to get them.

[Tym]

The command "getchaintips" results currently in:

Code:

[
  {
    "height": 667021,
    "hash": "0000000000000000000554929b9d4f557cb566409731997c6a994faad8f75c48",
    "branchlen": 0,
    "status": "active"
  },
  {
    "height": 666833,
    "hash": "00000000000000000005e086e9e74aae37139ba27c5ba8b50ba5c773e22c6b61",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 665005,
    "hash": "00000000000000000001039fa3b04eb66a658c44632ac1d3694f772ea50f865f",
    "branchlen": 1,
    "status": "headers-only"
  }
]

667021 is the current best tip. Hence, 666833 and 665005 are stale blocks?

You'll find it hard to record the accurate number of stales without quite a few nodes and/or a well connected node.

Based on this statement I assume that the result of "getchaintips" is a little different for each node?

[vjudeu]

Based on this statement I assume that the result of "getchaintips" is a little different for each node?

Yes. You can even create your own stale blocks if you really want, for example by building on top of the Genesis Block. If properly constructed, there is no difference between receiving some stale block from the network and creating it by yourself, each node has its own list of stale blocks in the same way as each node has its own mempool.

[Tym]

Yes. You can even create your own stale blocks if you really want, for example by building on top of the Genesis Block. If properly constructed, there is no difference between receiving some stale block from the network and creating it by yourself, each node has its own list of stale blocks in the same way as each node has its own mempool.

Alright, thank you for the confirmation.