The dev claimed on Telegram that
“network was frozen from a scheduled hard fork that was already in Grin source code, so we had to update it and remove that scheduled fork. If I only did that an released it we would end up with lots of forked chains because it actually froze because the update didnt happen *before* the scheduled hard fork block”
which is nonsense. The old code simply refused any block at height >= 2 * HARD_FORK_INTERVAL = 524160, while the new code allows blocks past that height. Thus there is nothing at height >= 524160 that the old
and new code could disagree on. Only the new code would be active in the new, unfrozen regime.
The only motivation for the other change is for a poorly hidden 5B premine, by changing
pub fn adjusted_block_reward() -> u64 {
return (4.5 * BITGRIN_BASE as f64) as u64;
}
into
pub fn adjusted_block_reward() -> u64 {
if height == YEAR_HEIGHT {
return (5 * BITGRIN_BASE * BITGRIN_BASE as f64) as u64;
} else {
return (4.5 * BITGRIN_BASE as f64) as u64;
}
}
But since that would be a little too obvious,
the dev split out the 5 * BITGRIN_BASE part into a separate function
fn year_block_overage() -> f64 {
// reward — fee per block for this block
return (BLOCK_REWARD as f64) * (BITGRIN_BASE as f64);
}
which he moved up a few functions in the source file while moving the other part
pub fn adjusted_block_reward(height: u64) -> u64 {
if height == YEAR_HEIGHT {
return (year_block_overage() * BITGRIN_BASE as f64) as u64;
} else {
return (4.5 * BITGRIN_BASE as f64) as u64;
}
}
a few functions down in the source file, making sure they would not be visible together in one screen.
He then obfuscated the logic further with a totally unnecessarily branch:
} else if height > YEAR_HEIGHT {
// After first year
return (4.5 * BITGRIN_BASE as f64) as u64;
}
return (4.5 * BITGRIN_BASE as f64) as u64;
Nice try!