The logic (as I understand it) for the difficulty changes are: [old target] * [actual time] / [expected time] = [new target].
Here's the old target (what block 24191 has) and the new target (what block 24192 has):
new target: 0000000000006b32b10000000000000000000000000000000000000000000000 (bits of 0x1a6b32b1)
But here's what my math arrives at:
The timestamp on block 24191 is 1319487998. Block 22176 (2016 blocks before 24192, the first one with the difficulty bits of 0x1a6b32b1) has a timestamp of 1318761282. The difference of those two (actual time spent) is 726716, which makes [actual]/[expected] = 0.600790343915344. Hence I get a new target of:
Close, but not quite. Taking the new difficulty that apparently is valid, I get a ratio of 0.6008515185394, arriving at an actual timestamp of 1319488072. That's 74 seconds after the timestamp of 24191. My retargeting math has worked for all the previous retargets, so why did this one go wonky? Was there some different logic in place for this block round that allowed a slightly different difficulty retarget? Is this a rounding error (after multiplying the old target by the actual time spent, do I need to truncate it before dividing it out)?