I don’t know if this has ever been discussed in the history of Bitcoin. But we had a short discussion on Telegram about this and I thought it might be worth making a topic here.
Wouldn’t it be smart additionally to halving the reward to also half the difficulty? Wouldn’t that completely negate the negative effect on blocktimes? The only negative effect I could think of are rapid blocks right after a halving. Which would be a much smaller problem to have in my opinion.
We are discussing this here. But per my latest comment, I don’t see any way to “fix” this, nor do I believe it is something that needs to be fixed.
Actually, that would be really smart.
I do agree it is smart, but I don’t agree we should alter the chain to do so.
Here is why:
the halving causing half the hashpower is only an issue while multiple non-trivial chains are using the same hashing hardware. With a halving every 4 years, the problem may fix itself if not the next time then the one after. A BTC at 1% the value of BCH is not going to cause an issue.
The DAA adjusts under normal circumstances pretty quickly. So even if half the hashpower would leave, it should not be an issue more than a day, maybe two.
The cost of changing is massive.
What does worry me, though, is the DAA itself.
The basic concept of the DAA is that it takes the number of blocks we should have had and looks how far we are off from what we actually have.
Now, if you have 101 blocks while you should have had 100 blocks, this is a 1% change and the DAA adjusts accordingly.
But we’ve had 100000 blocks and we’re off by 3 blocks. This raises the question how fast the DAA is adjusting. As I expect it to adjust as agressive as being late 3 blocks at any other time. But the percentage change is obviously much less, so…
Any DAA expert willing to shed a light on this ?
It adjusts as you expect it to, with one distinction: the lateness is expressed in seconds, not in blocks.
Recall that ASERT stands for absolutely scheduled exponentially rising targets. The adjustment is invariant of current block height, but that’s not obvious from the formulae.
These are the formulae, adapted (from Toomim’s writeup):
From those we can simply calculate relative adjustment by dividing some blocks difficulty with the difficulty of block before:
The constants cancel each other out, and 2 targetTimestamps reduce to a constant of -10min and we get:
It is just the block time deviation and tau which affect the magnitude of adjustment, and in the spec the tau has been set to 172800 seconds (2 days).
Why 2 days? There’s a section on that in the spec:
A half-life of 2 days (
halflife = 2 * 24 * 3600), equivalent to an e^x-based time constant of2 * 144 * ln(2)or aserti3-415.5, was chosen because it reaches near-optimal performance in simulations by balancing the need to buffer against statistical noise and the need to respond rapidly to swings in price or hashrate, while also being easy for humans to understand: For every 2 days ahead of schedule a block’s timestamp becomes, the difficulty doubles.
This sounds smart, but there is one issue: how do you know that the reward will halve? The transaction fees cannot be known in advance and probably will not halve. In the distant future where transaction fees are the main component of the reward, this change would actually deteriorate block time consistency!
Your expectation is correct, the percentage change does not matter. Being 30 minutes behind schedule has the same effect regardless of current block height.