Specify BIP9 deployment for DynaFed

[stevenroose]

Bit: 25 (identical to current elementsregtest dynafed bit)
Start: block 1,000,000 (recent past)
Timeout: never

[gwillen]

Looks reasonable to me. We should make sure to think very carefully about the implications of this. It's problematic to test, by its very nature (it's a change that only affects the non-test network.)

[jonasnick]

What's the rationale behind setting the start time to a block in the past instead of in the future?

[gwillen]

Hm, is my understanding correct (I hope) that this change will not actually cause any BIP 9 signalling, merely enable it to happen in the future?

If so, it seems like it shouldn't matter what we set the start time to, and setting it in the past is fine, giving us maximum flexibility.

[stevenroose]

@jonasnick yeah it shouldn't matter much and for rememberability, it seemed to make sense to pick a round number. The bit is not used today so it can't accidentally trigger the update. Nor do we expect the bit to be used before this is released, as we're not updating the blocksigners.

[jonasnick]

Okay, so iiuc the reason is that only blocksigners can exercise the hard fork rules. They can not even do that prematurely to fork the chain because the current dynafed code has been released more than 10 months ago (and they wouldn't have an incentive to do that).

[jonasnick]

After thinking about this again, this reasoning is incorrect. The dynafed code has been released but without the versionbit it's not active and therefore users that don't update can end up on a stalled chain if the blocksigners exercise the hardfork rules early. Considering the Liquid trust model this is not a significant issue. ACK afcb71f