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
|
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 879AC3EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Nov 2017 05:48:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f193.google.com (mail-qt0-f193.google.com
[209.85.216.193])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8D855A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Nov 2017 05:48:39 +0000 (UTC)
Received: by mail-qt0-f193.google.com with SMTP id h4so1461420qtk.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Oct 2017 22:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=niftybox-net.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=Pcg7Cchth9jvgIYOWhPRCV5xXpJEZHsGviliKjwwDi4=;
b=aFHSy2OwrqdiCAjHJkBfZ8tb0f0eDPcL2lwSm2hK3Ua6SCqnmhYnNQN2Qv2YVUVLZZ
SI4ioNuAQHF9fWgJEiFUKV+uqciCERyXION+49swiZdRXnbiANEScg6HH4HTxxIHId0Z
8f7CKrtblxlFqY1+vNQ3dOHs6iFsuq0YeasusnH9bb68kcfIuHKHkJyOruc7GCsLeefv
49d/NCDYc0BhhOYbaPJDxTfmvqAQF4+NoUvQw1VtNjNmQCu9rJ72pltLMLJK/Vv9t28v
h1vo6JtJlbB3hQ30pd/aIIcVNde7nOmNDEe6RMYruZr/AkLq1tOF+R2hhqa+/RpGOYiQ
Ze8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=Pcg7Cchth9jvgIYOWhPRCV5xXpJEZHsGviliKjwwDi4=;
b=j34lCGo7qQuzJcHT9/tcqiohWuGn3nfBI1Mt/PiPRKurtd3y2JijVw20wI3QHZa0sC
/QNldy3R+r76+EiaD/ElhXF0HDPXnIJcACJWPyzDhJFdwpL7AzIx7tAxxCmuho7sq61l
fiDAeZLU6t5YNnA+PE12a2ifF1CMMrMQG5fc04aV7EUFYaQ1DkIjY+jmvwDKMt+r/9Ei
Kap8v5eSKLqoyTbx93VdxZzt1ha1T5cSQErQlYnEJ7v6uYJjOEFWBAYQ/mNBReNkz/2s
jKFRJrd8JwrC0A0YNmDH+hSQDsT536vFfXs0GoKmInkD/aSPw8KAX8MJ8IhhB2Y28vYc
yi+w==
X-Gm-Message-State: AJaThX56z0k2IynrhSu9vj81dfiUImszu9rmK2mIhZhZKZ53C+iUyup/
rRWAHYD1T6oAiXKTuhqs52Pgu6KXjzbF4D5MXU5NIVH3
X-Google-Smtp-Source: ABhQp+QEYfX16R+aQkZOpMRMnNA4+PReWBRVJBGGiRjkwd6/FNsqY/UkFVWedLdZ+NSK1TgX7Hi8upUi2LwpyAH/ZBQ=
X-Received: by 10.200.36.50 with SMTP id c47mr6613867qtc.274.1509515318131;
Tue, 31 Oct 2017 22:48:38 -0700 (PDT)
MIME-Version: 1.0
From: Devrandom <c1.bitcoin@niftybox.net>
Date: Wed, 01 Nov 2017 05:48:27 +0000
Message-ID: <CAB0O3SVjhG19R61B78hFCPwfwWemTXj=tOsvgAgoNbjFYXXAtg@mail.gmail.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1141025c521d73055ce56c87"
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: Thu, 02 Nov 2017 23:33:13 +0000
Subject: [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: Wed, 01 Nov 2017 05:48:40 -0000
--001a1141025c521d73055ce56c87
Content-Type: text/plain; charset="UTF-8"
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
## Motivation:
- Mitigate mining centralization pressures by introducing a POW that does
not have economies of scale
- Introduce an intermediary confirmation point, reducing the impact of
mining power fluctuations
Note however that choice of a suitable POW will require deep analysis.
Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are
not, unexpected/covert optimization.
In particular, unexpected/covert optimizations, such as ASCIBOOST, present
a potential centralizing and destabilizing force.
## Design
### 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.
Block space is not increased.
The new intermediate block and the pointers are introduced via a soft-fork
restriction.
### Reward for aux POW miners
The reward for the aux POW smoothly increases from zero to a target value
(e.g. 1/2 of the total reward) over time.
The reward is transferred via a soft-fork restriction requiring a coinbase
output to an address published in the
aux-POW block.
### Aux POW difficulty adjustment
Difficulty adjustments remain independent for the two POWs.
The difficulty of the aux POW is adjusted based on the average time between
normal block found
to aux block found.
Further details are dependent on the specific POW.
### 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,
it might be possible to construct an alert system that notifies
non-upgraded nodes of an upcoming rule change.
All blocks are still valid, so this is not a hardforking change.
The heaviest chain definition changes from sum of `difficulty` to sum of:
mainDifficulty ^ x * auxDifficulty ^ y
where we start at:
x = 1; y = 0
and end at values of x and y that are related to the target relative
rewards. For example, if the target rewards
are equally distributed, we will want ot end up at:
x = 1/2; y = 1/2
so that both POWs have equal weight. If the aux POW is to become dominant,
x should end small relative to y.
## Questions and Answers
- What should be the parameters if we want the aux POW to have equal
weight? A: 1/2 of the reward should be transferred
to aux miners and x = 1/2, y = 1/2.
- What should be the parameters if we want to deprecate the main POW? A:
most of the reward should be transferred to
aux miners and x = 0, y = 1. The main difficulty will tend to zero, and
aux miners will just trivially generate the
main block immediately after finding an aux block, with identical content.
- Wasted bandwidth to transfer transactions twice? A: this can be
optimized by skipping transactions already
transferred.
- Why would miners agree to soft-fork away some of their reward? A: they
would agree if they believe that
the coins will increase in value due to improved security properties.
## Open Questions
- After a block of one type is found, we can naively assume that POW will
become idle while a block of the other type is being mined. In practice,
the spare capacity can be used to find alternative ("attacking") blocks or
mine other coins. Is that a problem?
- Is selfish mining amplified by this scheme for miners that have both
types of hardware?
## POW candidates
- SHA256 (i.e. use same POW, but introduce an intermediate block for faster
confirmation)
- Proof of Space and Time (Bram Cohen)
- Equihash
- Ethash
## Next Steps
- evaluate POW candidates
- evaluate difficulty adjustment rules
- simulate miner behavior to identify if there are incentives for
detrimental behavior patterns (e.g. block withholding / selfish mining)
- Protocol details
## Credits
Bram Cohen came up with a similar idea back in March:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html
--001a1141025c521d73055ce56c87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"color:rgb(33,33,33);font-size:13px">Hi all,=
</span><div style=3D"color:rgb(33,33,33);font-size:13px"><br></div><div sty=
le=3D"color:rgb(33,33,33);font-size:13px">Feedback is welcome on the draft =
below.=C2=A0 In particular, I want to see if there is interest in further d=
evelopment of the idea and also interested in any attack vectors or undesir=
able dynamics.</div><div style=3D"color:rgb(33,33,33);font-size:13px"><br><=
/div><div style=3D"color:rgb(33,33,33);font-size:13px">(Formatted version a=
vailable here:=C2=A0<a href=3D"https://github.com/devrandom/btc-papers/blob=
/master/aux-pow.md">https://github.com/devrandom/btc-papers/blob/master/aux=
-pow.md</a> )</div><div style=3D"color:rgb(33,33,33);font-size:13px"><br></=
div><div style=3D"color:rgb(33,33,33);font-size:13px"><div># Soft-fork Intr=
oduction of a New POW</div><div><br></div><div>## Motivation:<br></div><div=
><br></div><div>- Mitigate mining centralization pressures by introducing a=
POW that does not have economies of scale</div><div>- Introduce an interme=
diary confirmation point, reducing the impact of mining power fluctuations<=
/div><div><br></div><div>Note however that choice of a suitable POW will re=
quire deep analysis.=C2=A0 Some pitfalls include: botnet mining, POWs that =
seem ASIC resistant but are not, unexpected/covert optimization.</div><div>=
<br></div><div>In particular, unexpected/covert optimizations, such as ASCI=
BOOST, present a potential centralizing and destabilizing force.</div><div>=
<br></div><div>## Design</div><div><br></div><div>### Aux POW intermediate =
block</div><div><br></div><div>Auxiliary POW blocks are introduced between =
normal blocks - i.e. the chain alternates between the two POWs.</div><div>E=
ach aux-POW block points to the previous normal block and contains transact=
ions just like a normal block.</div><div>Each normal block points to the pr=
evious aux-POW block and must contain all transactions from the aux-POW blo=
ck.</div><div>Block space is not increased.</div><div><br></div><div>The ne=
w intermediate block and the pointers are introduced via a soft-fork restri=
ction.</div><div><br></div><div>### Reward for aux POW miners</div><div><br=
></div><div>The reward for the aux POW smoothly increases from zero to a ta=
rget value (e.g. 1/2 of the total reward) over time.</div><div>The reward i=
s transferred via a soft-fork restriction requiring a coinbase output to an=
address published in the</div><div>aux-POW block.</div><div><br></div><div=
>### Aux POW difficulty adjustment</div><div><br></div><div>Difficulty adju=
stments remain independent for the two POWs.</div><div><br></div><div>The d=
ifficulty of the aux POW is adjusted based on the average time between norm=
al block found</div><div>to aux block found.</div><div><br></div><div>Furth=
er details are dependent on the specific POW.</div><div><br></div><div>### =
Heaviest chain rule change</div><div><br></div><div>This is a semi-hard cha=
nge, because non-upgraded nodes can get on the wrong chain in case of attac=
k.=C2=A0 However,</div><div>it might be possible to construct an alert syst=
em that notifies non-upgraded nodes of an upcoming rule change.</div><div>A=
ll blocks are still valid, so this is not a hardforking change.</div><div><=
br></div><div>The heaviest chain definition changes from sum of `difficulty=
` to sum of:</div><div><br></div><div>=C2=A0 =C2=A0 mainDifficulty ^ x * au=
xDifficulty ^ y</div><div><br></div><div>where we start at:</div><div><br><=
/div><div>=C2=A0 =C2=A0 x =3D 1; y =3D 0</div><div><br></div><div>and end a=
t values of x and y that are related to the target relative rewards.=C2=A0 =
For example, if the target rewards</div><div>are equally distributed, we wi=
ll want ot end up at:</div><div><br></div><div>=C2=A0 =C2=A0 x =3D 1/2; y =
=3D 1/2</div><div><br></div><div>so that both POWs have equal weight.=C2=A0=
If the aux POW is to become dominant, x should end small relative to y.</d=
iv><div><br></div><div><br></div><div>## Questions and Answers</div><div><b=
r></div><div>- What should be the parameters if we want the aux POW to have=
equal weight? A: 1/2 of the reward should be transferred</div><div>to aux =
miners and x =3D 1/2, y =3D 1/2.</div><div><br></div><div>- What should be =
the parameters if we want to deprecate the main POW?=C2=A0 A: most of the r=
eward should be transferred to</div><div>aux miners and x =3D 0, y =3D 1.=
=C2=A0 The main difficulty will tend to zero, and aux miners will just triv=
ially generate the</div><div>main block immediately after finding an aux bl=
ock, with identical content.</div><div><br></div><div>- Wasted bandwidth to=
transfer transactions twice?=C2=A0 A: this can be optimized by skipping tr=
ansactions already</div><div>transferred.</div><div><br></div><div>- Why wo=
uld miners agree to soft-fork away some of their reward?=C2=A0 A: they woul=
d agree if they believe that</div><div>the coins will increase in value due=
to improved security properties.</div><div><br></div><div>## Open Question=
s</div><div><br></div><div>- After a block of one type is found, we can nai=
vely assume that POW will become idle while a block of the other type is be=
ing mined.=C2=A0 In practice, the spare capacity can be used to find altern=
ative ("attacking") blocks or mine other coins.=C2=A0 Is that a p=
roblem?</div><div>- Is selfish mining amplified by this scheme for miners t=
hat have both types of hardware?</div><div><br></div><div>## POW candidates=
</div><div><br></div><div>- SHA256 (i.e. use same POW, but introduce an int=
ermediate block for faster confirmation)</div><div>- Proof of Space and Tim=
e (Bram Cohen)</div><div>- Equihash</div><div>- Ethash</div><div><br></div>=
<div>## Next Steps</div><div><br></div><div>- evaluate POW candidates</div>=
<div>- evaluate difficulty adjustment rules</div><div>- simulate miner beha=
vior to identify if there are incentives for detrimental behavior patterns =
(e.g. block withholding / selfish mining)</div><div>- Protocol details</div=
><div><br></div><div>## Credits</div><div><br></div><div>Bram Cohen came up=
with a similar idea back in March:</div><div><a href=3D"https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html" target=3D"_bl=
ank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013=
744.html</a></div></div></div>
--001a1141025c521d73055ce56c87--
|