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 A23E75AE for ; Wed, 22 Jul 2015 17:37:13 +0000 (UTC) X-Greylist: delayed 00:36:30 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 0DED01BF for ; Wed, 22 Jul 2015 17:37:13 +0000 (UTC) Received: from localhost ([::1]:46555 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1ZHxNq-000AIs-0o for bitcoin-dev@lists.linuxfoundation.org; Wed, 22 Jul 2015 13:00:42 -0400 Received: from 119.246.245.241 ([119.246.245.241]) by server47.web-hosting.com (Horde Framework) with HTTP; Wed, 22 Jul 2015 17:00:41 +0000 Date: Wed, 22 Jul 2015 17:00:41 +0000 Message-ID: <20150722170041.Horde.N2psXR0k1XYN4_s0phBwGg1@server47.web-hosting.com> From: jl2012@xbt.hk To: bitcoin-dev@lists.linuxfoundation.org References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> In-Reply-To: <20150721130412.GA4551@savin.petertodd.org> User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline 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 Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB 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, 22 Jul 2015 17:37:13 -0000 Quoting Peter Todd via bitcoin-dev : > > Having said that, in general triggering events without verifying a > supermajority of miner support can be very dangerous. Without miner > support the chain is insecure, and can be attacked. For instance a > blocksize limit increase that a majority of miners choose not to > implement raises huge risks of reorg for any miners who attempt to > create large blocks, and huge risks of payment reversal for any > merchants accepting transactions in such blocks. Note how with BIP102, > extending the original Bitcoin chain is inherently an attack on the > Garzik chain. > > For that reason I think BIP102 is extremely poorly designed. I can only > conclude that Jeff Garzik is either deliberately trolling us and/or > manipulating discussion with a badly designed proposal that he doesn't > actually expect to be adopted verbatim, or is incompetent. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1 To avoid any risk of reorg, the hardfork may require that the first block with GetMedianTimePast() after a pre-determined time (the "flag block") MUST be version 0. The exception is applied ONLY to the flag block. Alternatively, the hardfork may require that the flag block MUST be larger than 1MB. Comparing with exploiting the block version, this does not require additional exceptions in consensus rules. However, miner may need to artificially inflate the size of the flag block and that could be trouble in coding. I don't have any preference. Old nodes will not accept the new chain because it violates BIP66 / block size limit. New nodes will not accept the old chain because its flag block is not version 0 / not larger than 1MB. This is actually checkpointing in a decentralized way. In that case, we can say goodbye to the old chain forever, as long as all major merchants and exchanges agree to upgrade. Miner support is less relevant. It is a no-brainer for miners to support the new chain, unless they don't want to sell or spend their bitcoin, or just give up mining after heavily investing in ASIC. jl2012