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
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B366DB62
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 May 2017 15:30:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com
[209.85.215.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5F2F91A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 May 2017 15:30:49 +0000 (UTC)
Received: by mail-lf0-f41.google.com with SMTP id a5so19810767lfh.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 May 2017 08:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=iovvb3qJYYvf7CIk3SZNEsrOxyKEOpyesnmLMoWJ7UQ=;
b=Nh5R2gNvdGnPxAWeRHV42LKOgtaSw8vHaye70hTjLXWx6a2ASD09zTTS3eWDMJ0UG9
y+t25xB9DHNZs3hTTy+Wkip9Rbm/1FFJMXfemgyoU5/N+MzZoOR5apU7KG3a8wNFoZCW
SdudTqm1p1zXKuOzUvb+j50RXmpyr/3RQmOOWYHKDadxtj69gNCrGesllgOQgvTElnwf
hf23Q0mJi04Rp2T/fguwLZgYv16vLI7uFYC6wr1JUnrU4zvsmDewCmihhLXMyzmlunZy
xIB+4e2YMmlV9vdnkGS6yLHlkMz4hZ0j6B+09ZQG9YJmpIZR16HaJRfC2V/dvLDkxm26
L8Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=iovvb3qJYYvf7CIk3SZNEsrOxyKEOpyesnmLMoWJ7UQ=;
b=jjUGEk78LT85mpZc+AInYo4gBHBJjppBSNrNdCavFtEbI2SxgPjbGWoJuLpPQbq0JB
K60QDC/2tl1NRD10MIqX/stbfIt7/pxvUlPqjkW3Sl0BzI+rU4Mw7GF3BzcqeflUAem4
jXTz348V1cVhRRILF/h2uufgBm4C/tyNqjGxCIVTAydoIT/oW+U2E75nNMgkhEXJgjPM
bky2eJP9qRZ87Xc1+DjLaZE2R5WOvukYji/eHPhmF4As6/m/6XEjYR4WtI2h9ZhyOY57
NTAipIoZpoQ875H1tf1+pF3nEzA7WqMWzw3T2f8ManLxAc+LKycjHizCfIj7zQ/1bZRl
UjTQ==
X-Gm-Message-State: AODbwcBdnspsDBDBwC9C5hPLBhK8yBpvdtsTj8lrkeTZ3s522cDecYqE
wXWjO+WTlZ449RK4tSg0d5zQl2vR4w==
X-Received: by 10.46.20.14 with SMTP id u14mr6874965ljd.101.1495467047548;
Mon, 22 May 2017 08:30:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.17.222 with HTTP; Mon, 22 May 2017 08:30:46 -0700 (PDT)
Received: by 10.25.17.222 with HTTP; Mon, 22 May 2017 08:30:46 -0700 (PDT)
In-Reply-To: <20170522133335.GA17194@fedora-23-dvm>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
<20170522133335.GA17194@fedora-23-dvm>
From: Paul Sztorc <truthcoin@gmail.com>
Date: Mon, 22 May 2017 17:30:46 +0200
Message-ID: <CA+XQW1h22jmwq+qN69UgOhE0LZqmUDpnrmF0ZM-+2ZpoPsTrwQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="f403045fbe8c247a5405501e8ea6"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion
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, 22 May 2017 15:30:50 -0000
--f403045fbe8c247a5405501e8ea6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Charlie, I'll be mostly in the tech track, of course. And I've already
planned to meet RSK guys after their event tomorrow.
Ryan, the more review the better. We aren't in any direct rush, other than
the natural desire to have cool things as early as possible.
Peter, responses below:
On May 22, 2017 9:33 AM, "Peter Todd" <pete@petertodd.org> wrote:
On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote=
:
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.
Thanks for the credit, although I think the security properties of what
you're
proposing are very different - and much weaker - than what I proposed in
Zookeyv.
As you state in [2] "if miners never validate sidechains at all, whoever
bids
the most for the chain (on a continuous basis), can spam a 3-month long
stream
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-withdrawal
security-level is SPV, miners who remain blind forever have no way of
telling
who =E2=80=9Cshould=E2=80=9D really get the funds."
Finally, you suggest that in this event, miners *do* have to upgrade to a
full
node, an expensive and time-consuming operation (and one that may be
impossible
for some miners if necessary data isn't available).
Surprisingly, this requirement (or, more precisely, this incentive) does
not effect miners relative to each other. The incentive to upgrade is only
for the purpose of preventing a "theft" -- defined as: an improper
withdrawal from a sidechain. It is not about miner revenues or the ability
to mine generally (or conduct BMM specifically). The costs of such a theft
(decrease in market price, decrease in future transaction fee levels) would
be shared collectively by all future miners. Therefore, it would have no
effect on miners relative to each other.
Moreover, miners have other recourse if they are unable to run the node.
They can adopt a policy of simply rejecting ("downvoting") any withdrawals
that they don't understand. This would pause the withdraw process until
enough miners understand enough of what is going on to proceed with it.
Finally, the point in dispute is a single, infrequent, true/false question.
So miners may resort to semi-trusted methods to supplement their decision.
In other words, they can just ask people they trust, if the withdrawal is
correct or not. It is up to users to decide if they are comfortable with
these risks, if/when they decide to deposit to a sidechain.
It's unclear to me what the incentive is for miners to do any of this. Coul=
d
you explain in more detail what that incentive is?
It is a matter of comparing the costs and benefits. Ignoring theft, the
costs are near-zero, and the benefits are >0. Specifically, they are: a
higher BTC price and greater transaction fees. Theft is discouraged by
attempting to tie a theft to a loss of confidence in the miners, as
described in the spec/website.
In general the incentives are very similar to those of Bitcoin itself.
Paul
> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--f403045fbe8c247a5405501e8ea6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>Charlie, I'll be mostly in the tech track, of co=
urse. And I've already planned to meet RSK guys after their event tomor=
row.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Ryan, the more revi=
ew the better. We aren't in any direct rush, other than the natural des=
ire to have cool things as early as possible.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Peter, responses below:</div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D=
"gmail_quote">On May 22, 2017 9:33 AM, "Peter Todd" <<a href=
=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> wrote:<br type=3D=
"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-text">On Mon, M=
ay 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:<br>
> This work includes the relatively new concept of "Blind Merged Mi=
ning"<br>
> [2] which I developed in January to allow SHA256^2 miners to merge-min=
e<br>
> these "drivechains", even if these miners aren't running=
the actual<br>
> sidechain software. The goal is to prevent sidechains from affecting t=
he<br>
> levelness of the mining "playing field". BMM is conceptually=
similar to<br>
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not<br>
> required for drivechain, but it would address some of the last remaini=
ng<br>
> concerns.<br>
<br>
</div>Thanks for the credit, although I think the security properties of wh=
at you're<br>
proposing are very different - and much weaker - than what I proposed in<br=
>
Zookeyv.</blockquote></div></div></div><div dir=3D"auto"><div class=3D"gmai=
l_extra" dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As you state in [2] "if miners never validate sidechains at all, whoev=
er bids<br>
the most for the chain (on a continuous basis), can spam a 3-month long str=
eam<br>
of invalid headers, and then withdraw all of the coins deposited to the<br>
sidechain." and "Since the mining is blind, and the sidechain-wit=
hdrawal<br>
security-level is SPV, miners who remain blind forever have no way of telli=
ng<br>
who =E2=80=9Cshould=E2=80=9D really get the funds."<br>
<br>
Finally, you suggest that in this event, miners *do* have to upgrade to a f=
ull<br>
node, an expensive and time-consuming operation (and one that may be imposs=
ible<br>
for some miners if necessary data isn't available).<br></blockquote></d=
iv></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Surprisingly, =
this requirement (or, more precisely, this incentive) does not effect miner=
s relative to each other. The incentive to upgrade is only for the purpose =
of preventing a "theft" -- defined as: an improper withdrawal fro=
m a sidechain. It is not about miner revenues or the ability to mine genera=
lly (or conduct BMM specifically). The costs of such a theft (decrease in m=
arket price, decrease in future transaction fee levels) would be shared col=
lectively by all future miners. Therefore, it would have no effect on miner=
s relative to each other.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">Moreover, miners have other recourse if they are unable to run the node. =
They can adopt a policy of simply rejecting ("downvoting") any wi=
thdrawals that they don't understand. This would pause the withdraw pro=
cess until enough miners understand enough of what is going on to proceed w=
ith it.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Finally, t=
he point in dispute is a single, infrequent, true/false question. So miners=
may resort to semi-trusted methods to supplement their decision. In other =
words, they can just ask people they trust, if the withdrawal is correct or=
not. It is up to users to decide if they are comfortable with these risks,=
if/when they decide to deposit to a sidechain.</div><div dir=3D"auto"><div=
class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote"><blockquote =
class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">
<br>
It's unclear to me what the incentive is for miners to do any of this. =
Could<br>
you explain in more detail what that incentive is?<br></blockquote></div></=
div></div><div dir=3D"auto"><br></div><div dir=3D"auto">It is a matter of c=
omparing the costs and benefits. Ignoring theft, the costs are near-zero, a=
nd the benefits are >0. Specifically, they are: a higher BTC price and g=
reater transaction fees. Theft is discouraged by attempting to tie a theft =
to a loss of confidence in the miners, as described in the spec/website.</d=
iv><div dir=3D"auto">In general the incentives are very similar to those of=
Bitcoin itself.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Paul</d=
iv><div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"=
gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div class=3D"elided-text"><br>
<br>
> [2] <a href=3D"http://www.truthcoin.info/blog/blind-merged-mining/" re=
l=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/<wbr>blog/blin=
d-merged-mining/</a><br>
> [3] <a href=3D"https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-=
10-17.log" rel=3D"noreferrer" target=3D"_blank">https://s3.amazonaws.com/<w=
br>peter.todd/bitcoin-wizards-13-<wbr>10-17.log</a><br>
<br>
</div><font color=3D"#888888">--<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>
</font></blockquote></div><br></div></div></div>
--f403045fbe8c247a5405501e8ea6--
|
