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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Return-Path: <ctpacia@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7C5F4EAF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Dec 2015 01:36:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com
[209.85.192.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D4FFCEE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Dec 2015 01:36:23 +0000 (UTC)
Received: by mail-qg0-f46.google.com with SMTP id v36so46704502qgd.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 17:36:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-type;
bh=raiBUHV8sMLC/BtrYr1XHPUnbx/XPQXwC/kkUY4mwBc=;
b=fJoznNgMwJH61/jPZUCuARx1KauMh+vA4Ard/8uHQ3bPaPb3V740MAIOcTiSd5XRbi
7bDizuQNvpzktv5bpK2b1aBWB4MXyMfPJXyKiCWhrYfgkWO83okCLx1Gy9ddb/G25Idy
k+kA4GuHgShiTzqFz7mOV99lCgQLxdu+1LPULW7jIY2Gy9nsogMEpqETEpB5bezklcQs
upm8fB4q4xjCZh1tEhY7P4HEWpzmryrBe+iNuYDAokQQdb4SSZ5Dyer+YZEXyvmYDPYT
Ou0VkYvxamY+cdAo8rWaWspkebB7lEbCqjEcEMTsYeSMBfMErK7tr0I6tfKjc3evxCTG
34vg==
X-Received: by 10.140.144.205 with SMTP id 196mr10008472qhq.38.1450488983051;
Fri, 18 Dec 2015 17:36:23 -0800 (PST)
Received: from [192.168.1.15] (pool-72-82-165-31.cmdnnj.east.verizon.net.
[72.82.165.31])
by smtp.gmail.com with ESMTPSA id f7sm7929230qhf.7.2015.12.18.17.36.22
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 18 Dec 2015 17:36:22 -0800 (PST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAPg+sBjJcqeqGLHnPyWt23z3YoCRGozQupuMxy51J_-hdkKBSA@mail.gmail.com>
<E76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.im>
From: Chris <ctpacia@gmail.com>
Message-ID: <5674B495.10903@gmail.com>
Date: Fri, 18 Dec 2015 20:36:21 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <E76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.im>
Content-Type: multipart/alternative;
boundary="------------080301090108010004070405"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
X-Mailman-Approved-At: Sat, 19 Dec 2015 08:38:30 +0000
Subject: Re: [bitcoin-dev] On the security of softforks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sat, 19 Dec 2015 01:36:24 -0000
This is a multi-part message in MIME format.
--------------080301090108010004070405
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 2) The risk of an old full node wallet accepting a transaction whose
> coins passed through a script that depends on the softforked rules.
>
There's that, but there's also a case where an attacker creates a
majority chain that follows the old rules but not the new ones.
Non-upgraded nodes would accept a transaction on what they believe to be
the consensus chain only to find that when they try to spend those coins
no one accepts them because they were part of an invalid chain.
This has the effect of dropping non upgraded nodes to a form of spv
security without their consent.
This is in contrast to a hard fork where a full node operator could
explicitly set their node to accept higher version blocks that it can't
validate. They get the soft fork functionality back but they have at
least consented to it rather than have it forced on them. Doing forks
that way would also have the benefit of notifying the user they are
accepting unvalidated coins, whereas they wont know that in a soft fork.
--------------080301090108010004070405
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <<a
moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org"><a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></a>>
wrote:
<blockquote cite="mid:E76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.im"
type="cite">
<div>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<span style="color: rgb(34, 34, 34); font-family: 'Helvetica
Neue', Arial, sans-serif; font-size: 15px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: 20px; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;
display: inline !important; float: none;">2) The risk of an
old full node wallet accepting a transaction whose</span><br
style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue',
Arial, sans-serif; font-size: 15px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: 20px; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<span style="color: rgb(34, 34, 34); font-family: 'Helvetica
Neue', Arial, sans-serif; font-size: 15px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: 20px; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;
display: inline !important; float: none;">coins passed through
a script that depends on the softforked rules.</span></div>
<br>
</blockquote>
There's that, but there's also a case where an attacker creates a
majority chain that follows the old rules but not the new ones.
Non-upgraded nodes would accept a transaction on what they believe
to be the consensus chain only to find that when they try to spend
those coins no one accepts them because they were part of an invalid
chain. <br>
<br>
This has the effect of dropping non upgraded nodes to a form of spv
security without their consent. <br>
<br>
This is in contrast to a hard fork where a full node operator could
explicitly set their node to accept higher version blocks that it
can't validate. They get the soft fork functionality back but they
have at least consented to it rather than have it forced on them.
Doing forks that way would also have the benefit of notifying the
user they are accepting unvalidated coins, whereas they wont know
that in a soft fork. <br>
</body>
</html>
--------------080301090108010004070405--
|
