Bitcoin Block Halving

[GreatArkansas]

As we all know, Bitcoin has a  "block halving event" in which every 210,000 blocks have mined, and the block reward halves.

210,000 blocks are approximately in 4 years.
Block intervals are 10 minutes.

What are the circumstances that we can reach those blocks in just a short period of time like not will reach in the approximately 4 years or it will more than?

Also, do we have any idea or basis why Satoshi Nakamoto decided that the block halving is scheduled in every 210,000 blocks?

Just become curious, because I saw an article about the upcoming US Election and Bitcoin.
Since the US election is held every 4 years which it is the same with the block halving event of Bitcoin.

[BlackHatCoiner]

What are the circumstances that we can reach those blocks in just a short period of time like not will reach in the approximately 4 years or it will more than?

I don't understand your question, I think that you know the answer. There are no circumstances to reach them in just a short period of time. As long as difficulty changes every 2016 blocks, it means that even if the total mining power gets doubled, the difficulty will get doubled as well. Same thing if mining power gets decreased.

Also, do we have any idea or basis why Satoshi Nakamoto decided that the block halving is scheduled in every 210,000 blocks?

I think I was making similar questions in the past and I've came to a conclusion about Nakamoto's decisions. He just considered it right, no mystery calculations. For example, difficulty adjucts every 2016 blocks, but there is no proper reason why he chose that, as far as I know. He could choose every 2000 blocks or 1008 blocks. Although, 2016 blocks, which is equal with 20160 minutes on average means 14 days, seemed a nice number.

Same thing happened for the halving that occurs every 210,000 blocks and the total supply that will be 21,000,000BTC

[odolvlobo]

What are the circumstances that we can reach those blocks in just a short period of time like not will reach in the approximately 4 years or it will more than?

The actual time between halvings depends on how much the hash rate changes. When the hash rate increases, the time between halvings is shorter. That is why the halvings so far were 32, 139, and 56 days early.

Also, do we have any idea or basis why Satoshi Nakamoto decided that the block halving is scheduled in every 210,000 blocks?

I believe that the 4 years between halvings, the two weeks between difficulty adjustments, and ten minutes between blocks were chosen somewhat arbitrarily.

Just become curious, because I saw an article about the upcoming US Election and Bitcoin.
Since the US election is held every 4 years which it is the same with the block halving event of Bitcoin.

Bitcoin was started in the year after the election. The first halving was in the same year but after the election, and the next two were before the election. In several years, the halving is likely to occur in the year before the election. The halvings do not occur on precise four-year intervals so they will not coincide with U.S. elections most of the time.

[o_e_l_e_o]

There are no circumstances to reach them in just a short period of time.

Practically speaking, this is largely correct, but I can think of a few hypothetical scenarios which would bring the next halving significantly closer.

As odolvlobo points out, since hash rate can increase in real time, but the target can only decrease every 2016 blocks, then if hash rate continues to increase then blocks will be mined quicker than every 10 minutes on average.

More broadly, the target can only adjust by a factor of 4 at any given retargetting, and so if the hash rate started increasing exponentially then the target could not keep up and the halving would come much sooner. The only ways I could see this happening is if a vulnerability was discovered in the hashing process (unlikely), or there was some massive breakthrough in ASIC design.

[hosseinimr93]

As odolvlobo points out, since hash rate can increase in real time, but the target can only decrease every 2016 blocks, then if hash rate continues to increase then blocks will be mined quicker than every 10 minutes on average.

And that's exactly why first 210,000 blocks were mined in 3 years, 10 months, 19 days.
Second 210,000 blocks were mined in 3 years, 7 months, 11 days.
Third 210,000 blocks were mined in 3 years, 10 months, 3 days.

If blocks were mined every 10 minutes on average, the current block would be 620,200 while the last block mined was block number 654,173.

The average time of blocks confirmation in the past 654,170 blocks have been 9 minutes and 29 seconds.

[o_e_l_e_o]

Note that there is also currently a bug in the protocol's implementation which leads to an average block time of 599.7 seconds rather than the intended 600 seconds.

What bug is this?

The only bug I am aware of skews things in the other direction. Although the retargetting period is every 2016 blocks, it only considers the time taken to mine the previous 2015 blocks, which would result in an average block time of 2 weeks/2015 = 600.3 seconds.

[BlackHatCoiner]

Practically speaking, this is largely correct, but I can think of a few hypothetical scenarios which would bring the next halving significantly closer.

Yes but only in the last 2016 blocks right? If the average time took between 2016 blocks is 9 minutes, then the difficulty will adjuct so the next 2 weeks will take 11 minutes. I don't get how you can trick the system, unless we're talking about 1-14 days difference.

The average time of blocks confirmation in the past 654,170 blocks have been 9 minutes and 29 seconds.

And this is why difficulty only increases. Because most of the time, the 2016 blocks are mined before 20160 minutes have passed.

[pooya87]

Practically speaking, this is largely correct, but I can think of a few hypothetical scenarios which would bring the next halving significantly closer.

Yes but only in the last 2016 blocks right? If the average time took between 2016 blocks is 9 minutes, then the difficulty will adjuct so the next 2 weeks will take 11 minutes. I don't get how you can trick the system, unless we're talking about 1-14 days difference.

probably by manipulating block times. all these times are measured using the time field in the block headers and a miner could put fake timestamps there within the reasonable range without getting it rejected (i believe it is 2 hours difference from real time).
although i believe it is easier to manipulate the difficulty by postponing the readjustment and the halving than it is to bringing it closer. all it takes is shutting down your miner (removing hashrate).

[o_e_l_e_o]

If the average time took between 2016 blocks is 9 minutes, then the difficulty will adjuct so the next 2 weeks will take 11 minutes.

No. If the average block time for the last 2016 blocks was 9 minutes, then the difficulty will readjust so as to try to make the average block time for the next 2016 blocks be 10 minutes. It does not try to over compensate for previous blocks being quicker by making subsequent ones slower. It is targeting an average of 10 minutes for those specific 2016 blocks, not an average of 10 minutes for the entire blockchain.

And this is why difficulty only increases. Because most of the time, the 2016 blocks are mined before 20160 minutes have passed.

Difficulty doesn't only increase. It can and does decrease as well, for example immediately after the halving.

[NotATether]

Note that there is also currently a bug in the protocol's implementation which leads to an average block time of 599.7 seconds rather than the intended 600 seconds.

What bug is this?

The only bug I am aware of skews things in the other direction. Although the retargetting period is every 2016 blocks, it only considers the time taken to mine the previous 2015 blocks, which would result in an average block time of 2 weeks/2015 = 600.3 seconds.

There is no mention of it in Bitcoin’s Github page or issues, and the bitcoin-dev mailing list is too tedious to search in without a search feature.

But in the src/chainparams.cpp:Consensus::Params class, the member nPowTargetSpacing is set to 600 seconds. Something tells me the buggy function is located at src/chain.cpp where the block proof time is retrieved but I don’t have evidence to back this.

[odolvlobo]

Note that there is also currently a bug in the protocol's implementation which leads to an average block time of 599.7 seconds rather than the intended 600 seconds.

What bug is this?

The only bug I am aware of skews things in the other direction. Although the retargetting period is every 2016 blocks, it only considers the time taken to mine the previous 2015 blocks, which would result in an average block time of 2 weeks/2015 = 600.3 seconds.

That's the one. I got the math backwards. Thanks for the correction.

[mikeywith]

There are no circumstances to reach them in just a short period of time. As long as difficulty changes every 2016 blocks, it means that even if the total mining power gets doubled, the difficulty will get doubled as well.

But difficulty adjustment alone can't maintain the 4 years halving theory, it's only meant to get it as close to that as possible to maintain a known inflation rate, correct me if I am wrong on the following:

Theoretically speaking we can have a bitcoin halving every day (or even an hour)

Difficulty adjustment is limited by a factor of 4 in this code, so this can only slow miners by a factor of 4 in the best-case scenario

Code:

 // Limit adjustment step
    int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
    printf("  nActualTimespan = %"PRI64d"  before bounds\n", nActualTimespan);
    if (nActualTimespan < nTargetTimespan/4)
        nActualTimespan = nTargetTimespan/4;
    if (nActualTimespan > nTargetTimespan*4)
        nActualTimespan = nTargetTimespan*4;

So it can't be more than 400% of the previous epoch and not less than 25%, which means if hypothetically the hashrate keeps going real fast ( 40 times higher constantly with every adjustment) we will be able to mine 210,000 blocks as fast as our hard drives can handle.

Imagine the following:

Diff = 1
hashrate = 10
2016 blocks were mined in 1 minute ( I mean all of the 2016 blocks)
Diff can only be 4x so:
Diff = 4
hashrate = 400
2016 blocks were mined in 1 minute

And so on, so forth! I can't find anything in the code that will stop miners from mining all bitcoins in no time, I believe Satoshi knew this wasn't going to happen because of the nature of people, money, and technology limitation, not because of the code itself.


Now for something like this to happen, we will need a new technology outside of this universe because the current 130Exahash hashrate is impossible to double in the course of a few months, let alone do 40x.

You will notice that the further we go, the closer we get to that 4 years mark because the larger the hashrate the less impact we can have on it, eventually we should be able to hit a very close period to that 4 years plan.

[tranthidung]

Halving happens for each 210 000 blocks but how long the interval between 2 consecutive halving days is a myth. No one can tell you exactly.

It depends on fluctuations or increases or decreases of block confirmation time within the all batch of 210 000 blocks. The chart shows you how the median confirmation time (block time) change over years. The plot is for 30-days MA.

Let's estimate the interval between 2 halvings based on 30-days MA of block time. In fact, I don't believe we will have to wait up to next 7 years (since May 2020) to see next halving. The plot shows regularly corrections of block time.

• 10 minutes: 3.995 years
• 15 minutes: 5.993 years
• 17.76 minutes (current 30-days MA of block time): 7.096 years

Raw estimations

Code:

. di 210000*10/60/24/365
3.9954338

. di 210000*15/60/24/365
5.9931507

. di 210000*17.76/60/24/365
7.0958904

https://www.blockchain.com/charts/median-confirmation-time

[stompix]

It depends on fluctuations or increases or decreases of block confirmation time within the all batch of 210 000 blocks. The chart shows you how the median confirmation time (block time) change over years. The plot is for 30-days MA.

https://www.blockchain.com/charts/median-confirmation-time

That's the confirmation time for a transaction, it is not really correlated with the time between blocks although it can be influenced by it, just look at how that thing is looking for the last year, if it were like that we would be seeing the next halving in 8 years as for the last month we've had an average confirmation time of around 20 minutes.

This is the block time, showing the average time between blocks:
https://bitinfocharts.com/comparison/bitcoin-confirmationtime.html#6m

[o_e_l_e_o]

It is a function of how full the mempool is, not how fast or slow the block time is. If I drop 500 MB of 1 sat/vbyte transaction in the the mempool right now, then even if we found a block every 5 minutes for the rest of the day the median confirmation time is going to be pushed up towards an hour. There is no direct correlation.

Looking at the graph, there is also no way the average block time could have increased from 10 minutes to 17 minutes over the course of 3 months without a massive drop in hashrate. That's approximately 10-12 difficulty readjustments. For the difficulty to readjust 10-12 times, but the block time to continue to increase, there would have had to have been a huge and consistent loss of hashrate over the last 3 months, when in reality it has increased from ~120 EH/s to ~140 EH/s.

[stompix]

It is a function of how full the mempool is, not how fast or slow the block time is. If I drop 500 MB of 1 sat/vbyte transaction in the the mempool right now, then even if we found a block every 5 minutes for the rest of the day the median confirmation time is going to be pushed up towards an hour. There is no direct correlation.

I should have worded that a bit better, correlation was not the right word.

Right now we're experiencing a drop in hash rate, currently about ~150 blocks behind the target, at around a 12% drop, based on this post by Philip 2 days ago we were just 8% behind so the drop is accelerating and, with less capacity, the mempool is indeed filling up and pushing tx confirmation time up, as you can see the mempool has never been this full in the last month.

Of course, if the price would have been flat it would have not triggered so many transactions even with this drop but when those two combine, we have this. So, not really correlated, more like one can definitely affect the other but not the other way around.
Anyhow, nothing to do with halving.  

[tranthidung]

That's the confirmation time for a transaction, it is not really correlated with the time between blocks although it can be influenced by it, just look at how that thing is looking for the last year, if it were like that we would be seeing the next halving in 8 years as for the last month we've had an average confirmation time of around 20 minutes.

This is the block time, showing the average time between blocks:
https://bitinfocharts.com/comparison/bitcoin-confirmationtime.html#6m

I am sorry for my mistake. I did not carefully notice it. Confirmation time is affected by fee rate each transaction is set up with. Firstly with Raw value option, I see the fluctuation around 10 mins and not check more. Thanks for your correction.

I knew the link you provided (thanks, of course). You post makes me wonder why bitinfocharts.com uses the term confirmationtime for block time. This somewhat causes my mistake (I did not do double check).  

It is a function of how full the mempool is, not how fast or slow the block time is. If I drop 500 MB of 1 sat/vbyte transaction in the the mempool right now, then even if we found a block every 5 minutes for the rest of the day the median confirmation time is going to be pushed up towards an hour. There is no direct correlation.

Yes. It is not a linear correlation.

In fact, hashrates rise significantly or falls dramatically over different period. Total blocks founds with short interval and total blocks found with long interval balance one another. It is what why the median value of block time is around 10 minutes. Miners (their greediness, over-mining activities or capitulations) can result in shortly impacts but in the long run, they can not.

Looking at the graph, there is also no way the average block time could have increased from 10 minutes to 17 minutes over the course of 3 months without a massive drop in hashrate. That's approximately 10-12 difficulty readjustments. For the difficulty to readjust 10-12 times, but the block time to continue to increase, there would have had to have been a huge and consistent loss of hashrate over the last 3 months, when in reality it has increased from ~120 EH/s to ~140 EH/s.

Thank you for the detailed explanation from which I learned something too. Again, the chart is taken from third party and its validity is unknown. I simply took it for these estimations.

Price of bitcoin has its impacts as well.

Lots of assumptions, lots of if. I am thankful to the difficulty adjustment that help the network works and halving intervals are almost stable.  

[mikeywith]

• 17.76 minutes (current 30-days MA of block time): 7.096 years

Using the 30 days MA will always give you "terrible" results, the number of blocks found in 30 days is a drop in the ocean as far as the 210,000 blocks are concerned, so getting 7 years halving estimate is pretty normal, getting 2 years is also nothing out of the ordinary, can you do another analysis from the last halving to the latest block? one more thing, you should use block time, ignore the confirmation thing, I remember you made a topic about empty blocks? you could use the same data from LoyceV.

It is a function of how full the mempool is, not how fast or slow the block time is. If I drop 500 MB of 1 sat/vbyte transaction in the the mempool right now, then even if we found a block every 5 minutes for the rest of the day the median confirmation time is going to be pushed up towards an hour. There is no direct correlation.

There is a direct correlation between hashrate (aka how fast blocks are found) and how fast/cheap/expensive transactions are, indeed the number of transactions has more weight in the equation because the number of transactions is infinite while the time to find blocks is always >0.

Using the simple ABC of economics which is supply and demand, the number of transactions is "demand" and the number of blocks found is the "supply".

[tranthidung]

Using the 30 days MA will always give you "terrible" results, the number of blocks found in 30 days is a drop in the ocean as far as the 210,000 blocks are concerned, so getting 7 years halving estimate is pretty normal, getting 2 years is also nothing out of the ordinary, can you do another analysis from the last halving to the latest block? one more thing, you should use block time, ignore the confirmation thing, I remember you made a topic about empty blocks? you could use the same data from LoyceV.

Thank you.

It is my mistake from carelessness with the likely wrong term from bitinfocharts.com. From my mistake, I looked back and see they use confirmation time ~ block time.

This discussion sheds a light for me that the confirmation time shows how generous or parsimonious or relevant people do their bitcoin transactions over time. There are some factors behind (knowledge, practice, skills, urgent needs, etc.) but somewhat can give us some ideas.

[LoyceV]

Difficulty adjustment is limited by a factor of 4 in this code, so this can only slow miners by a factor of 4 in the best-case scenario
~
So it can't be more than 400% of the previous epoch and not less than 25%, which means if hypothetically the hashrate keeps going real fast ( 40 times higher constantly with every adjustment) we will be able to mine 210,000 blocks as fast as our hard drives can handle.
~
I believe Satoshi knew this wasn't going to happen because of the nature of people, money, and technology limitation, not because of the code itself.

Even worse: if the hashrate can go up 400% in 2 weeks, a hardware manufacturer could easily do a 51% 81% attack by stashing his hardware for a few weeks. If that happens Bitcoin has bigger problems, but luckily it's not very likely to replace all existing mining hardware several times in 2 weeks.
The 25% adjustment is more likely to happen (as in: there are no physical limits that make it impossible): if Bitcoin's value drops to $100 tomorrow, most miners will turn off their equipment. It will take a very long time to complete the blocks for a difficulty adjustment, and lowering difficulty to 25% won't be enough to make it worth mining again, so this has to happen several times before blocks go back to their 10 minute average.