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 A57F0EFC for ; Thu, 4 Feb 2016 17:56:44 +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 42551144 for ; Thu, 4 Feb 2016 17:56:44 +0000 (UTC) Received: from [::1] (port=47772 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.86) (envelope-from ) id 1aRO95-004OOE-31; Thu, 04 Feb 2016 12:56:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 04 Feb 2016 12:56:42 -0500 From: jl2012 To: Gavin Andresen In-Reply-To: References: Message-ID: X-Sender: jl2012@xbt.hk User-Agent: Roundcube Webmail/1.0.6 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-Authenticated-Sender: server47.web-hosting.com: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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] Hardfork bit BIP 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: Thu, 04 Feb 2016 17:56:44 -0000 Gavin Andresen 於 2016-02-04 12:36 寫到: > This BIP is unnecessary, in my opinion. > > I'm going to take issue with items (2) and (3) that are the motivation > for this BIP: > > " 2. Full nodes and SPV nodes following original consensus rules may > not be aware of the deployment of a hardfork. They may stick to an > economic-minority fork and unknowingly accept devalued legacy tokens." > > If a hardfork is deployed by increasing the version number in blocks > (as is done for soft forks), then there is no risk-- Full and SPV > nodes should notice that they are seeing up-version blocks and warn > the user that they are using obsolete software. > > It doesn't matter if the software is obsolete because of hard or soft > fork, the difference in risks between those two cases will not be > understood by the typical full node or SPV node user. Thanks for your comments. In the case of a softfork, as long as an user waits for a few confirmations, the risk of money loss is very low. In the worst case they run a full node with SPV security. In the case of a hardfork, the consequence of failing to upgrade to the economic majority fork *is* fatal, even if an user waits for 1000 confirmations. Not to mention the risk of having 2 economically active forks. That's why wallets should STOP accepting and sending tx after a hardfork bit is detected and wait for users' instructions. > " 3. In the case which the original consensus rules are also valid > under the new consensus rules, users following the new chain may > unexpectedly reorg back to the original chain if it grows faster than > the new one. People may find their confirmed transactions becoming > unconfirmed and lose money." > > If a hard or soft fork uses a 'grace period' (as described in BIP 9 or > BIP 101) then there is essentially no risk that a reorg will happen > past the triggering block. A block-chain re-org of two thousand or > more blocks on the main Bitcoin chain is unthinkable-- the economic > chaos would be massive, and the reaction to such a drastic (and > extremely unlikely) event would certainly be a hastily imposed > checkpoint to get everybody back onto the chain that everybody was > using for economic transactions. No, the "triggering block" you mentioned is NOT where the hardfork starts. Using BIP101 as an example, the hardfork starts when the first >1MB is mined. For people who failed to upgrade, the "grace period" is always zero, which is the moment they realize a hardfork. > Since I don't agree with the motivations for this BIP, I don't think > the proposed mechanism (a negative-version-number-block) is necessary. > And since it would simply add more consensus-level code, I believe the > keep-it-simple principle applies. > > -- > > -- > Gavin Andresen