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 5D648C9C for ; 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 ; Fri, 29 Jan 2016 16:39:16 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id x4so44493807lbm.0 for ; 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: References: Date: Fri, 29 Jan 2016 11:39:14 -0500 Message-ID: From: Gavin Andresen To: Jannes Faber 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 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 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

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



<= /div>
Example: =C2=A0(check my math, I'm really good at screwing up= at basic arithmetic):

Fork at block%2016: =C2=A02= 5% hashpower will take 8 weeks to produce 2016 blocks, difficulty drops by = 4.

Fork one-week (halfway) into difficulty period:= =C2=A025% hashpower will take 4 weeks to adjust, difficulty drops by 5/2 = =3D 2.5
It will then take another 3.2 weeks to get to the next di= fficult 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:=


=
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).


--
--
Ga= vin Andresen

--047d7b342fd4f6f815052a7bacf4--