pull down to refresh

IIRC there used to be a modified version of bitcoind that tries to explore all chaintip forks and fetch the block data of announced headers / compact blocks, even if it is on a tip that is extremely unlikely to ever overtake.

I'm not sure how well this works with the BIP-110 fork because last I checked at least the activation client seemed to be discriminative and aggressively disconnect any nodes that allow blocks deviating from BIP-110, so from that perspective, running 2 nodes is probably your best bet if you want to observe and compare in depth. You'll still be able to see the block headers and chaintip length of everything on Core, as long as you're connected to at least one peer with the other chaintip though, just it won't always fetch the block data, so you won't always be able to tell what's in the blocks.

bitcoin-cli getchaintips is always your friend.

Interesting. TIL my node connected to peers on other chain tips (17 to be exact).

reply

Those are orphaned blocks due to timing / races, i.e. the bulk should be "naturally" occuring reorgs or late blocks that didn't make it in, branchlen is indicating how many blocks the split is deep. You should for example be seeing the recent 2-block reorg from #1459136 at 941880 to 941882:

  {
    "height": 941882,
    "hash": "00000000000000000000c81cbf94a12ca498e72eb8530f7061c8746cf9687b2e",
    "branchlen": 2,
    "status": "valid-fork"
  }

When the chaintip splits, the BIP-110 side should show up there too, given that there is still some bridging happening between the two implementations. If it takes over, the non-BIP-110 side will be listed there.

reply

Great, I do see the reorg.

I thought it was interesting that these are all post block 900000.

reply
186 sats \ 1 reply \ @optimism 28 Jul

Your node only knows what it has seen, and only since since the last reindex / IBD.

reply

Makes sense.

reply