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 2F188E22 for ; Fri, 18 Dec 2015 20:20:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D1BAA125 for ; Fri, 18 Dec 2015 20:20:14 +0000 (UTC) Received: by mail-vk0-f45.google.com with SMTP id a188so72643119vkc.0 for ; Fri, 18 Dec 2015 12:20:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0pe2LWBHcmG3WDyTUrydfzTV9AEE+C+g2M8ytlqvZLY=; b=CEihEWNeVR8Dnw4WsfYtYAyZFLcKj6ONy1oGoguCezmU/19A2NmfX+9Z0GHYKtmRx3 2itttr7YtGxt7JSUZODi4vGA8b3CBDwoKvrvc1087mm54Oafd69w1ubIgeSLwLLrWhIa 24QXPUJTOsB+K7/ox1enXBvIglMhKkGK97/RY1VhMoJ0utOjwXtexLM6q+v/dfYaCGz3 kLApH3V1FaBXGjsfbiAa/zpd212bapYvHjnhXIBTYi8ixpU63dA/1GD8LYBZU5JeyUmD B+GqVYH4fU4xchbv8/1SYRsk7CwIJ5XemucM6KvYxN1UNUr475pq2iqGMJMqxWoEfWmR 2QqA== 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=0pe2LWBHcmG3WDyTUrydfzTV9AEE+C+g2M8ytlqvZLY=; b=AlexvbhTz3neIXauDZyYp29yXwkvVjlWVwiPd/9wf87NCBgzYOs7/07rlMPMAXCGju vmJnmUO8EYNvn7WRUhoyB4ZJU8p9jp9eAUPUZjFIUXK7r82+bJJ6wnttGXmIuvSyc/4y TAIXOI5wdsZEXCAnzNjRZQJeLhQVT8SRwGavhNWfJiIA4JXY4l/9na0faWnoaHBzI/HI AA8l8oexVSnFLfjPopUA3Y4OGRB9nBFn9C8SgeaAHIjo8Kb7bUwe+ZkhjhbiM5TIRfyE BbJe88YT4u9YNWAVYoWM4Zt/We0Nr7cVcOgEHVDB5bnRtjfOztY1QTgCIjJIZfvb8K9N Jf2Q== X-Gm-Message-State: ALoCoQnRYHTIoX8nXU5Z5EbC4sJXud28vjwx66NiosxYsaGexA7YeCfUNqo3gW7OVmmBhViGAlHKA4WUL8TATOkav3DTgFF8Sw== MIME-Version: 1.0 X-Received: by 10.31.154.213 with SMTP id c204mr3699632vke.38.1450470013957; Fri, 18 Dec 2015 12:20:13 -0800 (PST) Received: by 10.31.236.70 with HTTP; Fri, 18 Dec 2015 12:20:13 -0800 (PST) Received: by 10.31.236.70 with HTTP; Fri, 18 Dec 2015 12:20:13 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 21:20:13 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a1140f52cf09228052731dd07 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no 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] The increase of max block size should be determined by block height instead of block time 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, 18 Dec 2015 20:20:17 -0000 --001a1140f52cf09228052731dd07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe the attacks are the same for height or median time of the prev block are equal, only the time of the current block has more edge cases. On Dec 18, 2015 9:15 PM, "Jeff Garzik" wrote: > My preference is height activation + one step per block (i.e. also > height). Height seems KISS. > > AFAICT most of the attacks would occur around the already-heavily-watched > flag day activation event, in a height based environment, a useful > attribute. > > However I would like to hear from others about possible attacks with the > various approaches, before diverging from the default community approach = of > switch-based-on-time. > > > > > > > On Fri, Dec 18, 2015 at 3:10 PM, Jorge Tim=C3=B3n wrot= e: > >> Well, if it's not going to be height, I think median time of the previou= s >> block is better than the time of the current one, and would also solve C= hun >> Wang's concerns. >> But as said I prefer to use heights that correspond to diff recalculatio= n >> (because that's the window that bip9 will use for the later 95% >> confirmation anyway). >> On Dec 18, 2015 9:02 PM, "Jeff Garzik" wrote: >> >>> From a code standpoint, based off height is easy. >>> >>> My first internal version triggered on block 406,800 (~May 5), and each >>> block increased by 20 bytes thereafter. >>> >>> It was changed to time, because time was the standard used in years pas= t >>> for other changes; MTP flag day is more stable than block height. >>> >>> It is preferred to have a single flag trigger (height or time), rather >>> than the more complex trigger-on-time, increment-on-height, but any >>> combination of those will work. >>> >>> Easy to change code back to height-based... >>> >>> >>> >>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Tim=C3=B3n < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> I agree that nHeight is the simplest option and is my preference. >>>> Another option is to use the median time from the previous block (thus >>>> you know whether or not the next block should start the miner confirma= tion >>>> or not). In fact, if we're going to use bip9 for 95% miner upgrade >>>> confirmation, it would be nice to always pick a difficulty retarget bl= ock >>>> (ie block.nHeight % DifficultyAdjustmentInterval =3D=3D 0). >>>> Actually I would always have an initial height in bip9, for softforks >>>> too. >>>> I would also use the sign bit as the "hardfork bit" that gets activate= d >>>> for the next diff interval after 95% is reached and a hardfork becomes >>>> active (that way even SPV nodes will notice when a softfork or hardfo= rk >>>> happens and also be able to tell which one is it). >>>> I should update bip99 with all this. And if the 2 mb bump is >>>> uncontroversial, maybe I can add that to the timewarp fix and th recov= ery >>>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem = to >>>> follow bip99's recommendations and doesn't want to give 6 full months = as >>>> the pre activation grace period). >>>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" < >>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> >>>>> In many BIPs we have seen, include the latest BIP202, it is the block >>>>> time that determine the max block size. From from pool's point of >>>>> view, it cannot issue a job with a fixed ntime due to the existence o= f >>>>> ntime roll. It is hard to issue a job with the max block size unknown= . >>>>> For developers, it is also easier to implement if max block size is a >>>>> function of block height instead of time. Block height is also much >>>>> more simple and elegant than time. >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>> >>> > --001a1140f52cf09228052731dd07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I believe the attacks are the same for height or median time= of the prev block are equal, only the time of the current block has more e= dge cases.

On Dec 18, 2015 9:15 PM, "Jeff Garzik"= <jgarzik@gmail.com> wrote:<= br type=3D"attribution">
My = preference is height activation + one step per block (i.e. also height).=C2= =A0 Height seems KISS.

AFAICT most of the attacks would = occur around the already-heavily-watched flag day activation event, in a he= ight based environment, a useful attribute.

H= owever I would like to hear from others about possible attacks with the var= ious approaches, before diverging from the default community approach of sw= itch-based-on-time.






On Fri, Dec 18, 2015 at 3:10 PM, Jorge Tim=C3=B3n <jtim= on@jtimon.cc> wrote:

Well, if it's not going to be height, I think median time of t= he previous block is better than the time of the current one, and would als= o solve Chun Wang's concerns.
But as said I prefer to use heights that correspond to diff recalculation (= because that's the window that bip9 will use for the later 95% confirma= tion anyway).

On Dec 18, 2015 9:02 PM, "Jeff Garzik"= <jgarzik@gmail.c= om> wrote:
From a code standpoint, based off height is easy.

My first internal version triggered on block 406,800 (~May 5), and= each block increased by 20 bytes thereafter.

It w= as changed to time, because time was the standard used in years past for ot= her changes; MTP flag day is more stable than block height.

<= /div>
It is preferred to have a single flag trigger (height or time), r= ather than the more complex trigger-on-time, increment-on-height, but any c= ombination of those will work.

Easy to change code= back to height-based...



On Fri, Dec 18, 2015 at 2:= 52 PM, Jorge Tim=C3=B3n <bitcoin-dev@lists.linuxfounda= tion.org> wrote:

I agree that nHeight is the simplest option and is my preference.<= br> Another option is to use the median time from the previous block (thus you = know whether or not the next block should start the miner confirmation or n= ot). In fact, if we're going to use bip9=C2=A0 for 95% miner upgrade co= nfirmation, it would be nice to always pick a difficulty retarget block (ie= block.nHeight % DifficultyAdjustmentInterval =3D=3D 0).
Actually I would always have an initial height in bip9, for softforks too.<= br> I would also use the sign bit as the "hardfork bit" that gets act= ivated for the next diff interval after 95% is reached and a hardfork becom= es active (that way even SPV nodes will notice when a softfork=C2=A0 or har= dfork happens and also be able to tell which one is it).
I should update bip99 with all this. And if the 2 mb bump is uncontroversia= l, maybe I can add that to the timewarp fix and th recovery of the other 2 = bits in block.nVersion (given that bip102 doesn't seem to follow bip99&= #39;s recommendations and doesn't want to give 6 full months as the pre= activation grace period).

On Dec 18, 2015 8:17 PM, "Chun Wang via bit= coin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
In many BIPs we have se= en, include the latest BIP202, it is the block
time that determine the max block size. From from pool's point of
view, it cannot issue a job with a fixed ntime due to the existence of
ntime roll. It is hard to issue a job with the max block size unknown.
For developers, it is also easier to implement if max block size is a
function of block height instead of time. Block height is also much
more simple and elegant than time.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev



--001a1140f52cf09228052731dd07--