What are the advantages of a 210,000-block subsidy halving interval that's out-of-sync with retargeting?

Question

The block subsidy halves every 210,000 blocks. Where could this number reasonably have come from? I'm not talking about the idea of a four year interval. 210,000 is quite close to four years given 10-minute blocks - let's just assume that's the ballpark Satoshi was after.

The most obvious problem is that 2,016 (the retargeting block interval) isn't a factor of 210,000. This puts the block subsidy halving and retargeting intervals out of sync.

For example, the subsidy halving interval might have been set at 209,664 blocks. At 10 minutes/block, this would have put the halving interval at very close to 4 years (~3.99).

Granted, retargeting and subsidy halving don't appear to be related. Nevertheless, it seems awkward to create unsynchronized adjustment events.

1. Was Satoshi just trying to keep things simple by choosing 210,000, or is there something I'm missing?
2. What attacks might be feasible under a synchronized halving schedule that wouldn't be possible under the existing one?

Answer 1

We do not know whether it was a deliberate choice or an oversight that the difficulty interval is not a factor of the halving interval. Instinctively, I'd suspect that both were chosen on their own to be round numbers in their context: 14 days worth of 10 minute intervals, and a 4 year intervals starting with 50 ₿ rounded to the next ten thousand. Choosing a halving interval of 209,664 blocks would have prevented either a nice round numbers for subsidies or the final supply. Today, we know that especially the supply has become an important meme in explaining Bitcoin. Generally, non-round numbers can mean an increase in complexity.

^{via https://btc.com/stats/diff}

Let's look at what happened at the third halving. The halving in May at block 630,000 was exactly in the middle of the two difficulty adjustments at block 628,992 (+0.92%) and 631,008 (-6.00%). Assuming that the profitability drop of the halving led to miners turning off their hardware exactly then, one could suspect that the shift between the two periods could have smoothed out some of the congestion the slowdown: instead of one long period of extremely slow blocks, the difficulty adjusted across two periods with a shorter period of very slow blocks and a long period of less slower blocks. Since the blockspace supply is inelastic, this may have reduced the overall congestion. On the other hand, congestion can also significantly drive up transaction fees, which in turn could incentive miners bringing shutdown hardware back online.

Either way, the difference is very small.

If the halving would have coincided with a difficulty adjustment and the complete hashrate drop happened with the halving block, we would have expected the complete difficulty reduction of 6.00% and 9.29% in one period. Then, we would have expected the first difficulty period to have taken (14/(1*0.9400*0.9071)) = 16.38 days. If the second period would have then been balanced, and we would have reached 1.5 difficulty periods after the halving in:

16.38 days + 7 days = 23.38 days

Our record shows that the halving block is timestamped at 2020-05-11 19:23 UTC and the second adjustment after the halving at block 633,024 has a timestamp of 2020-06-04 12:30 UTC. This amounts to 23.7 days. Unsurprisingly, fully adjusting downward immediately would have led to a shorter time. However, as mentioned above it might have also caused more congestion due to the already slower blocks in the period directly after the halving, driving feerates even higher which in turn could have sped up blocks a bit.

In the end, it would likely not have made a huge difference if they had been aligned, and it will even less so in the following halvings under the assumption that the total transaction fees will remain at least at this absolute level, since the subsidy will then be a smaller relative part of the total reward.