From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 22EE7F9C for ; 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 ; 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 To: Jannes Faber Message-ID: <20160129191152.GA18253@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--