Testnet3 difficulty transition problem?

Both blocks

38304 00000000015bb4069249fa1f41ae61d8a7447aaacc33c50dacd3c3654377fa43

and

40320 000000008011f56b8c92ff27fb502df5723171c5374673670ef0eee3696aee6d

are difficulty transition blocks. However, block 40320 has a difficulty of 1. I know there is this special testnet rule that allows mining a block at difficulty 1, but I always thought you can't use this exception on difficulty transition blocks.

As a result, bitcoinj based clients do not advance their blockchain past block 40319.

On Sat, Dec 22, 2012 at 1:39 PM, Andreas Schildbach <andreas@schildbach•de> wrote:

> Both blocks
>
> 38304 00000000015bb4069249fa1f41ae61d8a7447aaacc33c50dacd3c3654377fa43
>
> and
>
> 40320 000000008011f56b8c92ff27fb502df5723171c5374673670ef0eee3696aee6d
>
> are difficulty transition blocks. However, block 40320 has a difficulty
> of 1. I know there is this special testnet rule that allows mining a
> block at difficulty 1,

Yes.

> but I always thought you can't use this exception
> on difficulty transition blocks.

Not so— but what you're actually seeing is that difficult change is relative to the prior block's difficulty. E.g. if the penultimate block in the difficulty cycle is under the special rule the difficulty change will be relative to 1.

(I had intentionally avoided triggering that test case when adding the timewarp attack to the testnet chain in case we had wanted to fix it prior to testnet3's release— I guess I should have added it sooner in order to catch the bitcoinj misbehavior!)

I pushed a fix for this.