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 3218EB7A for ; Thu, 17 Nov 2016 03:15:43 +0000 (UTC) X-Greylist: delayed 00:09:32 by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C628B269 for ; Thu, 17 Nov 2016 03:15:42 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 6D06038AB6EE; Thu, 17 Nov 2016 03:06:03 +0000 (UTC) X-Hashcash: 1:25:161117:pete@petertodd.org::SQBjatSPHN0bqb0Q:KAkl X-Hashcash: 1:25:161117:bitcoin-dev@lists.linuxfoundation.org::=w/MdmRH71GL7bse:wYEc From: Luke Dashjr To: Peter Todd , Bitcoin Protocol Discussion Date: Thu, 17 Nov 2016 03:06:01 +0000 User-Agent: KMail/1.13.7 (Linux/4.4.31-gentoo; KDE/4.14.24; x86_64; ; ) References: <20161116210100.GC5639@savin.petertodd.org> In-Reply-To: <20161116210100.GC5639@savin.petertodd.org> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201611170306.02406.luke@dashjr.org> X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD 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 Proposal] Buried Deployments X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 03:15:43 -0000 On Wednesday, November 16, 2016 9:01:00 PM Peter Todd via bitcoin-dev wrote: > So, conceptually, another way to deal with this is to hardcode a blockhash > where we allow blocks in a chain ending with that blockhash to _not_ follow > BIP65, up until that blockhash, and any blockchain without that blockhash > must respect BIP65 for all blocks in the chain. > > This is a softfork: we've only added rules that made otherwise valid chains > invalid, and at the same time we are still accepting large reorgs (albeit > under stricter rules than before). > > I'd suggest we call this a exemption hash - we've exempted a particular > blockchains from a soft-forked rule that we would otherwise enforce. While this is technically a softfork, I think it may behave somewhat like a hardfork if we're not careful. Particularly, is the chain up to the block immediately before the checkpoint itself valid on its own, or does it simply become retroactively valid when it hits that checkpoint? P.S. Your PGP signature is invalid?