Okay, here's a technical question; I've got an issue trying to get my namecoin port to validate the block at height 24192
. That's a point where the difficulty target changes (24192 % 2016 = 0), and it looks to me like the difficulty moved incorrectly, and yet it's in the blockchain as valid.
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):
old target: 000000000000b269000000000000000000000000000000000000000000000000 (bits of 0x1b00b269)
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:
my target: 0000000000006b2fe50000000000000000000000000000000000000000000000 (bits of 0x1a6b2fe5)
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)?