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 3DBB583D for ; Wed, 19 Aug 2015 10:34:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BACA910D for ; Wed, 19 Aug 2015 10:34:39 +0000 (UTC) Received: from localhost ([::1]:54903 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZS0ha-000b9D-DM; Wed, 19 Aug 2015 06:34:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 19 Aug 2015 06:34:38 -0400 From: jl2012@xbt.hk To: =?UTF-8?Q?Jorge_Tim=C3=B3n?= In-Reply-To: References: Message-ID: <4e57154a051f182bf9c4f939a61acad3@xbt.hk> X-Sender: jl2012@xbt.hk User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched 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] =?utf-8?q?Bitcoin_is_an_experiment=2E_Why_don=27t_w?= =?utf-8?q?e_have_an_experimental_hardfork=3F?= 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:34:40 -0000 Jorge Timón 於 2015-08-19 05:24 寫到: > On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev > wrote: >> As I understand, there is already a consensus among core dev that >> block size >> should/could be raised. The remaining questions are how, when, how >> much, and >> how fast. These are the questions for the coming Bitcoin Scalability >> Workshops but immediate consensus in these issues are not guaranteed. >> >> Could we just stop the debate for a moment, and agree to a scheduled >> experimental hardfork? >> >> Objectives (by order of importance): >> >> 1. The most important objective is to show the world that reaching >> consensus >> for a Bitcoin hardfork is possible. If we could have a successful one, >> we >> would have more in the future > > Apart from classifying all potential consensus rule changes and > recommend a deployment path for each case, deploying an > uncontroversial hardfork is one of the main goals of bip99: > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html > >> 2. With a slight increase in block size, to collect data for future >> hardforks > > The uncontroversial hardfork doesn't need to change the maximum block > size: there's plenty of hardfork proposals out there, some of them > very well tested (like the proposed hardfork in bip99). You misunderstand my intention. The experiment is not about a random hardfork. It's about a block size increase hardfork. The data will help us to design further hardfork on block size. To make it less controversial, the size must not be too big. 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. That's why I suggest 1.5MB. >> 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. 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) The problem is many people won't update until they must do so. So 4 months or 1 year make little difference