summaryrefslogtreecommitdiff
path: root/52/e8f304f4a139ac23232d2e548a18c5f13faf6e
blob: 0b9b02eb896ae7a5e367ca6f275cbf55aadfee85 (plain)
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
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 62641955
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 21:01:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149081.authsmtp.net (outmail149081.authsmtp.net
	[62.13.149.81])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0525AA7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 21:01:05 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id uAGL13bL011977;
	Wed, 16 Nov 2016 21:01:03 GMT
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
	[52.5.185.120]) (authenticated bits=0)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id uAGL114K034399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 16 Nov 2016 21:01:02 GMT
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by petertodd.org (Postfix) with ESMTPSA id BAD7F400F7;
	Wed, 16 Nov 2016 20:56:20 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
	id 316B52047A; Wed, 16 Nov 2016 16:01:00 -0500 (EST)
Date: Wed, 16 Nov 2016 16:01:00 -0500
From: Peter Todd <pete@petertodd.org>
To: Alex Morcos <morcos@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20161116210100.GC5639@savin.petertodd.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
	<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
	<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
	<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
	<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
	<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
	<CAE-z3OXdiyS_5HEFu1VLG1DH_K1QUBTSy49nXh1M4tcuoi6D_w@mail.gmail.com>
	<CAPWm=eUQjpELFB2A9vJ8j6Y5Zvts9YqkZYNCO0aDnNSb+VwFvg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5"
Content-Disposition: inline
In-Reply-To: <CAPWm=eUQjpELFB2A9vJ8j6Y5Zvts9YqkZYNCO0aDnNSb+VwFvg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: c89c23dd-ac3f-11e6-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdwQUFloCAgsB AmAbWVVeUFx7WWE7 bghPaBtcak9QXgdq
	T0pMXVMcUXQffR0A AmUeUR1xfgwIeX92 bUMsDXhSD0Z5IRJg
	Ex1XQ3AHZDJmdWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk
	FAgyOXU9MCtqYBd/ YzlFFUgVWUEQFzoJ DzofBzQiEQUpSj03 KA0jJ1gABy4A
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
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 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: Wed, 16 Nov 2016 21:01:10 -0000


--O3RTKUHj+75w1tg5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote:
> I think we are misunderstanding the effect of this change.
> It's still "OK" for a 50k re-org to happen.
> We're just saying that if it does, we will now have potentially introduced
> a hard fork between new client and old clients if the reorg contains
> earlier signaling for the most recent ISM soft fork and then blocks which
> do not conform to that soft fork before the block height encoded activati=
on.
>=20
> I think the argument is this doesn't substantially add to the confusion or
> usability of the system as its likely that old software won't even handle
> 50k block reorgs cleanly anyway and there will clearly have to be human
> coordination at the time of the event.  In the unlikely event that the new
> chain does cause such a hard fork, that coordination can result in everyo=
ne
> upgrading to software that supports the new rules anyway.
>=20
> So no, I don't think we should add a checkpoint.  I think we should all
> just agree to a hard fork that only has a very very slim chance of any
> practical effect.

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 m=
ust
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 u=
nder
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.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--O3RTKUHj+75w1tg5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJYLMkJAAoJECSBQD2l8JH7Q3oH/Roi+0I8kT8S2GITOgS+XQRv
Ro8ghB3KrHE76Q4SLM+GT4CZvYevBdcsqM8epeGsOaeLYxpPPhhd0XJJ9+O4/qJo
6+OIbgkWV98IK9ss+uqxYwYam6Z3EJL6WE+Y/sgyfnQkNkHrOObg1e2JeAl4Q31/
/Ty128nR8doRIVU9fh/pnqaP//CrDtogf6mnfVAcRUZZRSXhAGDW8cmXV/xGtXFN
KVszxqkV+8bNxP9zt+oS7Y7hp6m7KpjY8DPQSNCfGop0lVvik9JzmkJGlAKM84+w
zi/oGTO/JiwoaoIbKdVobqMmedKKrP5pIcI6fE03lL0qTKSfdzxk2U32PbNF+aQ=
=ocKT
-----END PGP SIGNATURE-----

--O3RTKUHj+75w1tg5--