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
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
|
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 385A4BDA
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Dec 2017 19:55:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com
[209.85.217.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF74B413
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 5 Dec 2017 19:55:34 +0000 (UTC)
Received: by mail-ua0-f172.google.com with SMTP id e10so1145557uah.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 05 Dec 2017 11:55:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-language;
bh=VSVJOzCCCR5lSQzy1wT9uU+4GTnqpPC7dT1CtUa2BUY=;
b=qKxxmB2aE+i9gaq2gER2L/Ij2vYnM3p2MAKyzoYc/dEBXNR57T/pO17iznt9AtapD5
t03lysatpn1w4SpK+3siSjeppEM03GE8M1acIzva7gxO6YXG2mU/z0BTKds7XbaSJYpE
isqyQeHhr6FB7FAAj6o8aE3epNpbuRjF3f7VwYUFsfYM4cabUqXsqFE3PFxx6NkgKlll
qgitopqOZ4qspcgAjEYoLonl9iLrZEBBWhDu4u9+b+s6bFw06YycMhr0vYKjZT8MJZi6
HHmzh4woIZgPDLW5Wltvvxhz6ZNem/a6PXfZRRJTFOisWH7FzkLfnfWrqwpNRsYd4Z6E
agaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language;
bh=VSVJOzCCCR5lSQzy1wT9uU+4GTnqpPC7dT1CtUa2BUY=;
b=q6CN7KL6TgwMx1TqxOHFPP9j8TdWF+Bh4YFkypwVu4OqP4/UaaOVErTmfcSzyHhuXe
/lI5zkTECCVxaRzjklNjqy4PHHp8f6xvHW0XQuwZhJLKd8QRG1LbL+ixQWXY4wL56UDX
m0sPdxLoAy0P8fyxHYY4S8t1KV1XfAVKsGtQJSjdSzeU5o+ly+ZMqzwKtdOONz8r3PZ2
UiirudcbEfsUQ/ZEgUnHBjNbn4Wa355zaGvLHAiob8QObx6GS4O17+um1JNBW0z5ocAX
anzVJ04cuzvEI94Fjv1QdlhjbgrM24fnRmuuBEOjIG+eEp+sFRk67jv4pxwjww447sKn
LHGA==
X-Gm-Message-State: AKGB3mLLF/GqZCTCyCsd9WVJ1vI+RdoLYjSmD1UAIs46F7tGD6u9jUuJ
f8XuuGsLL9ZPdOosUeW4e+NMGQ==
X-Google-Smtp-Source: AGs4zMYKY91U/aRrTD2NpSV+0CKUThAQA1Er//ieTNjSKbDU/0lSfNrZiM2Y0HIrF6VOQbZ8S0PXMg==
X-Received: by 10.176.90.108 with SMTP id m41mr6197552uad.178.1512503733457;
Tue, 05 Dec 2017 11:55:33 -0800 (PST)
Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net.
[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
p18sm431904vkd.17.2017.12.05.11.55.32
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 05 Dec 2017 11:55:32 -0800 (PST)
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <d3497397-33c3-90c1-1be8-a733736eac0b@gmail.com>
<1bb6cccd-3f6d-d62a-2825-4e6f46a4b525@mattcorallo.com>
<dd2781a6-3e10-9f0c-6ee0-a2c070b7cf67@gmail.com>
<CAB+qUq4wNv=-ZSibUvVCwYSE7Qw8xe8EH91KG6znUp1d7X=mdA@mail.gmail.com>
<CAGL6+mF1YbjZ28MtvPxTye-HndEqmd6LkaFVr9BWvPiK-kfVTA@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <b0c3f0f9-72f4-b73e-f5b1-e5590f9456aa@gmail.com>
Date: Tue, 5 Dec 2017 14:55:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CAGL6+mF1YbjZ28MtvPxTye-HndEqmd6LkaFVr9BWvPiK-kfVTA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------990D476ECC191B99853130EF"
Content-Language: en-US
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Two Drivechain BIPs
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, 05 Dec 2017 19:55:36 -0000
This is a multi-part message in MIME format.
--------------990D476ECC191B99853130EF
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Other Chris,
Thanks for pointing this out. Here are my responses.
On 12/4/2017 3:11 PM, Chris Stewart wrote:
>There is another interesting analysis on BMM and drivechains from
/u/almkglor on reddit. I'm going to share here for visibility.
>> 3 and 7 will mean that non-verifying miners will be (inadvertently)
complicit in theft. Drivechains have 1008-block cycles ostensibly to
protect against theft, so that someone can "raise the alarm" and tell
miners to downvote a particular theft withdrawal, but that sounds too
much like centralized collusion to me.
Well, that is simply not what "centralized" means. "Centralized" means
that one person has special, irreplaceable influence. In contrast,
"decentralized" means that the process is not uniquely influenced by
what any *one* individual does or believes. Which is the case here: each
miner can independently make a decision about what to check, how to
check it, and what to do as a result. They could do undertake this
process, even if they ignored what everyone else was doing.
>> ...
>>
>> It seems Drivechain's security model is: miners always upvote by
default. If a theft withdrawal is done on the mainchain, some sidechain
nodes call up their miner friends (which makes me worry about miner
centralization) to downvote it instead.
>>
>> The problem is: what if after a theft withdrawal is defeated, another
theft withdrawal is done? And another, and another? This weakens the
peg: while a theft withdrawal is on-going, a genuine withdrawal can't be
posted (at least as I understand Sztorc's explanation). This chokes the
sidechain withdrawal.
This is a good question.
The answer is that there are mechanisms in place to address these
problems. Contrary to the reviewer's interpretation, multiple
withdrawal-attempts *are* allowed simultaneously. (This part of design
may have changed between now and Nov 2015, and I'm not sure if it was
ever documented anywhere until very recently). Second, only one
withdrawal can be upvoted at a time [ie, per sidechain per main:block].
Third, upvoting one withdrawal automatically downvotes all of the other
withdrawals (all in-progress withdrawals for that sidechain). Thus, we
have the asymmetry we desire. An "auditor class" can ignore all of the
withdrawals, until a significant amount of time has been invested in one
candidate. This makes the attempt more futile. Since they are unlikely
to be meaninglessly harassed, this opens the door to a "farmer class"
who can take it upon themselves to make sure the good withdrawals get
in, and get upvotes (especially early upvotes). Thus, the system can
tolerate a large "loafer class" who just lazily upvotes everything (or
nothing, or only the front-runner).
> TLDR: a miner is most profitable if he always accepts BMM bribes, but
downvotes withdrawal transactions (WT). This obviously isn't ideal
because a withdrawal will never occur from the drivechain if enough
miners employ this strategy -- which seems to be the most profitable
strategy.
>
>-Chris
I agree that miners should "always accept BMM bribes". In my recent
email to Matt Corallo, I described that this is basically the same as
saying that miners should "always mine on top of the heaviest chain".
(Of course, in mainchain Bitcoin miners are advised to mine atop the
heaviest *valid* chain, which is different from this case. It is
different because blind-merged-miners have no way of knowing if the
sidechain blocks they are mining are valid or not, which is kind of the
point. In practice I estimate that between 70% and 100% of today's
hashpower is already mining the mainchain "blind" -- through some
combination of pools, spv and spy mining.)
I don't agree with the conclusion (that the optimal policy is "always
downvoting", see above), but even if this analysis turns out to be
correct, it isn't a total disaster. The result (which is in the original
Nov 2015 specification) is that miners are the ones who perform the
atomic swaps. Then they walk the coins side-to-main (which, at this
point, are *their* coins). As long as there are a few large mining
groups, competition will drive the atomic swap fees down to negligible
levels. This slightly encourages mining to consolidate into two large
pools...but of course that is also true of the status quo!
Paul
=C2=A0
>
> On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>
> I think you are missing a few things.
>
> First of all, I think the security model for sidechains is the
> same as
> that of every blockchain
>
> People will say things, like "but with sidechains 51% hashrate
> can steal
> your coins!", but as I have repeated many times, this is also
> true of
> mainchain btc-tx. =C2=A0is something else?
>
>
> There are substantial opportunity costs as well as a collective
> action problem when it comes to re-writing the mainchain.=C2=A0
>
> Is there anything similar for drivechains? As far as I can tell
> there is no opportunity cost to casting a malicious vote, no
> repercussions, and no collective action barrier that needs to be
> overcome.=C2=A0
>
> Unless I'm missing something I wouldn't liken the security of a
> drivechain to that of the mainchain.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
--------------990D476ECC191B99853130EF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div dir="ltr">Hi Other Chris,<br>
<br>
Thanks for pointing this out. Here are my responses.<br>
<br>
On 12/4/2017 3:11 PM, Chris Stewart wrote:<br>
>There is another interesting analysis on BMM and drivechains
from /u/almkglor on reddit. I'm going to share here for
visibility.<br>
>> 3 and 7 will mean that non-verifying miners will be
(inadvertently) complicit in theft. Drivechains have 1008-block
cycles ostensibly to protect against theft, so that someone can
"raise the alarm" and tell miners to downvote a particular theft
withdrawal, but that sounds too much like centralized collusion to
me.<br>
<br>
Well, that is simply not what "centralized" means. "Centralized"
means that one person has special, irreplaceable influence. In
contrast, "decentralized" means that the process is not uniquely
influenced by what any *one* individual does or believes. Which is
the case here: each miner can independently make a decision about
what to check, how to check it, and what to do as a result. They
could do undertake this process, even if they ignored what
everyone else was doing.<br>
<br>
>> ...<br>
>><br>
>> It seems Drivechain's security model is: miners always
upvote by default. If a theft withdrawal is done on the mainchain,
some sidechain nodes call up their miner friends (which makes me
worry about miner centralization) to downvote it instead.<br>
>> <br>
>> The problem is: what if after a theft withdrawal is
defeated, another theft withdrawal is done? And another, and
another? This weakens the peg: while a theft withdrawal is
on-going, a genuine withdrawal can't be posted (at least as I
understand Sztorc's explanation). This chokes the sidechain
withdrawal.<br>
<br>
This is a good question.<br>
<br>
The answer is that there are mechanisms in place to address these
problems. Contrary to the reviewer's interpretation, multiple
withdrawal-attempts *are* allowed simultaneously. (This part of
design may have changed between now and Nov 2015, and I'm not sure
if it was ever documented anywhere until very recently). Second,
only one withdrawal can be upvoted at a time [ie, per sidechain
per main:block]. Third, upvoting one withdrawal automatically
downvotes all of the other withdrawals (all in-progress
withdrawals for that sidechain). Thus, we have the asymmetry we
desire. An "auditor class" can ignore all of the withdrawals,
until a significant amount of time has been invested in one
candidate. This makes the attempt more futile. Since they are
unlikely to be meaninglessly harassed, this opens the door to a
"farmer class" who can take it upon themselves to make sure the
good withdrawals get in, and get upvotes (especially early
upvotes). Thus, the system can tolerate a large "loafer class" who
just lazily upvotes everything (or nothing, or only the
front-runner).<br>
<br>
> TLDR: a miner is most profitable if he always accepts BMM
bribes, but downvotes withdrawal transactions (WT). This obviously
isn't ideal because a withdrawal will never occur from the
drivechain if enough miners employ this strategy -- which seems to
be the most profitable strategy.<br>
><br>
>-Chris<br>
<br>
I agree that miners should "always accept BMM bribes". In my
recent email to Matt Corallo, I described that this is basically
the same as saying that miners should "always mine on top of the
heaviest chain". (Of course, in mainchain Bitcoin miners are
advised to mine atop the heaviest *valid* chain, which is
different from this case. It is different because
blind-merged-miners have no way of knowing if the sidechain blocks
they are mining are valid or not, which is kind of the point. In
practice I estimate that between 70% and 100% of today's hashpower
is already mining the mainchain "blind" -- through some
combination of pools, spv and spy mining.)<br>
<br>
I don't agree with the conclusion (that the optimal policy is
"always downvoting", see above), but even if this analysis turns
out to be correct, it isn't a total disaster. The result (which is
in the original Nov 2015 specification) is that miners are the
ones who perform the atomic swaps. Then they walk the coins
side-to-main (which, at this point, are *their* coins). As long as
there are a few large mining groups, competition will drive the
atomic swap fees down to negligible levels. This slightly
encourages mining to consolidate into two large pools...but of
course that is also true of the status quo!<br>
<br>
Paul
<div> </div>
</div>
<blockquote type="cite"
cite="mid:CAGL6+mF1YbjZ28MtvPxTye-HndEqmd6LkaFVr9BWvPiK-kfVTA@mail.gmail.com">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Dec 4, 2017 at 1:36 PM, Chris
Pacia via bitcoin-dev <span dir="ltr"><<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div><br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="m_4849272993808656596quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><span class="">
<div class="m_4849272993808656596quoted-text">I
think you are missing a few things.<br>
</div>
<br>
First of all, I think the security model for
sidechains is the same as<br>
that of every blockchain<br>
<br>
People will say things, like "but with
sidechains 51% hashrate can steal<br>
your coins!", but as I have repeated many times,
this is also true of<br>
</span>
mainchain btc-tx. is something else?<br>
</blockquote>
</div>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">There are substantial opportunity costs as
well as a collective action problem when it comes to
re-writing the mainchain. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Is there anything similar for drivechains?
As far as I can tell there is no opportunity cost to
casting a malicious vote, no repercussions, and no
collective action barrier that needs to be overcome. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Unless I'm missing something I wouldn't
liken the security of a drivechain to that of the
mainchain.</div>
</div>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>
--------------990D476ECC191B99853130EF--
|