- I understand and agree with your example.
- Right, I don’t see why the BIP thinks it’s 2017 instead of 2018. I bolded the unexplained jump in logic in the BIP that I didn’t follow.
- You agree that making the limit 600 seconds is at least as safe as 7200?
Rather than 2017 / 2018, we’re measuring a timespan across 2015 blocks, so via Erlang we expected 2014 blocks. Therefore the adjustment is supposed to be “2014_blocks / 2015_expected_solvetimes”. But the code calculates “2016_blocks / 2015_times”. Allowing +600 in the denominator makes it 2016 / 2016. But we should add 1 to the numerator if we’re going to add one to the denominator: (2014+1) / (2015 + 1) = 2015 / 2016. So 2016 / 2016 is too large.
For your example of subtracting 600 at the beginning and end, the difficulty is too much as always 2016 / 2015 instead of “staying constant” with 2014 / 2015, i.e. it’s taking 600.6 seconds / block (2 weeks + 20 minutes). So G = 3 * 600 in order to solve in 2 weeks minus 10 minutes?