Thanks for all the work you’ve been pouring into this CHIP @bitcoincashautist!
I’m strongly in favor, and I hope to have my own software ready for a 2027 upgrade tempnet in the next week or two. 
Nine-block overpayment at halving boundaries
There’s an issue in the halving calculation that should be corrected – in Block Subsidy:
// Subsidy is cut in half every 126,000,000 ticks which will occur approximately every 4 years.
SUBSIDY_HALVING_INTERVAL = 126'000'000 // ticks equivalent to 210,000 10-minute target intervals
int GetBlockSubsidy(int tick, int targetBlockTime) {
int halvings = tick / SUBSIDY_HALVING_INTERVAL;
// Base subsidy: 50 BCH = 5,000,000,000 satoshis
Amount subsidy = 5'000'000'000 * targetBlockTime / 600; // Scale by target block time expressed in ticks
// Subsidy is cut in half every 126,000,000 ticks which will occur
// approximately every 4 years.
return (subsidy >> halvings);
}
This divides each existing ten-minute subsidy into 10 one-minute subsidies. However, the next halving is “too late” for nine of the ten one-minute blocks that replace the halving block.
For example, with today’s schedule, the next halving occurs at ten-minute height 1,050,000. Block 1,049,999 will have a subsidy of 312,500,000 satoshis, while the halving block itself will have a subsidy of 156,250,000 satoshis.
With the CHIP’s current code, the 20 one-minute blocks replacing ten-minute heights 1,049,999 and 1,050,000 would have subsidies of: 19 blocks of 31,250,000 and the 1 halving block of 15,625,000. That means 9 of the 10 one-minute blocks which replace ten-minute height 1,050,000 will continue to pay the higher subsidy of the unhalved block – only the last one-minute block correctly adjusts down to the lower subsidy. In practice, that permits 1.40625 BCH more subsidy across those 20 one-minute blocks than the two corresponding original payments. (2.8125 BCH across the remaining schedule, net change of 2.5626 BCH after subtracting the 0.2499 BCH integer-division shortfall already mentioned in the CHIP.)
To avoid that additional inflation, we should simply assign installments to the corresponding ten-minute payment before calculating the one-minute subsidy:
- int halvings = tick / SUBSIDY_HALVING_INTERVAL;
+ int halvings = (tick + 600 - targetBlockTime) / SUBSIDY_HALVING_INTERVAL;
With that correction, the next halving correctly pays 10 one-minute blocks at 31,250,000 equivalent to ten-minute height 1,049,999 and 10 one-minute blocks at 15,625,000 equivalent to ten-minute height 1,050,000.
Note that this solution still “rounds down” some fractional satoshis that would otherwise be issued in the future (those fractional satoshis might ultimately be issued if BCH adds support for fractional satoshis). The first down rounding happens at ten-minute height 1,890,000, approx. ~2044.
It would also be possible to modulate the subsidy to more precisely match the ten-minute schedule – e.g. ten-minute height 5,670,000’s 37-satoshi subsidy would be paid out as 3, 4, 4, 3, 4, 4, 3, 4, 4, 4 over every 10 blocks. That’s harder to reason about and would mean that blocks don’t have a consistent subsidy between halvings, which seems like a footgun for ecosystem software vs. today’s consistent subsidies. I think it’s much preferable to either a) do the above and round all the payments down to 3, meaning that 7 fewer satoshis are minted per 10 blocks, or b) wait for BCH to support fractional satoshis, allowing the calculation to pay an even 3.7 for every block. (And of course, in practice, the goal is for BCH security to be primarily funded by transaction fees long before single-satoshi rounding differences make up a non-trivial percentage of the subsidy.)
