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
137
138
139
140
141
142
143
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8C20B88A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 02:16:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com [74.125.83.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 288FD22C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 02:16:23 +0000 (UTC)
Received: by mail-pg0-f48.google.com with SMTP id 3so85805859pgd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 18:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:cc:from:message-id:date:user-agent
:mime-version:in-reply-to;
bh=pl0kXp7azpTIKuRqY+sk7uW6BbssbnlYfAhCXNTFC7w=;
b=qtRGWit8pFG0hQhb9BgEofPuE0Pth/+JfTd49SVN+V60PGQiOdGibq90HhSA1DQ6+q
RfwyJ8XnvDDGvaFGrTrEPNRD3aW/wJAtN7Zuqs4YyniQae89etRBCBb4/e/SxolWKkL3
u+r0k/vyGTJ36YkEn0HLX3xzZ7EH864es3MfClXv5GUHZi+aQRsaj03gcLH02+97OlEy
psgge1PMxPFx3gsi3QHskkn3wBYhRP4RJfWmuRAiAaGZXLClpOVU4O7QCjSd2SmpUVyV
kNl0yuww+afOjzScOj+ToQMalT6OpYQ4lW8f6yN1YVq2ULtO7eP0BjQbprlujjAKYiPw
rhHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:subject:to:references:cc:from:message-id:date
:user-agent:mime-version:in-reply-to;
bh=pl0kXp7azpTIKuRqY+sk7uW6BbssbnlYfAhCXNTFC7w=;
b=Mojrqk/MJzOk3ufVjOB9BegxzF7XnQPNt4bauJ5UCSCWZ84yOG0lSSj9wUkqb3Vltt
7lf+VO2SJBCxvMaS7WP3in8yy22vt60rCYiV9kFMaVrdv2yAZg1FcLeBuOTiIJBxP154
pW3ALnyxTx5nZjuYv8zTaDNP4ZG1PcCCipVuta8ICpUB20Nx3++AplyI/WXR5lDH6aHo
pgJPf7qb5PD+86+8K8sBC0VnCp4WlCH7Qn3xQ1FoF8zlDXJtM9qNtKaxRI7c8ynkY7qa
PBOm9AFQBejONzJLuX4+VbfBAFctWy43Y4CVJpGT9Z4QoLuXGUcACOw42hQ/P21I7nWv
hibg==
X-Gm-Message-State: ABUngvd/ft6+plJ/21kudG/lRXPZ+6RYhZGIR9R33UFcvKPDhE4xLCBCMAFyQyq0jdmpOQ==
X-Received: by 10.98.73.203 with SMTP id r72mr1161091pfi.75.1479348982746;
Wed, 16 Nov 2016 18:16:22 -0800 (PST)
Received: from ?IPv6:2601:600:9000:d69e:8084:4206:2529:776d?
([2601:600:9000:d69e:8084:4206:2529:776d])
by smtp.gmail.com with ESMTPSA id i76sm798230pfk.89.2016.11.16.18.16.21
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 16 Nov 2016 18:16:22 -0800 (PST)
To: Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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>
<CAPg+sBiGwz23mm5fCKUrg7GpWwuJ=3Nf2DcN89KxG=g_Wz4vBw@mail.gmail.com>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N0110
Message-ID: <0d66bf24-2ded-cd98-ec55-945e01b436d0@voskuil.org>
Date: Wed, 16 Nov 2016 18:16:23 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAPg+sBiGwz23mm5fCKUrg7GpWwuJ=3Nf2DcN89KxG=g_Wz4vBw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="6wQsoxBDP47ItSVAlIJG3GKs5VaJiPjL9"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 17 Nov 2016 02:20:31 +0000
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 02:16:23 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6wQsoxBDP47ItSVAlIJG3GKs5VaJiPjL9
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 11/16/2016 05:50 PM, Pieter Wuille wrote:
> If you were trying to point out that buried softforks are similar to
> checkpoints in this regard, I agree.
Yes, that was my point.
> So are checkpoints good now?
> I believe we should get rid of checkpoints because they seem to be
misunderstood as a security feature rather than as an optimization.
Or maybe because they place control of the "true chain" in the hands of
those selecting the checkpoints? It's not a great leap for the parties
distributing the checkpoints to become the central authority.
I recommend users of our node validate the full chain without
checkpoints and from that chain select their own checkpoints and place
them into config. From that point forward they can apply the
optimization. Checkpoints should never be hardcoded into the source.
> I don't think buried softforks have that problem.
I find "buried softfork" a curious name as you are using it. You seem to
be implying that this type of change is itself a softfork as opposed to
a hardfork that changes the activation of a softfork. It was my
understanding that the term referred to the 3 softforks that were being
"buried", or the proposal, but not the burial itself.
Nevertheless, this proposal shouldn't have "that problem" because it is
clearly neither a security feature nor an optimization. That is the
first issue that needs to be addressed.
e
--6wQsoxBDP47ItSVAlIJG3GKs5VaJiPjL9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJYLRL3AAoJEDzYwH8LXOFOgnQH/jP2Mcqi+nSKsq8tCUaQprRc
CyvWQbUWvIss38bsr0DxUhlijuAGwMZ9vz9AECaWMuQMyBg137FgZqMfj/hUmirB
YRNBCtSJi0s5NHGrtEsyKf/IgrT6bTxpQw9p9joKREevcwoDaHnUqXyZWj8FqE0g
Q4scwGiQF+WQUBpZI+Xu8A0AHYcpc4+tBEyxL71FT2naQhSU5dnO7SFBXy2dxQeB
cRmov6ImaqMAUGaACyXtA2uhw6KDOLcUMClT9VEW9kzwrJwj0N1uBtpkqfDIXSgZ
Ay2XQ4Iv57qi2Ggf3GyhPkn0Zxe5a638OWlaa6MxiSU76Ub8JWkPJ+aPX6z6mYU=
=dyWX
-----END PGP SIGNATURE-----
--6wQsoxBDP47ItSVAlIJG3GKs5VaJiPjL9--
|
