Thanks for this proposal!
I’m generally in favour of smooth transitions rather than abrupt changes. They are more predictable for users, and easier for developers to code and test correctly.
But I think there might be a vulnerability in one of the issuance rules in the proposal:
The parameter X% is calculated from the block target time so that without any incoming Fund deposits, the balance of the Fund reduces to half over a four year period.
I’m concerned that we’re using a miner-specified value in this issuance rule.
I’m not sure exactly what the block target time is, but I’m assuming it’s based on the median-time-past of the block, which depends on the block timestamps provided by miners in recent blocks:
Here is an attack that gives some miners more fees than others:
- if the mining pool controls a large proportion of the total hash rate, set the block timestamp as low as possible, to increase X% for future blocks mined by the pool
- if a mining pool controls a small proportion of the total hash rate, set the block timestamp as high as possible, to reduce X% for future blocks mined by other pools (therefore preserving more balance for the blocks occasionally mined by this pool)
This attack is compatible with the current consensus rules, as long as the block times are:
[1, 90 * 60] seconds after the median-time-past for the block
- less than 2 hours in the future, according to the node’s local clock
For example, it is valid for each block time to be 1 more than the previous block time, even if the block took 75 seconds to mine.
Because some of these consensus rules depend on the node’s local clock, this rule also provides incentives to attack node clocks. For example, these attacks could happen via the Network Time Protocol (NTP).
There are also incentives for miners to prefer forks depending on their block times, or rollback blocks with high or low block times.
The difference in X% caused by these strategies might not actually yield a large number of Zats. But the cumulative effect on the protocol could be significant. And attacks can also impact the reputation of the protocol.
Fortunately, there’s an easy fix here - use the block height instead. It’s strictly constrained by the consensus rules to a single value: one more than the previous block.
We could calculate X% for each block height using some combination of:
- the target block spacing, and
- the actual block spacing over the past N years.
It’s not quite as neat as using the block time, but it’s a lot more robust.