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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6E25BAB6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 01:50:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com
[209.85.213.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F27571AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Nov 2016 01:50:54 +0000 (UTC)
Received: by mail-vk0-f47.google.com with SMTP id x186so130414406vkd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 17:50:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=ZnMtF3wZmoSOMWNHkDaALlBsxOkcZyMiDDm++NDI3Dg=;
b=orqx0Cji6LD/ZWpgc6Xs0zubkTr/EektsNofENGFGXLLeBUl3adiJ6tkLesuu8femi
uNmDPPvJ5t8rjArZMnQfz6s5/IX8OyKmIGlOLBQ2K24ylCrLfBWfpM8gvekVW2hLZYZU
yNYV54ccnwI4Hl2Nd0E9GhQqxFwWqL9N3VcUbXeO0okGOnIZJPZhOYFLSFNbUqgGfBfl
GxkBk2IJWDQN1mmF9acnNjC0v4x034Rrqv5EzCnS97xOMAtq/yaPhFvkE3pnSGv/KVeD
dEcdglR1yny/5ZrfUPw4Yz6/7AMK6vSLV7zwY97TCGR2N7PPfIG1tYJFZ1hviqxNpgXI
7GUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=ZnMtF3wZmoSOMWNHkDaALlBsxOkcZyMiDDm++NDI3Dg=;
b=kFsMUzz9C1XvavdMjYhCZS1KAvREynSlfjzbv3jiIMjwIMdu0NupXdTNFnzuDGMvM2
GJwgN9SdH02EkBLe3y8nNWoZbehOz2hefxdtfSWWHlcMyUhk9dQjDm/Z18vtalREv0GD
HiSgMdFmCicS6cNn05O1FXNu6ITeRz+r1eAoK/4a1QYpIaph+nazF9u18xa5wFD0/PC4
XkGR8zjdS1ieWm3Aqx1ssjUs490yvfwrZiHiAc2sfvMTAJTL4rjt7Pc/ukY+4JzshN5G
qrlzeWkyUtlzhjMrDIGfLfyQsZcJLAdJLVyolLcsgwTRB6mSxHIQC8CbKIWcij160ceT
xStQ==
X-Gm-Message-State: AKaTC02L+17nKBNFeFHWWnKzhyX9qp8W35sWm2Hl4MoqErkEjUNb6P7je/90gu4Qgk64cxxle8z7ywBlB/sDgw==
X-Received: by 10.31.108.144 with SMTP id j16mr212222vki.93.1479347454097;
Wed, 16 Nov 2016 17:50:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.115.201 with HTTP; Wed, 16 Nov 2016 17:50:53 -0800 (PST)
In-Reply-To: <A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.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>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 16 Nov 2016 17:50:53 -0800
Message-ID: <CAPg+sBiGwz23mm5fCKUrg7GpWwuJ=3Nf2DcN89KxG=g_Wz4vBw@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11478b7080403d0541756b64
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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
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 01:50:55 -0000
--001a11478b7080403d0541756b64
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 16, 2016 at 5:58 AM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This sort of statement represents one consequence of the aforementioned
> bad precedent.
>
> Are checkpoints good now?
>
So far in this discussion, and in a thread that has forked off, I think 3
cases of implementation aspects have been mentioned that under certain
circumstances result in the validity of chains changing:
* Buried softforks (by simplifying the activation rules for certain rules)
* Not verifying BIP30 after BIP34 is active (since only under a SHA256^2
collision a duplicate txid can occur)
* The existence (and/or removal) of checkpoints (in one form or another).
None of these will influence the accepted main chain, however. If they ever
do, Bitcoin has far worse things to worry about (years-deep reorgs, or
SHA256 collisions).
If you were trying to point out that buried softforks are similar to
checkpoints in this regard, I agree. 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. I don't think buried
softforks have that problem.
--
Pieter
--001a11478b7080403d0541756b64
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Nov 16, 2016 at 5:58 AM, Eric Voskuil via bitcoin-=
dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></sp=
an> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"auto"><div></div><div>This sort of stat=
ement represents one consequence of the aforementioned bad precedent.</div>=
<div><br></div><div>Are checkpoints good now?<br></div></div></blockquote><=
div><br></div><div>So far in this discussion, and in a thread that has fork=
ed off, I think 3 cases of implementation aspects have been mentioned that =
under certain circumstances result in the validity of chains changing:<br><=
/div><div>* Buried softforks (by simplifying the activation rules for certa=
in rules)<br></div><div>* Not verifying BIP30 after BIP34 is active (since =
only under a SHA256^2 collision a duplicate txid can occur)<br></div><div>*=
The existence (and/or removal) of checkpoints (in one form or another).<br=
><br></div><div>None of these will influence the accepted main chain, howev=
er. If they ever do, Bitcoin has far worse things to worry about (years-dee=
p reorgs, or SHA256 collisions).<br><br></div><div>If you were trying to po=
int out that buried softforks are similar to checkpoints in this regard, I =
agree. So are checkpoints good now? I believe we should get rid of checkpoi=
nts because they seem to be misunderstood as a security feature rather than=
as an optimization. I don't think buried softforks have that problem.<=
br><br>-- <br></div><div>Pieter<br><br></div></div></div></div>
--001a11478b7080403d0541756b64--
|
