1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3218EB7A
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <luke@dashjr.org>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
<CAPWm=eUQjpELFB2A9vJ8j6Y5Zvts9YqkZYNCO0aDnNSb+VwFvg@mail.gmail.com>
<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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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?
|
