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
|
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 8F392A7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Nov 2017 22:39:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f196.google.com (mail-qt0-f196.google.com
[209.85.216.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D7FB879
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Nov 2017 22:39:13 +0000 (UTC)
Received: by mail-qt0-f196.google.com with SMTP id h4so13008537qtk.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 06 Nov 2017 14:39:13 -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=QifNr6IXMqLZYNMD+Bfgxj1oec63DQeDVvr+OU8HOaE=;
b=tIM0zFUayeItu8nAUAKUeB0hebAiwMcrYrQKOO+zctZ0no5k4JsMJ6My+xiohacG6Q
w7zmffauKdrffrW80Uuv6xeyOiUwJzEAL27kEkKCNo+rcRfmlBATpnfzcD8WLbO68s5v
JiIA7/xZdugq99Pr7uUECAMV3bi+bKfIIKIF5LpTJ5MbNPGdKUZcjwhLFXnfPVdNqngD
GyYfF87nu7LDw/cR1vXjz42PAxdt72hQ4siv9rAdReiQ8pKKPXH/2bneZX7HRl6qEEeD
G6TP0jms5Meagce/r2MlheL6iax5sCV+5Z1QqCbcz7c/eUit83uoUPrxTph4pa87Zq2k
2uUg==
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=QifNr6IXMqLZYNMD+Bfgxj1oec63DQeDVvr+OU8HOaE=;
b=DYOJsY6k5shGIX/XwRI+rQgY7ZcY4Df+3EthO9rrh9YAEgxilY4Xtfx58wU/O0za5w
QmJZzvoGaZCwUHN3JDSdlAGYsHMgYfNujCuiC3ae3bRoN0o7+Zkjy53/FPh5f1w/ctvg
gMTFP5+YIEIKMtc9NqibB0PEY2CFKj2tfdU65jqMxLv7eLW0HlZFad1EpaLnTh9zl2Mp
Q5gzh4tL5hqQBw732KH9VLBqitZ75CLW5NL7LO0XrOkondrDJkFQxS/wznN35TVd5SAI
d/zCaLnvzRlS/5HQRojqCVZ09MVSbvLB8uzXRacC/8DLiJ7uhgY6HvQ8kFtX3xsg8jiD
0Faw==
X-Gm-Message-State: AMCzsaXKnWG5wRb/aamG/XaiwOsY5t5fVD3WM8s3ph8Ya5NOWi+31vvX
KhMfwaXvkU3ynwRGsInKclDdlSGfff1Vaelkod+EXNq7
X-Google-Smtp-Source: ABhQp+S8FkmFqJidVEY9bL7Y84aHzeTqMWfCQhR04zyia8vMBhGenY7m3fWpKRITG2Og75U7vzg8X7yh/BFT5nkBAyU=
X-Received: by 10.237.37.142 with SMTP id x14mr23857509qtc.6.1510007952771;
Mon, 06 Nov 2017 14:39:12 -0800 (PST)
MIME-Version: 1.0
References: <CAB0O3SVjhG19R61B78hFCPwfwWemTXj=tOsvgAgoNbjFYXXAtg@mail.gmail.com>
<20171106195000.GA7245@fedora-23-dvm>
In-Reply-To: <20171106195000.GA7245@fedora-23-dvm>
From: Devrandom <c1.bitcoin@niftybox.net>
Date: Mon, 06 Nov 2017 22:39:02 +0000
Message-ID: <CAB0O3SVsXL_zVBs-OFEaFuKTXoyYAiB8TEZStOfou7mMkHLMnA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="001a114132a4a2248f055d581f5a"
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: Mon, 06 Nov 2017 23:53:58 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 22:39:14 -0000
--001a114132a4a2248f055d581f5a
Content-Type: text/plain; charset="UTF-8"
Hi Peter, thank you for the review. See below
On Mon, Nov 6, 2017 at 11:50 AM Peter Todd <pete@petertodd.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.
>
The interesting thing is that the cost of attack varies smoothly as you
vary the POW weights.
To attack non-upgraded nodes, you still have to "51%" the original POW.
The reward going to that POW will vary smoothly between 1.0 * block_reward
and whatever
target value (e.g. 0.5 * block_reward) and the difficulty of attack will
tend to be proportional to that.
In a real hard-fork, your software just breaks at the fork point. In this
case, it's just the non-upgraded
node security level declining from 100% to 50% over a long period of time.
I envision the transition of POW weights will be over 1-3 years, which
leaves plenty of time to
upgrade after the fork activates.
>
> > ### 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.
>
Note that the total transaction rate and block size don't materially
change, so I don't
see why the orphan rate will change. Normal blocks are constrained to have
all of the txs of the aux blocks, so propagation time should stay the
same. Am I missing
something?
>
> > ### 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.
>
"smooth-fork" perhaps? :)
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--001a114132a4a2248f055d581f5a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Peter, thank you for the review.=C2=A0 See below<br><br=
><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Nov 6, 2017 at 11:50 A=
M Peter Todd <<a href=3D"mailto:pete@petertodd.org">pete@petertodd.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">On Wed, Nov 01, 2017 =
at 05:48:27AM +0000, Devrandom 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></blockquote><div><=
br></div><div>The interesting thing is that the cost of attack varies smoot=
hly as you vary the POW weights.</div><div>To attack non-upgraded nodes, yo=
u still have to "51%" the original POW.</div><div>The reward goin=
g to that POW will vary smoothly between 1.0 * block_reward and whatever</d=
iv><div>target value (e.g. 0.5 * block_reward) and the difficulty of attack=
will tend to be proportional to that.</div><div><br></div><div>In a real h=
ard-fork, your software just breaks at the fork point.=C2=A0 In this case, =
it's just the non-upgraded</div><div>node security level declining from=
100% to 50% over a long period of time.</div><div><br></div><div>I envisio=
n the transition of POW weights will be over 1-3 years, which leaves plenty=
of time to</div><div>upgrade after the fork activates.</div><div>=C2=A0<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<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></blockqu=
ote><div><br></div><div>Note that the total transaction rate and block size=
don't materially change, so I don't</div><div>see why the orphan r=
ate will change.=C2=A0 Normal blocks are constrained to have</div><div>all =
of the txs of the aux blocks, so propagation time should stay the same.=C2=
=A0 Am I missing</div><div>something?</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<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></blockquote><div><br></div><div>"=
smooth-fork" perhaps? :)</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<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>
</blockquote></div></div>
--001a114132a4a2248f055d581f5a--
|
