MIME-Version: 1.0
Date: Fri, 29 Jan 2016 03:31:05 +0100
Message-ID: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
From: Jannes Faber <jannes.faber@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e01177191cb73bc052a6fd301
Subject: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
Precedence: list

--089e01177191cb73bc052a6fd301
Content-Type: text/plain; charset=UTF-8

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.

--089e01177191cb73bc052a6fd301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Hi,</p>
<p dir=3D"ltr">Question if you&#39;ll allow me. This is not about Gavin&#39=
;s latest hard fork proposal but in general about any hard (or soft) fork.<=
/p>
<p dir=3D"ltr">I was surprised to see a period expressed in human time inst=
ead of in block time:</p>
<p dir=3D"ltr">&gt; Blocks with timestamps greater than or equal to the tri=
ggering block&#39;s timestamp plus 28 days (60*60*24*28 seconds) shall have=
 the new limits.</p>
<p dir=3D"ltr">But even more so I would expect there to be significant diff=
erences in effects on non-updated clients depending on the moment (expresse=
d as block number) of applying the new rules. I see a few options, all rela=
ting to the 2016 blocks recalibration window.</p>
<p dir=3D"ltr">1) the first block after difficulty adjustment.<br>
2) the last block before the difficulty adjustment.<br>
3) in the middle<br>
4) n blocks before the adjustment with n the smallest number of blocks calc=
ulated such that the adjustment can just manage to do the maximum possible =
drop in difficulty.</p>
<p dir=3D"ltr">One of the effects I&#39;m thinking of would be in case of a=
n evil contentious 75-25 hard fork. If that activates at 1) or 2) it will t=
ake an awful long time for the 25% chain to get to 2016 for the next adjust=
ment all the while having 40 minutes block times. Option 4) sounds a lot be=
tter for the conservative chain. The attacking fork clearly has a choice to=
 make it as hard as possible for them.</p>
<p dir=3D"ltr">On the other hand when a non-contentious hard fork is rolled=
 out, one could argue that it&#39;s actually best for everyone if the remai=
ning 1% chain doesn&#39;t stand a chance of ever reaching 2016 blocks anymo=
re (not even by a decent sized attacker trying to double spend on straggler=
s). Also causing all alarm bells to go off in the non-updated clients.</p>
<p dir=3D"ltr">Have people thought through all the different scenarios yet?=
</p>
<p dir=3D"ltr">And would it not make sense to define whatever the best choi=
ce is as mandatory for any hard fork proposal? BIP9? (Realising attackers w=
on&#39;t necessarily follow BIPs anyway.)</p>
<p dir=3D"ltr">Does something like this also play a role for soft forks?</p=
>
<p dir=3D"ltr">I do realise that it&#39;s quite possible for the first few =
blocks, mined after the new rules become valid, to still be old style block=
s. Thus maybe defeating the whole planning.</p>

--089e01177191cb73bc052a6fd301--