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 8AC0DDFC for ; Sun, 7 Feb 2016 19:27:35 +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 7A247E1 for ; Sun, 7 Feb 2016 19:27:31 +0000 (UTC) Received: from 119246245241.ctinets.com ([119.246.245.241]:53400 helo=2012R2) by server47.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86) (envelope-from ) id 1aSUzZ-001ZBS-LZ; Sun, 07 Feb 2016 14:27:30 -0500 From: To: "'Gavin Andresen'" , "'Gregory Maxwell'" References: In-Reply-To: Date: Mon, 8 Feb 2016 03:27:48 +0800 Message-ID: <232901d161dd$a35f8d30$ea1ea790$@xbt.hk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHbMrTCecyH04NftjxoC3dSKJ6yWAIfgCv5AT+pZiae8lanIA== Content-Language: en-hk 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: Sun, 07 Feb 2016 19:27:35 -0000 From: Gavin Andresen [mailto:gavinandresen@gmail.com]=20 Sent: Friday, 5 February, 2016 06:16 To: Gregory Maxwell Cc: jl2012 ; Bitcoin Dev = Subject: Re: [bitcoin-dev] Hardfork bit BIP >It is always possible I'm being dense, but I still don't understand how = this proposal makes a chain-forking situation better for anybody. >If there are SPV clients that don't pay attention to versions in block = headers, then setting the block version negative doesn't directly help = them, they will ignore it in any case. It is unfortunate SPV clients are not following that. However, they = SHOULD follow that. It becomes a self fulfilling prophecy if we decide = not to do that if SPV are not following that. >If the worry is full nodes that are not upgraded, then a block with a = negative version number will, indeed, fork them off the the chain, in = exactly the same way a block with new hard-forking consensus rules = would. And with the same consequences (if there is any hashpower not = paying attention, then a worthless minority chain might continue on with = the old rules). It will distinguish between a planned hardfork and an accidental = hardfork, and full nodes may react differently. Particularly, a planned = unknown hardfork is a strong indication that the original chain has = become economic minority and the non-upgraded full node should stop = accepting incoming tx immediately. >If the worry is not-upgraded SPV clients connecting to the old, = not-upgraded full nodes, I don't see how this proposed BIP helps. Same for not-upgraded full nodes following not-upgraded full nodes. = Anyway, the header with enough PoW should still be propagated. >I think a much better idea than this proposed BIP would be a BIP that = recommends that SPV clients to pay attention to block version numbers in = the headers that they download, and warn if there is a soft OR hard fork = that they don't know about. Normal version number only suggests softforks, which is usually not a = concern for SPV clients. An unknown hardfork is a completely different = story as the values of the forks are completely unknown. >It is also a very good idea for SPV clients to pay attention to = timestamps in the block headers that the receive, and to warn if blocks = were generated either much slower or faster than statistically likely. = Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in = general. Yes, they should. --=20 -- Gavin Andresen