Are we prepared for triple blocks?

[Mitchellpkt]

It just dawned on me that it is statistically likely that we will encounter heights with 3 versions of a solved block.

Why?

Natural splits due to latency often lead to a single orphaned block. If that was the only source of forks, we expect a split to two versions.

However, we know that there is a second phenomenon; the miner frequently running out 20 - 35 chain blocks. While those artificial side chains are being produced, there will still be the usual benign orphaned blocks.

Once I have values for (frequency of single orphaned blocks) and (frequency of these longer side chains) it will be possible to calculate the statistical frequency of expected triplets.

However, back-of-the-envelope: I suspect that random latency splits occurring at the same time as the artificial side chains is a common event.

Are we prepared for this?

@neptuneresearch , how does the custom daemon handle this

[neptuneresearch]

Custom daemon just saves data, so if Monero handles this, we're saving them.

The current version distinguishes only between MAIN and ALT blocks, so I think the triple blocks would be ALT blocks.

Otherwise we can further analyze the alt block processing code to see what it does regarding multiple side chains, if you need that answer.

Are there any triple blocks in the archive so far? How do you tell it is a triple?

[Mitchellpkt]

Triple would be any case where our node, over the course of its life, hears three blocks like this: (denoting by colors instead of numbers/letters because I don't want to imply that any one is special. Also, using a random made up height from the future)

orange block: Height = 2625940, Nonce = 2394239
blue block: Height = 2625940, Nonce = 10582
red block: Height = 2625940, Nonce = 608284

---

Here's how we'll test whether/how the patch is recording triple events... Note:

• bitmonero.log = standard daemon output
  • MAP_archive.log = custom patch output

Once next version of the patch is live, I'll keep an eye on the node's bitmonero.log ... Any time a block is received, it records something like:

id: <7037a4f743b912373f33b47f305ef2965db8e4e8b0a2c30058462b38ed26223a>
PoW:    <8c7a63ae55ff31d54289b8b6755495e7d258facf0eed15aadcc28e0400000000>
HEIGHT 1625853, difficulty: 54880087720

To check how the patch is handling triple blocks, I'll dig through and index all of those into a database for analysis.

Note that bitmonero.log doesn't record the nonce... But the ID is the hash of the block, including the nonce, so any two blocks with different nonces will necessarily have different IDs.

I'll find any cases where we have heard 3 different ID's at the same height. Once I've wrangled that out of bitmonero.log we can cross-reference with what MAP_archive.log recorded at that height.

(this would not be routine... just once for MAP_archive validation)

[Mitchellpkt]

Actually, I wouldn't worry about this too much....

Statistical notes:

• Experiment lasted for: 85 days = 60171 heights
• Observed 22 single orphan blocks
• Observed 219 blocks assocated with longer alternative chains
• This corresponds to 1 natural orphan per 2735 heights
• This corresponds to 1 alt-chain-related block per 2735 heights
• Statistically we expect to see a triple block once per 751463 blocks (1044 days)

Of course, there is a big implicit assumption there are only two statistically-independent source: the natural blocks, and one entity creating anomalous alternative chains. However, we know there is weird stuff going on, so I don't trust that assumption. I wouldn't be surprised to see the odd entity testing FPGA's on multiple chains simultaneously, or something like that.

[neptuneresearch]

Ok.

Well note I can move any logging you like into the archive. So that you don't have to have a separate data stream and parser involving the daemon log.

Like this message:

id: <7037a4f743b912373f33b47f305ef2965db8e4e8b0a2c30058462b38ed26223a> PoW: <8c7a63ae55ff31d54289b8b6755495e7d258facf0eed15aadcc28e0400000000> HEIGHT 1625853, difficulty: 54880087720

and I could probably add the nonce.

That's a big idea here that you can keep in mind. Any messaging that the daemon already generates, we can get it flowing in pure form to the Archive Producer, instead of scraping it from the daemon log.