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 1C19C7AA for ; Wed, 19 Aug 2015 10:53:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8585C10D for ; Wed, 19 Aug 2015 10:53:31 +0000 (UTC) Received: by oiew67 with SMTP id w67so537761oie.2 for ; Wed, 19 Aug 2015 03:53:31 -0700 (PDT) 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=nPn+qjeIDKasgBDr5HaWP2bl6NMa4j4UsK18FDgNzo4=; b=V7F6suFwebg7PcyI/GIIXImkHTiWgScYIzPVEjy4rGc5OGv4lKsVJf0uGcjZxMPLm6 /DMXnBdNt0yOxx745IgUqBHya2L+gNnzrMdVUbOYguA33mc32ZVwedRlehPkwqjeVda7 Ok2aMv3whbvdjLVtpGQCKVsdgF+i+3OPUyYuxyCPQohEdDziBRfeqw7TnftUX9DcTXN/ BwvXdoSwp8geqouN20/+NzeCzO/her6M5Go71BlOmwfmUZxysg1+dElQn9O/dQ26z7nb UBqGoBAZDyaMdrIIoY0FTjYDZwHNgnIxGCZ818/hYRO013T0seD6yyFS9jh9ojAYq1Z2 mfBQ== X-Gm-Message-State: ALoCoQk3OfDTjFGTZVD/s+sg5pyHdnhimzs1sht78eB/fgQItKEh/J5uFROEeaeSNf6UuzNkACu+ MIME-Version: 1.0 X-Received: by 10.202.58.133 with SMTP id h127mr9669682oia.35.1439981610860; Wed, 19 Aug 2015 03:53:30 -0700 (PDT) Received: by 10.202.71.85 with HTTP; Wed, 19 Aug 2015 03:53:30 -0700 (PDT) In-Reply-To: <4e57154a051f182bf9c4f939a61acad3@xbt.hk> References: <4e57154a051f182bf9c4f939a61acad3@xbt.hk> Date: Wed, 19 Aug 2015 12:53:30 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: jl2012@xbt.hk Content-Type: text/plain; charset=UTF-8 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] Bitcoin is an experiment. Why don't we have an experimental hardfork? 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: Wed, 19 Aug 2015 10:53:32 -0000 On Wed, Aug 19, 2015 at 12:34 PM, wrote: > You misunderstand my intention. The experiment is not about a random > hardfork. It's about a block size increase hardfork. One of your goals is "show the world that reaching consensus for a Bitcoin hardfork is possible", right? BIP99 can achieve that goal without touching the block size (thus probably less controversial). > The data will help us > to design further hardfork on block size. The data can be collected using testchains. See #6382 > To make it less controversial, the size must not be too big. That makes the data less interesting, doesn't it? > To allow a meaningful experiment, the size must not be too small. > Technically we could make it 1.01MB but that defeats all objectives I listed > and there is no point to do it. It wouldn't defeat the "show the world that reaching consensus for a Bitcoin hardfork is possible" objective though. But again, we don't need to touch the block size to achieve that goal. > That's why I suggest 1.5MB. But that wouldn't be uncontroversial (unless it was accompanied with data that somehow quantifies the risks, in which case maybe another bigger size is acceptable). >>> 1. Today, we all agree that some kind of block size hardfork will happen >>> on >>> t1=*1 June 2016* >> >> >> I disagree with this. I think it should be schedule at least a year >> after it is deployed in the newest versions. >> Maybe there's something special about June 2016 that I'm missing. > > > I hope the fork could be done before the halving, which (hopefully) we may > have a new bitcoin rush > > There was only 2 months for the BIP50 hardfork. You may argue that's a "bug > fix" but practically there is no difference: people not fixing the bug in 2 > months was forked off. Four months of grace period (Feb to June 2016) is > already a double of that. Yes, emergency hardforks are a different case as explained in BIP99's draft. In any case, " we all agree that some kind of block size hardfork will happen on June 2016" it's clearly false since I can find many counter-examples besides myself. > Also, if we could have zero grace period for softfork, why must we have a > ultra-long period for hardfork? (Unless you also agree to have an 1-year > grace period for softfork. I don't buy the "softfork is safer than hardfork" > theory. The recent BIP66 fork has clearly shown why it is wrong: > non-upgrading full nodes are not full nodes) I don't think giving 1 year for "everybody in the world" to upgrade is an "ultra-long" period. I'm proposing 5 years for the hardfork proposed in bip99. I do think softforks are safer than hardforks, that doesn't mean softforks don't have serious risks as well. > The problem is many people won't update until they must do so. So 4 months > or 1 year make little difference I disagree with this conclusion as well (it doesn't follow from the first sentence, non sequitur).