MIME-Version: 1.0
In-Reply-To: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
References: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
Date: Fri, 29 Jan 2016 11:39:14 -0500
Message-ID: <CABsx9T0oY2OuPCRgnQmqbLOBSQVd-yuQ8mMXjfzYpJTjXn8woQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Jannes Faber <jannes.faber@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b342fd4f6f815052a7bacf4
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
Precedence: list

--047d7b342fd4f6f815052a7bacf4
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>
>
Block timestamps are in the 80-byte block header, so activation is
completely deterministic and can be determined from just the sequence of
block headers. There are no edge cases to worry about.

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.
>

It doesn't matter much where in the difficulty period the fork happens; if
it happens in the middle, the lower-power fork's difficulty will adjust a
little quicker.

Example:  (check my math, I'm really good at screwing up at basic
arithmetic):

Fork at block%2016:  25% hashpower will take 8 weeks to produce 2016
blocks, difficulty drops by 4.

Fork one-week (halfway) into difficulty period:  25% hashpower will take 4
weeks to adjust, difficulty drops by 5/2 = 2.5
It will then take another 3.2 weeks to get to the next difficult adjustment
period and normal 10-minute blocks.

That's an unrealisitic scenario, though-- there will not be 25% of hash
power on a minority fork. I wrote about why in a blog post today:

http://gavinandresen.ninja/minority-branches

If you assume a more realistic single-digit-percentage of hash power on the
minority fork, then the numbers get silly (e.g. two or three months of an
hour or three between blocks before a difficulty adjustment).


-- 
--
Gavin Andresen

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

<div dir=3D"ltr"><div>On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bit=
coin-dev=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt;</span>=C2=A0wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><p dir=3D"ltr">Hi,</p><p dir=
=3D"ltr">Question if you&#39;ll allow me. This is not about Gavin&#39;s lat=
est 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 instead=
 of in block time:</p><p dir=3D"ltr">&gt; Blocks with timestamps greater th=
an or equal to the triggering block&#39;s timestamp plus 28 days (60*60*24*=
28 seconds) shall have the new limits.</p><div><br></div></blockquote><div>=
=C2=A0</div></div><div>Block timestamps are in the 80-byte block header, so=
 activation is completely deterministic and can be determined from just the=
 sequence of block headers. There are no edge cases to worry about.</div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><p dir=3D"ltr">But even more so I would expec=
t there to be significant differences in effects on non-updated clients dep=
ending 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.=
</p></blockquote><div><br></div><div>It doesn&#39;t matter much where in th=
e difficulty period the fork happens; if it happens in the middle, the lowe=
r-power fork&#39;s difficulty will adjust a little quicker.</div><div><br><=
/div><div>Example: =C2=A0(check my math, I&#39;m really good at screwing up=
 at basic arithmetic):</div><div><br></div><div>Fork at block%2016: =C2=A02=
5% hashpower will take 8 weeks to produce 2016 blocks, difficulty drops by =
4.</div><div><br></div><div>Fork one-week (halfway) into difficulty period:=
 =C2=A025% hashpower will take 4 weeks to adjust, difficulty drops by 5/2 =
=3D 2.5</div><div>It will then take another 3.2 weeks to get to the next di=
fficult adjustment period and normal 10-minute blocks.<br></div><div><br></=
div><div>That&#39;s an unrealisitic scenario, though-- there will not be 25=
% of hash power on a minority fork. I wrote about why in a blog post today:=
</div><div><br></div><div><a href=3D"http://gavinandresen.ninja/minority-br=
anches">http://gavinandresen.ninja/minority-branches</a><br></div><div><br>=
</div><div>If you assume a more realistic single-digit-percentage of hash p=
ower on the minority fork, then the numbers get silly (e.g. two or three mo=
nths of an hour or three between blocks before a difficulty adjustment).</d=
iv><div><br></div><div class=3D"gmail_extra"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>--<br>Ga=
vin Andresen<br></div><div><br></div></div></div></div></div>
</div></div>

--047d7b342fd4f6f815052a7bacf4--