diff options
| author | Peter Todd <pete@petertodd.org> | 2016-01-29 14:11:52 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-01-29 19:11:58 +0000 |
| commit | a77c795b9592316b0c85c181373db73cc5a7e319 (patch) | |
| tree | 25f294e2c5b6fafa71dbe13c1bdfe20a4e8073f8 | |
| parent | 4dd49509f96913fa31b8223a7782a585502dd9f0 (diff) | |
| download | pi-bitcoindev-a77c795b9592316b0c85c181373db73cc5a7e319.tar.gz pi-bitcoindev-a77c795b9592316b0c85c181373db73cc5a7e319.zip | |
Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
| -rw-r--r-- | e0/5561bae47c16e91c136961936cb7594906d222 | 140 |
1 files changed, 140 insertions, 0 deletions
diff --git a/e0/5561bae47c16e91c136961936cb7594906d222 b/e0/5561bae47c16e91c136961936cb7594906d222 new file mode 100644 index 000000000..f06aea7dd --- /dev/null +++ b/e0/5561bae47c16e91c136961936cb7594906d222 @@ -0,0 +1,140 @@ +Return-Path: <pete@petertodd.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 22EE7F9C + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 29 Jan 2016 19:11:58 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from outmail148114.authsmtp.net (outmail148114.authsmtp.net + [62.13.148.114]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 525708A + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 29 Jan 2016 19:11:57 +0000 (UTC) +Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) + by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u0TJBt0a062207; + Fri, 29 Jan 2016 19:11:55 GMT +Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com + [52.5.185.120]) (authenticated bits=0) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u0TJBrFR031709 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); + Fri, 29 Jan 2016 19:11:54 GMT +Received: from [127.0.0.1] (localhost [127.0.0.1]) + by petertodd.org (Postfix) with ESMTPSA id 4735540140; + Fri, 29 Jan 2016 19:08:47 +0000 (UTC) +Date: Fri, 29 Jan 2016 14:11:52 -0500 +From: Peter Todd <pete@petertodd.org> +To: Jannes Faber <jannes.faber@gmail.com> +Message-ID: <20160129191152.GA18253@savin.petertodd.org> +References: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" +Content-Disposition: inline +In-Reply-To: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com> +X-Server-Quench: 28cbe30a-c6bc-11e5-829e-00151795d556 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aAdMdAsUElQaAgsB AmAbWl1eUVx7XGc7 bghPaBtcak9QXgdq + T0pMXVMcUQUMe25D cHweURh1dwwIf3l5 ZwhgViMJCUd6JFsu + RBwHCGwHMGJ9YGIW BV1YdwJRcQRDe0tA b1YxNiYHcQ5VPz4z + GA41ejw8IwAXAilO XklNJ1YVSkVDGCR0 ClhYRWxxXAULQD97 + LxU8JhYSG1wSekw5 LVo/UE4ZNBlFYgAA +X-Authentic-SMTP: 61633532353630.1037:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 52.5.185.120/25 +X-AuthVirus-Status: No virus detected - but ensure you scan with your own + anti-virus system. +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 +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 19:11:58 -0000 + + +--r5Pyd7+fXNt84Ff3 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Fri, Jan 29, 2016 at 03:31:05AM +0100, Jannes Faber via bitcoin-dev wrot= +e: +> On the other hand when a non-contentious hard fork is rolled out, one cou= +ld +> 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. +>=20 +> Have people thought through all the different scenarios yet? + +I wrote up some of those risks in my "Soft Forks Are Safer Than Hard +Forks" post the other week: + +https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks + +I was writing mainly in terms of technical risks for deployment +non-controversial forks; for controversial forks there's many more +failure scenarios. In any case, on technical grounds alone it's obvious +that hard-forks without very high - 95% or so - activation thresholds +are quite dangerous. + +In general, it should be remembered that high activation thresholds for +hard-forks can always be soft-forked down after the fact. For instance, +suppose we initially used 100% support over the past one month of blocks +as a hard-fork threshold, but can't get more than 96% support. A +soft-fork with the following rule can be implemented: + + If 95% of the past blocks vote yes, voting against the hard-fork is + not allowed. + +As soft-forks can be rolled out quite quickly, implementing this in the +event that a hard-fork isn't getting sufficient support won't add much +delay to the overall process; as it is a soft-fork, only miners need to +adopt it for it to take effect. + +For this reason I'd suggest any hard fork use 99%+ activation +thresholds, measured over multi-week timespan. Hard-forks should not be +controversial for good social/political reasons anyway, so there's +little harm in most cases to at worst delaying the fork by two or three +months if stragglers won't upgrade (in very rare cases like security +issues there may be exceptions; blocksize is certainly not one of those +cases). + +--=20 +https://petertodd.org 'peter'[:-1]@petertodd.org +000000000000000005822b77a904129795a3ff4167c57ed1044f5a93512c830f + +--r5Pyd7+fXNt84Ff3 +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- + +iQGrBAEBCACVBQJWq7l0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw +MDAwMDAwMDAwMDAwMDAwN2RmNTNkZGEyODBmMTQxNjhjYTJlYjYzMmIxYjg2YmJh +YmE1ZDkwZjdkMzhiNjAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 +ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuzqgf/cuFXN2IT/l12nwrrzwO3KnuX +7MoeLwEhR8X0xIEd2lCrYyRKlFIFVV4F0fVzOl8fhLwBobZiGf0TylBYAHDf8DJN +G1Emn8nOuIqwjEFCpoEk+5niv4CUs5I7p7UVuKvjbRakMMEE358l4RJTaT6pJs7Q +3wXU3B81cUFPpOyVgLp/nksUgeJLLYnfBs6nF6mZZu655Zz15733H1ZPS3FYCMJb +0MputiDHLrGXu3vh67PYb08XtzvrufHI3KqGI9NVXlXCdG0aMkP+Hb4PU52VuN6H +sarBmUO70fRCw/d+WYq4+wr/85qTucSaAPhp+dPZ+x0QnPGLFitPI7hDTFmy5A== +=pNLE +-----END PGP SIGNATURE----- + +--r5Pyd7+fXNt84Ff3-- + |