https://mempool.space/block/000000000000000000003be80b432a84daf900e043f3a4f41bfa22921ae0ef6c
Seems like mining 0.1 sat/vB transactions did not pay off for MARA. At the same time SBI Crypto found a block that only goes down to 1 sat/vB. Since most of the nodes still have their policy set to a minimum fee of 1 sat/vB, propagating a block that includes these extremely cheap transactions tends to be slower than a block that can be immediately reconstructed via Compact Block Relay.
Thanks for posting this. It seems like a good example of something that the tolerant minority of node runners wouldn't change. And therefore a pretty good example of filters working.
Do you think that was the reason? Or it was the next block found that determined the outcome?
Likely yes, but impossible to know for sure. The block after that was found by Foundry USA. It would seem that they happened to receive the SBI Crypto block first.
But sure, let's investigate a bit:
The MARA block was found at 00:54:09 UTC.
The SBI Crypto block was found at 00:54:32 UTC.
Miners can of course have an inaccurate clock but let's check:
The
ntimeof both SBI Crypto and MARA tends to be very close to UTC:https://stratum.work/template/SBI%20Crypto
https://stratum.work/template/MARA%20Pool
I used https://www.epochconverter.com/hex to convert the hexadecimal
ntimeto a human readable format.So it is likely that the times are indeed correct.
Even though the MARA block was found 23 seconds before the SBI Crypto block, MARA still lost the block race.
EDIT: On second thought, looking at the block template update intervals: (https://stratum.work/timing) MARA and SBI Crypto both update their block template in ~30 second intervals. A 23 second difference is still within that time frame. So hard to say when exactly these blocks were found.
The next block always determines the outcome.
~bitcoin_Mining