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
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
|
Return-Path: <miron@hyper.to>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id ECA2FC0C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2017 04:39:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f194.google.com (mail-qk0-f194.google.com
[209.85.220.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1E2E3DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2017 04:39:02 +0000 (UTC)
Received: by mail-qk0-f194.google.com with SMTP id n5so13755768qke.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 06 Nov 2017 20:39:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=niftybox-net.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=vT1Fp60C5atIniVOgawc0Cl03jjTPtIeYYcM+EEzcv4=;
b=gayQQLG2XTicfOJylsSXMLDXyjMUNEF8V/RbA6uNTzxBNQ5wVnR1pvjXkLPi++RRzr
Aagj90l1wdRLq/B30BCdKuDwqF9gZipWfiDCb7ZggO8rF5H0/Cwt7VwFSHUY8AlaNkBL
dCSeZndp3E8JPuORFxxAY040ZEGLfsh4fUeOmfvvZDjUbHF/PDpG+EyGQjONHVoYDd15
h32+wZDTytiU2kV4ixMqZjUgadzO2nxlXtA5gN0dBlCiMlxT9j1+z/7Ukpv78kaJQCtE
iGEX7s4d7o7eoOL/LWfPuHkUsBAuglIge4yqf4vBCHae2vFwxxeimbRm7HKIqO49lhc3
riVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=vT1Fp60C5atIniVOgawc0Cl03jjTPtIeYYcM+EEzcv4=;
b=nwtkaihT9MsevXiysm/kyyQ0dQ4944mKHhwFy97eWz1GlOCrgaUhg/BJZdJhoP3dUe
/QQDwzt7z6tkx1pKwANy9Y1DuXirhSdMHUYLw6q0Kv7oiXawovxxOeJQ6v78lqMSrbh4
NWRHVdxJPaUWBY2UcqrridjoKdsUeSpGPS7KshPEghPwD9e0KXP0nsX2U+qmLh2W2fbm
qBfeqV96pcX1+kynHS3UijYec/nCWoH0dwLd5he/iKg+4a9bG1hO3cipyLJ0I+n97sqD
2wkuoqJ2UVdyDHKhDiLOy6/SZDsUAZogOkhWQBO+zDlvz1CKQuXyLF1fd1w4ixmzwNdH
AzTA==
X-Gm-Message-State: AJaThX5rWni7oEtyMR5wo9UaGKYPoM1Yggjr2j70Zvy5uUkXH9jWuuta
WVCttuhcV/p9nN3BIsEvsv1gLD+D99uaMFnPxs/LRg==
X-Google-Smtp-Source: ABhQp+TijRnTmIc43ge8cQ5CgONkhph5SZcszwtOhoyt1RfFGLQYXGrWfIylipKqMvKrwrh7yDq9xhWhczVumC58yIA=
X-Received: by 10.55.203.217 with SMTP id u86mr8625960qkl.98.1510029541857;
Mon, 06 Nov 2017 20:39:01 -0800 (PST)
MIME-Version: 1.0
References: <CAB0O3SVjhG19R61B78hFCPwfwWemTXj=tOsvgAgoNbjFYXXAtg@mail.gmail.com>
<20171106195000.GA7245@fedora-23-dvm>
<CA+XQW1j2vNNswEQ-HVWF9MpyGBzmq3ij+v=2NGH2VicQ63=v6A@mail.gmail.com>
<61253DDB-A045-4346-A39C-F5C4E07396C7@voskuil.org>
In-Reply-To: <61253DDB-A045-4346-A39C-F5C4E07396C7@voskuil.org>
From: Devrandom <c1.bitcoin@niftybox.net>
Date: Tue, 07 Nov 2017 04:38:51 +0000
Message-ID: <CAB0O3SX-m1Uw8Ga-ddzyU6oYdM2QRXn2OetgPmPBT+-5wGmjKQ@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1139e25871733c055d5d2677"
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
HTML_MESSAGE,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: Tue, 07 Nov 2017 04:55:08 +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: Tue, 07 Nov 2017 04:39:04 -0000
--001a1139e25871733c055d5d2677
Content-Type: text/plain; charset="UTF-8"
A hard-fork is a situation where non-upgraded nodes reject a block mined
and relayed by upgraded nodes. This creates a fork that cannot heal
regardless of what follows.
This proposal is not a hard-fork, because the non-upgraded node *will heal*
if the attack has less than 1/2 of the original-POW power in the long term.
The cost of such an attack is the cost of a normal "51%" attack, multiplied
by the fractional weight of the original POW (e.g. 0.75 or 0.5).
So rather than saying this is a hard-fork, I would say that this is a
soft-fork with reduced security for non-upgraded nodes. I would also say
that the reduction in security is proportional to the reduction in weight
of the original POW at the time of attack.
As mentioned before, the original-POW weight starts at 1.0 and is reduced
over a long period of time. I would set up the transition curve so that
all nodes upgrade by the time the weight is, say, 0.75. In reality, nodes
protecting high economic value would upgrade early.
On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If a block that would be discarded under previous rules becomes accepted
> after a rule addition, there is no reason to not simply call the new rule a
> hard fork. IOW it's perfectly rational 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 Peter's observation (the specific
> behavior) is ultimately what matters.
>
> e
>
> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> +1 to all of Peter Todd's comments
>
> 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:
>>
>> Some quick thoughts...
>>
>> > Hi all,
>> >
>> > Feedback is welcome on the draft below. In particular, I want to see if
>> > there is interest in further development of the idea and also
>> interested 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
>>
>> First of all, I don't think you can really call this a soft-fork; I'd
>> call it a
>> "pseudo-soft-fork"
>>
>> My reasoning being that after implementation, a chain with less total
>> work 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-fork,
>> but it's security model is definitely different.
>>
>> > ### Aux POW intermediate block
>> >
>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the
>> chain
>> > 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.
>>
>> Note how you're basically proposing for the block interval to be
>> decreased,
>> which has security implications due to increased orphan rates.
>>
>> > ### Heaviest chain rule change
>> >
>> > This is a semi-hard change, because non-upgraded nodes can get on the
>> wrong
>> > chain in case of attack. However,
>>
>> Exactly! Not really a soft-fork.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a1139e25871733c055d5d2677
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A hard-fork is a situation where non-upgraded nodes reject=
a block mined and relayed by upgraded nodes.=C2=A0 This creates a fork tha=
t cannot heal regardless of what follows.<div><br></div><div>This proposal =
is not a hard-fork, because the non-upgraded node *will heal* if the attack=
has less than 1/2 of the original-POW power in the long term.</div><div><b=
r></div><div>The cost of such an attack is the cost of a normal "51%&q=
uot; attack, multiplied by the fractional weight of the original POW (e.g. =
0.75 or 0.5).<br></div><div><br></div><div>So rather than saying this is a =
hard-fork, I would say that this is a soft-fork with reduced security for n=
on-upgraded nodes. I would also say that the reduction in security is propo=
rtional to the reduction in weight of the original POW at the time of attac=
k.<br></div><div><br></div><div>As mentioned before, the original-POW weigh=
t starts at 1.0 and is reduced over a long period of time.=C2=A0 I would se=
t up the transition curve so that all nodes upgrade by the time the weight =
is, say, 0.75.=C2=A0 In reality, nodes protecting high economic value would=
upgrade early.</div><div><br></div><div><div class=3D"gmail_quote"><div di=
r=3D"ltr">On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev <<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a>> wrote:<br></div><blockquote 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>If a block that would be discarded under p=
revious rules becomes accepted after a rule addition, there is no reason to=
not simply call the new rule a hard fork. IOW it's perfectly rational =
to consider a weaker block as "invalid" relative to the strong ch=
ain. As such I don't see any reason to qualify the term, it's a har=
d fork. But Peter's observation (the specific behavior) is ultimately w=
hat matters.</div></div><div dir=3D"auto"><div><br></div><div>e</div></div>=
<div dir=3D"auto"><div><br>On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoi=
n-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br></d=
iv><blockquote type=3D"cite"><div><div dir=3D"auto">+1 to all of Peter Todd=
's comments</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>> 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, Dev=
random via bitcoin-dev wrote:<br>
<br>
Some quick thoughts...<br>
<br>
> Hi all,<br>
><br>
> Feedback is welcome on the draft below.=C2=A0 In particular, I want to=
see if<br>
> there is interest in further development of the idea and also interest=
ed in<br>
> any attack vectors or undesirable dynamics.<br>
><br>
> (Formatted version available here:<br>
> <a href=3D"https://github.com/devrandom/btc-papers/blob/master/aux-pow=
.md" rel=3D"noreferrer" target=3D"_blank">https://github.com/devrandom/btc-=
papers/blob/master/aux-pow.md</a> )<br>
><br>
> # 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 it a<br>
"pseudo-soft-fork"<br>
<br>
My reasoning being that after implementation, a chain with less total work =
than<br>
the main chain - but more total SHA256^2 work than the main chain - might b=
e<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>
> ### Aux POW intermediate block<br>
><br>
> Auxiliary POW blocks are introduced between normal blocks - i.e. the c=
hain<br>
> alternates between the two POWs.<br>
> Each aux-POW block points to the previous normal block and contains<br=
>
> transactions just like a normal block.<br>
> Each normal block points to the previous aux-POW block and must contai=
n all<br>
> transactions from the aux-POW block.<br>
<br>
Note how you're basically proposing for the block interval to be decrea=
sed,<br>
which has security implications due to increased orphan rates.<br>
<br>
> ### Heaviest chain rule change<br>
><br>
> This is a semi-hard change, because non-upgraded nodes can get on the =
wrong<br>
> chain in case of attack.=C2=A0 However,<br>
<br>
Exactly! Not really a soft-fork.<br>
<br>
--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-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" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a hr=
ef=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" targe=
t=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=
</a></span><br></div></blockquote></div>___________________________________=
____________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>
--001a1139e25871733c055d5d2677--
|
