MIME-Version: 1.0
In-Reply-To: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
From: Bram Cohen <bram@bittorrent.com>
Date: Tue, 4 Jul 2017 20:39:09 -0700
Message-ID: <CA+KqGkqMtHzxzKObn7OkXsdrP4sKOFm-z1bJWThhPe4jXFmzDw@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114435122d7d96055389beec"
Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
Precedence: list

--001a114435122d7d96055389beec
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps in a way that could prevent or delay
> activation - for example by only advancing the block timestamp by 1 second
> you would never meet the threshold (although this would come a the penalty
> of hiking the difficulty dramatically).
>
> On the other hand, the exact date of a height based thresholds is hard to
> predict a long time in advance due to difficulty fluctuations. However,
> there is certainty at a given block height and it's easy to monitor.
>

You could get most of the best of both with a combination of the two: Have
the activation be a timestamp plus a certain number of blocks to come after
maybe about 100, which is more than enough to make sure all the games which
can be played with timestamps have passed but a small enough amount that it
doesn't add much uncertainty to wall clock time.

--001a114435122d7d96055389beec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div>Some people have criticized BIP9&#39;s blocktime =
based thresholds arguing they are confusing (the first retarget after thres=
hold). It is also vulnerable to miners fiddling with timestamps in a way th=
at could prevent or delay activation - for example by only advancing the bl=
ock timestamp by 1 second you would never meet the threshold (although this=
 would come a the penalty of hiking the difficulty dramatically).<br></div>=
<div><br></div><div>On the other hand, the exact date of a height based thr=
esholds is hard to predict a long time in advance due to difficulty fluctua=
tions. However, there is certainty at a given block height and it&#39;s eas=
y to monitor.<br></div></blockquote><div><br></div><div>You could get most =
of the best of both with a combination of the two: Have the activation be a=
 timestamp plus a certain number of blocks to come after maybe about 100, w=
hich is more than enough to make sure all the games which can be played wit=
h timestamps have passed but a small enough amount that it doesn&#39;t add =
much uncertainty to wall clock time.</div><div><br></div></div></div></div>

--001a114435122d7d96055389beec--