diff options
| author | Gavin Andresen <gavinandresen@gmail.com> | 2016-01-29 11:39:14 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-01-29 16:39:17 +0000 |
| commit | d58bd59f1f5b482279af38faec33db36bfad68c7 (patch) | |
| tree | da72437eaa6bf7c1e9863d8773adafc2f0f9b1b2 | |
| parent | 023adc6c27085a6e3e15ea45c1bae32efd0df05d (diff) | |
| download | pi-bitcoindev-d58bd59f1f5b482279af38faec33db36bfad68c7.tar.gz pi-bitcoindev-d58bd59f1f5b482279af38faec33db36bfad68c7.zip | |
Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
| -rw-r--r-- | 99/5f3b6a134c121757cc0496f5674a5983af2feb | 175 |
1 files changed, 175 insertions, 0 deletions
diff --git a/99/5f3b6a134c121757cc0496f5674a5983af2feb b/99/5f3b6a134c121757cc0496f5674a5983af2feb new file mode 100644 index 000000000..ee5317abd --- /dev/null +++ b/99/5f3b6a134c121757cc0496f5674a5983af2feb @@ -0,0 +1,175 @@ +Return-Path: <gavinandresen@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D648C9C + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 29 Jan 2016 16:39:17 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com + [209.85.217.179]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A26112E + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 29 Jan 2016 16:39:16 +0000 (UTC) +Received: by mail-lb0-f179.google.com with SMTP id x4so44493807lbm.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 29 Jan 2016 08:39:16 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=4xwcivgrPSSR70psc2+/q4ZnsRje5HsFQW4930nPV0M=; + b=znHPtlsICg0kGBy5p68sVw3qaRqwH3x6EeJizcdSqA+Thy6i/vz5rnsGjEJHFhWbz7 + uFp+zt08wfk2JDBmcGIUpTzB2wS3HtbvO7tKHQI13jie47bSuLd25OOojbQKcMHL9PWv + oVPigGXimgo7CyF9kiGLnFjQ9RSrmyhbc0e7I6/O4Kg0bFqrqf/CjUZwTYKmj0dgUaFo + qaxvpIoviECLWuDBnRUpB4WMN2bum1ALeIcqx05Lou9G45VAXVDFAX7OQ6geF8kKU9Sk + /ixvnT0NgXvu1fC0ajpJh20DX7DadBGpovwET6RIRMdfd79/xWuMpck6iKBlA3ejI+8P + jS9Q== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:date + :message-id:subject:from:to:cc:content-type; + bh=4xwcivgrPSSR70psc2+/q4ZnsRje5HsFQW4930nPV0M=; + b=BjjJ4j542lk5HfTMaBVD4/b4/kiZQf5PrcvaUi0YfvqxyiD/ajqBlXZl713DraqGOT + QyxyfxAM5MtzOF3yG9wHOU/9pN0PwwfsjJ1LsV7Ur+whWl3XtRs+teVj0TaNGAWVlsQn + 0dkJBzl6RoAgHXfj/KL+QhwAOIJ16m3DN06MCq1a8tu1GTHZXgx2YHC0gXD9cYugaJQk + UfDDHYuJQ5C+kV3XOrMbstCKhsqXCnNdxoGP6P2LWUUWxsSAd3OqGpKv2FQ4OhGGIX3Y + QyXDYXeZkPwN69btT2wX57xJZ4b1Q+PSM3i32rpjgHO0C7ROw5syhfPYHj+S66LNcOi+ + +Jrw== +X-Gm-Message-State: AG10YOScC3139SdNccvu0ZmBxF/d6q4Zcb7dIvfIGqrZ13JyMHS1xNOzOFz1fbfM81h7kln+982UywUbyf91DQ== +MIME-Version: 1.0 +X-Received: by 10.112.144.226 with SMTP id sp2mr3661807lbb.70.1454085554760; + Fri, 29 Jan 2016 08:39:14 -0800 (PST) +Received: by 10.25.79.208 with HTTP; Fri, 29 Jan 2016 08:39:14 -0800 (PST) +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 +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Fri, 29 Jan 2016 16:57:33 +0000 +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation? +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 29 Jan 2016 16:39:17 -0000 + +--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"><<a href=3D"mailto:bitcoin-dev@lists.lin= +uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</= +a>></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'll allow me. This is not about Gavin'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">> Blocks with timestamps greater th= +an or equal to the triggering block'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't matter much where in th= +e difficulty period the fork happens; if it happens in the middle, the lowe= +r-power fork's difficulty will adjust a little quicker.</div><div><br><= +/div><div>Example: =C2=A0(check my math, I'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'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-- + |