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 CCFD3FDF for ; Fri, 29 Jan 2016 02:31:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D64CC8A for ; Fri, 29 Jan 2016 02:31:09 +0000 (UTC) Received: by mail-lf0-f43.google.com with SMTP id 17so38760344lfz.1 for ; Thu, 28 Jan 2016 18:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gvbKJfGmWK5I5a3yqv4AK2hyIDHwRyfvFsPATHhHIuI=; b=ZSj09ZQbkIhT/yNJpaJWoArL26OSCTIFP0BxGgm3KmzyL1ekiO34K2vv9GZJI97RMA lDChKBQScIy2w1xCSHVXy73WSOg3phVbYAqPfslS8qsmC4LhomAk1f/eX6vLEu8VcnoC AIj9vuuJD2wEyniNmJMcduBGTu2x0OpgZQRFr/Vst8a0rYouuB3V2CpTktEwdK7USL9B kCg3QeUkwe5FgmNHuZ28Ll8wc/P/oxWWuwxxsl7UpCiN1PNFfiizOiprfjgLz8xUbTu0 Mml4Jyg7SxfFluVycFYWy5bdy+E9LrbXPjp1SID4TRbU5NhECwuctm1/3kk0ZpzHLego WYbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=gvbKJfGmWK5I5a3yqv4AK2hyIDHwRyfvFsPATHhHIuI=; b=WFQyiuiliysIQ3Kq7lAZVqXJYaQs996aT+lhlJNB+jmG2pdGqLZ5smrp46ywQbDsNY ICYtm+YRdzZTbcE7hyJoVGlodOy68HD7S3INTzBvIP+Bw+vCJ5tEJYtTaTapPnI8sFEL 521dlWeUHKq1KRBNineOfT1U9jlEyvOoX9s8eN32TLSixBDja1NtDc3wGIkWBJ+ATiYS 8a7t4CVTZKP2OJDjTmpbNTwMTTUq6/CzO8S+OUxfQ5ZC6icmxkHnXASZYIiG2OhXXjge R/7gHffBsiAxBXtUtxMc1txEqkvRCVgoTYz24/iz2+IZqNYZZH7enijDMRnExBTUSMlc bXag== X-Gm-Message-State: AG10YOTSRaTpH96aPVaMqwDqyCGx/SnMMEF0Y6ztMOrsTAVfBgQzGsm2npvFQeKz3RHz7Q== X-Received: by 10.25.21.29 with SMTP id l29mr241922lfi.123.1454034668261; Thu, 28 Jan 2016 18:31:08 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com. [209.85.217.169]) by smtp.gmail.com with ESMTPSA id l129sm1754885lfl.37.2016.01.28.18.31.07 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 18:31:07 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id dx2so33749062lbd.3 for ; Thu, 28 Jan 2016 18:31:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.137.41 with SMTP id qf9mr2358093lbb.140.1454034666577; Thu, 28 Jan 2016 18:31:06 -0800 (PST) Received: by 10.112.211.161 with HTTP; Thu, 28 Jan 2016 18:31:05 -0800 (PST) Received: by 10.112.211.161 with HTTP; Thu, 28 Jan 2016 18:31:05 -0800 (PST) Date: Fri, 29 Jan 2016 03:31:05 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Jannes Faber To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e01177191cb73bc052a6fd301 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 03:41:23 +0000 Subject: [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 02:31:10 -0000 --089e01177191cb73bc052a6fd301 Content-Type: text/plain; charset=UTF-8 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. 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. 1) the first block after difficulty adjustment. 2) the last block before the difficulty adjustment. 3) in the middle 4) n blocks before the adjustment with n the smallest number of blocks calculated such that the adjustment can just manage to do the maximum possible drop in difficulty. One of the effects I'm thinking of would be in case of an evil contentious 75-25 hard fork. If that activates at 1) or 2) it will take an awful long time for the 25% chain to get to 2016 for the next adjustment all the while having 40 minutes block times. Option 4) sounds a lot better for the conservative chain. The attacking fork clearly has a choice to make it as hard as possible for them. On the other hand when a non-contentious hard fork is rolled out, one could 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. Have people thought through all the different scenarios yet? And would it not make sense to define whatever the best choice is as mandatory for any hard fork proposal? BIP9? (Realising attackers won't necessarily follow BIPs anyway.) Does something like this also play a role for soft forks? I do realise that it's quite possible for the first few blocks, mined after the new rules become valid, to still be old style blocks. Thus maybe defeating the whole planning. --089e01177191cb73bc052a6fd301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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.<= /p>

I was surprised to see a period expressed in human time inst= ead of in block time:

> Blocks with timestamps greater than or equal to the tri= ggering block's timestamp plus 28 days (60*60*24*28 seconds) shall have= the new limits.

But even more so I would expect there to be significant diff= erences in effects on non-updated clients depending on the moment (expresse= d as block number) of applying the new rules. I see a few options, all rela= ting to the 2016 blocks recalibration window.

1) the first block after difficulty adjustment.
2) the last block before the difficulty adjustment.
3) in the middle
4) n blocks before the adjustment with n the smallest number of blocks calc= ulated such that the adjustment can just manage to do the maximum possible = drop in difficulty.

One of the effects I'm thinking of would be in case of a= n evil contentious 75-25 hard fork. If that activates at 1) or 2) it will t= ake an awful long time for the 25% chain to get to 2016 for the next adjust= ment all the while having 40 minutes block times. Option 4) sounds a lot be= tter for the conservative chain. The attacking fork clearly has a choice to= make it as hard as possible for them.

On the other hand when a non-contentious hard fork is rolled= out, one could argue that it's actually best for everyone if the remai= ning 1% chain doesn't stand a chance of ever reaching 2016 blocks anymo= re (not even by a decent sized attacker trying to double spend on straggler= s). Also causing all alarm bells to go off in the non-updated clients.

Have people thought through all the different scenarios yet?=

And would it not make sense to define whatever the best choi= ce is as mandatory for any hard fork proposal? BIP9? (Realising attackers w= on't necessarily follow BIPs anyway.)

Does something like this also play a role for soft forks?

I do realise that it's quite possible for the first few = blocks, mined after the new rules become valid, to still be old style block= s. Thus maybe defeating the whole planning.

--089e01177191cb73bc052a6fd301--