[bitcoin-dev] Best (block nr % 2016) for hard fork activation?

Jannes Faber jannes.faber at gmail.com
Fri Jan 29 02:31:05 UTC 2016


Hi,

Question if you'll allow me. This is not about Gavin's latest hard fork
proposal but in general about any hard (or soft) fork.

I was surprised to see a period expressed in human time instead of in block
time:

> Blocks with timestamps greater than or equal to the triggering block's
timestamp plus 28 days (60*60*24*28 seconds) shall have the new limits.

But even more so I would expect there to be significant differences in
effects on non-updated clients depending on the moment (expressed as block
number) of applying the new rules. I see a few options, all relating to the
2016 blocks recalibration window.

1) the first block after difficulty adjustment.
2) the last block before the difficulty adjustment.
3) in the middle
4) n blocks before the adjustment with n the smallest number of blocks
calculated such that the adjustment can just manage to do the maximum
possible drop in difficulty.

One of the effects I'm thinking of would be in case of an evil contentious
75-25 hard fork. If that activates at 1) or 2) it will take an awful long
time for the 25% chain to get to 2016 for the next adjustment all the while
having 40 minutes block times. Option 4) sounds a lot better for the
conservative chain. The attacking fork clearly has a choice to make it as
hard as possible for them.

On the other hand when a non-contentious hard fork is rolled out, one could
argue that it's actually best for everyone if the remaining 1% chain
doesn't stand a chance of ever reaching 2016 blocks anymore (not even by a
decent sized attacker trying to double spend on stragglers). Also causing
all alarm bells to go off in the non-updated clients.

Have people thought through all the different scenarios yet?

And would it not make sense to define whatever the best choice is as
mandatory for any hard fork proposal? BIP9? (Realising attackers won't
necessarily follow BIPs anyway.)

Does something like this also play a role for soft forks?

I do realise that it's quite possible for the first few blocks, mined after
the new rules become valid, to still be old style blocks. Thus maybe
defeating the whole planning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160129/09171b31/attachment.html>


More information about the bitcoin-dev mailing list