summaryrefslogtreecommitdiff
path: root/11/f99526f38b0797313041b0e1d266275b695d07
blob: b3b8524c7ee24a06aa3050b7c2602d3d9801a4ba (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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
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 E3C439BA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  6 Nov 2017 20:55:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f65.google.com (mail-pg0-f65.google.com [74.125.83.65])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4F3CA4F5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  6 Nov 2017 20:55:32 +0000 (UTC)
Received: by mail-pg0-f65.google.com with SMTP id s2so9176798pge.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 06 Nov 2017 12:55:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=Md1aSjcGDTSmw8dMD/tKq8974lHrfnP6LS+WozmbZfk=;
	b=fo47FcZmJRybKk/7cOYLjefRWvBBAobD9cNmXMlzfSsQTt/oQ3Kk3PQIDtbE8eLxQX
	DSH66kQ+w367iXCjz1/IVcSvV5tSS8Js3z+TCEZJdQofqcaSmPA05FbuzL6p/eaASYn9
	Jeroy+4qjyj+mUgOqouAljBXjtisF7/VZqaHbOTxIdUOsJ27nYhpafBtOs1H622A/osw
	Iw0rulNTvJtwlGT0Lgavc412I6p+Y1AffXZHpJIf/Nqx7sDZR4C8LyaNEpBZHGLiETx8
	AkgKJLANgEEg+MGOex2ekGfj0U+j5pniZ1TG742kMyuVqCeyb2vTyGcyQeuPRxwuV0ut
	M/MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=Md1aSjcGDTSmw8dMD/tKq8974lHrfnP6LS+WozmbZfk=;
	b=XjFhxmchJxV++nbntS0Xe7sAxP9LJTC5DtF++0j2bwuGI8CA/AhF5uuMQ+6nJPdw0d
	NuRaKipyZvo5aOr36pfI6kzkLXNOGd7mVyz5uYhhoL5s4IHDpnLATAJA1zVMi/TnbALW
	JIP/+VV8yszTx87+/G+VkENcsRvYbj26f+TQkgDDiL4VB6sKZESPnZqM/2wNZZqzp8cr
	5Us1gKrL/iigwPsCuQskhu6V2y0MVeGM/eFNEZ8RfAkbd79m1tJDxCJi+w8G+yY+OdOL
	0qo5VXOtQXIbzai1rLfZN4T1SgzPpxOr6TEvWaF+2ux+xxzW2k8weSHAAzmr9V6VNuPt
	FgEw==
X-Gm-Message-State: AMCzsaXcPvUXZkQdWCNFz6Y7B/KIuIKrJcflIj5EeBSiPG3pkHkM7HLh
	f5hiITQmB4YnK8JfKScuDq7jMRqoz6E=
X-Google-Smtp-Source: ABhQp+RXuGbtDiF3/+Sri0atsTnaqq3R0b1tWoHdGDzeZ8JkyBXun15CMWW1zOoDR/IpuD0UZCWkgA==
X-Received: by 10.84.173.195 with SMTP id p61mr16088806plb.138.1510001731892; 
	Mon, 06 Nov 2017 12:55:31 -0800 (PST)
Received: from ?IPv6:2600:380:8554:5445:59dc:e765:ef93:cb5e?
	([2600:380:8554:5445:59dc:e765:ef93:cb5e])
	by smtp.gmail.com with ESMTPSA id
	a19sm25648417pfh.30.2017.11.06.12.55.30
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 06 Nov 2017 12:55:30 -0800 (PST)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-1A38FFB1-0409-4D5B-96FD-0BF06AE27860
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <CA+XQW1j2vNNswEQ-HVWF9MpyGBzmq3ij+v=2NGH2VicQ63=v6A@mail.gmail.com>
Date: Mon, 6 Nov 2017 12:55:29 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <61253DDB-A045-4346-A39C-F5C4E07396C7@voskuil.org>
References: <CAB0O3SVjhG19R61B78hFCPwfwWemTXj=tOsvgAgoNbjFYXXAtg@mail.gmail.com>
	<20171106195000.GA7245@fedora-23-dvm>
	<CA+XQW1j2vNNswEQ-HVWF9MpyGBzmq3ij+v=2NGH2VicQ63=v6A@mail.gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM
	autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 06 Nov 2017 23:54:11 +0000
Subject: Re: [bitcoin-dev] Introducing a POW through a soft-fork
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: Mon, 06 Nov 2017 20:55:33 -0000


--Apple-Mail-1A38FFB1-0409-4D5B-96FD-0BF06AE27860
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

If a block that would be discarded under previous rules becomes accepted aft=
er a rule addition, there is no reason to not simply call the new rule a har=
d fork. IOW it's perfectly rational to consider a weaker block as "invalid" r=
elative to the strong chain. As such I don't see any reason to qualify the t=
erm, it's a hard fork. But Peter's observation (the specific behavior) is ul=
timately what matters.

e

> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
>=20
> +1 to all of Peter Todd's comments
>=20
>> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote=
:
>>=20
>> Some quick thoughts...
>>=20
>> > Hi all,
>> >
>> > Feedback is welcome on the draft below.  In particular, I want to see i=
f
>> > there is interest in further development of the idea and also intereste=
d in
>> > any attack vectors or undesirable dynamics.
>> >
>> > (Formatted version available here:
>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>> >
>> > # Soft-fork Introduction of a New POW
>>=20
>> First of all, I don't think you can really call this a soft-fork; I'd cal=
l it a
>> "pseudo-soft-fork"
>>=20
>> My reasoning being that after implementation, a chain with less total wor=
k than
>> the main chain - but more total SHA256^2 work than the main chain - might=
 be
>> followed by non-supporting clients. It's got some properties of a soft-fo=
rk,
>> but it's security model is definitely different.
>>=20
>> > ### Aux POW intermediate block
>> >
>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the ch=
ain
>> > alternates between the two POWs.
>> > Each aux-POW block points to the previous normal block and contains
>> > transactions just like a normal block.
>> > Each normal block points to the previous aux-POW block and must contain=
 all
>> > transactions from the aux-POW block.
>>=20
>> Note how you're basically proposing for the block interval to be decrease=
d,
>> which has security implications due to increased orphan rates.
>>=20
>> > ### Heaviest chain rule change
>> >
>> > This is a semi-hard change, because non-upgraded nodes can get on the w=
rong
>> > chain in case of attack.  However,
>>=20
>> Exactly! Not really a soft-fork.
>>=20
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-1A38FFB1-0409-4D5B-96FD-0BF06AE27860
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>If a block that would be di=
scarded under previous rules becomes accepted after a rule addition, there i=
s no reason to not simply call the new rule a hard fork. IOW it's perfectly r=
ational to consider a weaker block as "invalid" relative to the strong chain=
. As such I don't see any reason to qualify the term, it's a hard fork. But P=
eter's observation (the specific behavior) is ultimately what matters.</div>=
<div><br></div><div>e</div><div><br>On Nov 6, 2017, at 12:30, Paul Sztorc vi=
a bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></div><blockquote=
 type=3D"cite"><div><div dir=3D"auto">+1 to all of Peter Todd's comments</di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Nov 6, 2017 1=
1:50 AM, "Peter Todd via bitcoin-dev" &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<=
br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Nov 01, 2017 at=
 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:<br>
<br>
Some quick thoughts...<br>
<br>
&gt; Hi all,<br>
&gt;<br>
&gt; Feedback is welcome on the draft below.&nbsp; In particular, I want to s=
ee if<br>
&gt; there is interest in further development of the idea and also intereste=
d in<br>
&gt; any attack vectors or undesirable dynamics.<br>
&gt;<br>
&gt; (Formatted version available here:<br>
&gt; <a href=3D"https://github.com/devrandom/btc-papers/blob/master/aux-pow.=
md" rel=3D"noreferrer" target=3D"_blank">https://github.com/devrandom/<wbr>b=
tc-papers/blob/master/aux-<wbr>pow.md</a> )<br>
&gt;<br>
&gt; # Soft-fork Introduction of a New POW<br>
<br>
First of all, I don't think you can really call this a soft-fork; I'd call i=
t a<br>
"pseudo-soft-fork"<br>
<br>
My reasoning being that after implementation, a chain with less total work t=
han<br>
the main chain - but more total SHA256^2 work than the main chain - might be=
<br>
followed by non-supporting clients. It's got some properties of a soft-fork,=
<br>
but it's security model is definitely different.<br>
<br>
&gt; ### Aux POW intermediate block<br>
&gt;<br>
&gt; Auxiliary POW blocks are introduced between normal blocks - i.e. the ch=
ain<br>
&gt; alternates between the two POWs.<br>
&gt; Each aux-POW block points to the previous normal block and contains<br>=

&gt; transactions just like a normal block.<br>
&gt; Each normal block points to the previous aux-POW block and must contain=
 all<br>
&gt; transactions from the aux-POW block.<br>
<br>
Note how you're basically proposing for the block interval to be decreased,<=
br>
which has security implications due to increased orphan rates.<br>
<br>
&gt; ### Heaviest chain rule change<br>
&gt;<br>
&gt; This is a semi-hard change, because non-upgraded nodes can get on the w=
rong<br>
&gt; chain in case of attack.&nbsp; However,<br>
<br>
Exactly! Not really a soft-fork.<br>
<br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">https=
://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"no=
referrer" target=3D"_blank">petertodd.org</a><br>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<=
wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/m=
ailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-1A38FFB1-0409-4D5B-96FD-0BF06AE27860--