pull down to refresh

It took miners about 98 minutes to find block #820132 today. As I was waiting for it, I wondered: Had the hashrate fallen off a cliff?
According to some math*, a block taking 98 minutes or longer is expected to happen around once every 125 days*. Quite rare, but not alarmingly so.
According to some more math, three or more blocks appearing within three minutes of the last block happens a lot more often, around every 2 days.
But (although maybe a bit specific) the two events happening right after one another (in any order) is expected to happen only once every 47 years!
Seeing the fees pile up in the mempool as block #820132 was being mined also made me wonder if there is any significant reserve of old, normally unprofitable miners that are ready to be fired up as soon as the total reward of a block (subsidy + fees) reaches a certain point. If there were, I would expect a block taking 98 minutes or longer to be even more rare. But it could also help explain the observed behavior of blocks coming in faster after the initial delayed block.
Just my nerdy Bitcoin musings of the day.

*) The math, which I'm pretty sure but not absolutely certain is reasonably correct:
from scipy.stats import poisson DAY = 24 * 60 expected_period = 10 long_period = 98 blocks_per_longer_period = round(1 / poisson.cdf(0, long_period / expected_period)) print(f"{blocks_per_longer_period = }") # blocks_per_longer_period = 18034 days_per_longer_period = round(blocks_per_longer_period * expected_period / DAY) print(f"{days_per_longer_period = }") # days_per_longer_period = 125 short_window = 3 short_window_blocks = 3 blocks_per_shorter_window = round(1 / (1 - poisson.cdf(short_window_blocks - 1, short_window / expected_period))) print(f"{blocks_per_shorter_window = }") # blocks_per_shorter_window = 278 days_per_shorter_window = round(blocks_per_shorter_window * expected_period / DAY) print(f"{days_per_shorter_window = }") # days_per_shorter_window = 2 blocks_per_combined_event = round(blocks_per_longer_period * blocks_per_shorter_window / 2) print(f"{blocks_per_combined_event = }") # blocks_per_combined_event = 2506726 days_per_combined_event = round(blocks_per_combined_event * expected_period / DAY) print(f"{days_per_combined_event = }") print(f"{days_per_combined_event // 365 = }") # days_per_combined_event = 17408 # days_per_combined_event // 365 = 47
Nice Bitcoin nerdy musing ;)
reply
I'm pretty certain that a block taking more than 98 minutes happens everytime you need to move sats on chain in a hurry :)
reply
Does for me. That's for sure. In the very rare instance where.im FORCED to use on chain Bitcoin.
reply
How much is ur electric bill?
reply
This is one of the issues with Bitcoin and why the chances of orange pilling people in mass will fail. Why would anyone want to wait 5 mins let alone 98 mins for their transaction to be irreversible when you can have an irreversible transaction with either fiat or an alt coin in seconds/instantly. This is what you maxi's don't understand. And don't tell me lightning solved the issue because lightning comes with its own issue regarding finding a route and payments failing or pending for hours or days.
reply
Lol. Have you tried swift?
reply
Awesome post! Thanks for sharing the math.
reply
deleted by author
reply
I found it a bit unintuitive that three blocks in a row at an average of 10x the expected rate is so much less unlikely than a single block at one 10th the expected rate. But the math seems to check out. And if you look at the graphs from https://blog.lopp.net/bitcoin-block-time-variance/, you can see that 1 minute is actually around the peak of the historical time delta distribution.
poisson.cdf(k, rate) is the cumulative Poisson distribution. I.e., it returns the probability that the number of events within an interval is less than or equal to k, with rate being the expected number of events.
reply