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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6C784414
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 May 2017 05:54:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com
[209.85.216.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75378E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 May 2017 05:54:36 +0000 (UTC)
Received: by mail-qt0-f181.google.com with SMTP id t26so43111768qtg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 May 2017 22:54:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:reply-to:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=hE4RzKP1+9Rd9RdSv9ikC89bHOLVuY4fGl6tDd8mkzI=;
b=oJK4+lV32wMj5wzCRMPMRagtcLoSo6dglrZY3z1hJERM1+ttEYDFZxBpt9V8fXzcRc
yeWBkpRdwoKAn+aHUG50RnhP2Z6jCt/OzzVb56V1G8VC/JNVWX32XancAzexOtLxhhaA
4rMiFT4C7PETOYU3HmqlDMCma7SqnJiDhNra3QbjRCei3m8QGSKE5UXBNDlNh0tRdvRs
zIqaz65qNtUlX/nC3NhdIySywwLtHFaa63nF0DGxXwM/oj7l2sQXdPhOMHWwytCIRrVR
h1TL5uKHPBueeNN2Yk9FJNw2OkQH4nSSYe0l+i8yEvtaZyPMvtGUK9uljZvP1iuWr+lk
qEMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
:from:date:message-id:subject:to:cc;
bh=hE4RzKP1+9Rd9RdSv9ikC89bHOLVuY4fGl6tDd8mkzI=;
b=khZ8m/SP7BeZT+eRFhhO41TbkQlR55sCqfCB//CsDQIfp9+sq/6iQR/y/mEHtjMM6c
I9iFVa58d6CYPW0qIxNx3LWLVErJq8OaUEsbob/C3JTp52icn7pTSTbqEF/1vrQyrpUG
YYdUfcfsq7418wcZ2Ct0+Gk0OmJFz2Bd7aXXaxaS4v9b4TBeE1ZIcfc4vc3VD2N7khUZ
bBXJuNbKwqb+N34z8PcyKXIrwUKsMU819CYqhADHQIECoQlYRFpNMBQF9CYjI+P6SPQT
vNsSwX2NvHFJAn4WoO56j238iN7J3R1ZCnk5lxKgiZ7IKNkc7Dcm8Q7XEsmkscv9eTQB
qvAg==
X-Gm-Message-State: AODbwcA43C2sFoSuhtI5lZOLc7/unROJwADID4mU6THCIcMXAdrUArLa
hliLZmj1kqdgLEsQlfMNaGwfDAMx7w==
X-Received: by 10.237.53.70 with SMTP id b6mr16932136qte.142.1496037275642;
Sun, 28 May 2017 22:54:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.102 with HTTP; Sun, 28 May 2017 22:54:34 -0700 (PDT)
Received: by 10.237.48.102 with HTTP; Sun, 28 May 2017 22:54:34 -0700 (PDT)
Reply-To: erik@q32.com
In-Reply-To: <CAJowKgKFMXDE-yzEqYkY7c+80Mgn+iL9ZRNJbv9WhUBR32EvRg@mail.gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
<20170522133335.GA17194@fedora-23-dvm>
<CA+XQW1h22jmwq+qN69UgOhE0LZqmUDpnrmF0ZM-+2ZpoPsTrwQ@mail.gmail.com>
<20170528210757.GA19450@fedora-23-dvm>
<CAJowKgJjNaoWVc=QXfOqH3OdBPoKm3qkfUNpKV6oKLSRx_fD0g@mail.gmail.com>
<CAJowKgKFMXDE-yzEqYkY7c+80Mgn+iL9ZRNJbv9WhUBR32EvRg@mail.gmail.com>
From: Erik Aronesty <earonesty@gmail.com>
Date: Mon, 29 May 2017 01:54:34 -0400
Message-ID: <CAJowKgJDFrgvSvp8KW2oEDh+4xUTfV_HW0Ap2EHtgG7-1NY_Xg@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="001a11c0024662b0590550a35262"
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM autolearn=ham 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, 29 May 2017 06:02:24 +0000
Cc: Bitcoin Protocol Discussion <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, 29 May 2017 05:54:37 -0000
--001a11c0024662b0590550a35262
Content-Type: text/plain; charset="UTF-8"
Seems to me an obvious use case for drive chains are to have high speed
small transactions on a side chain, eventually cleared to the main chain.
Not sure why miners would want this to fail any more than any other side
chain, like Liquid or lightning.
On May 28, 2017 5:23 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> 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.
That's not at all true. If I'm a miner with a better capability than another
miner to prevent that theft, I have reasons to induce it to happen to give
me
political cover to pushing that other miner off the network.
This is a very similar problem to what we had with zeroconf double-spending,
where entities such as Coinbase tried to pay off miners to guarantee
something
that wasn't possible in a geninely decrentralized system: safe zeroconf
transactions.
> 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.
Why are you forcing miners to run this code at all?
Equally, you're opening up miners to huge political risks, as rejecting all
withdrawals is preventing users' from getting their money, which gives other
miners a rational for kicking those miners off of Bitcoin entirely.
> 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.
Why do you think this will be infrequent? Miners with a better ability to
validate the drivechain have every reason to make these events more
frequent.
> 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.
This is also a very dubious security model - I would argue that Bitcoin is
much
*more* valuable if miners do everything they can to ensure that drivechains
fail, given the huge risks involved. I would also argue that users should do
user-activated-soft-forks to ensure they fail.
By comparison, note Adam Back and my own efforts to ensure miners have a
smaller part in the ecosystem, with things like committed (encrypted)
transactions and my closed-seal-set/truth-list approach(1). We want to
involve
miners as little as possible in the consensus, not more.
I have to ask: What use-cases do you actually see for drivechains? Why can't
those use-cases be done in the much safer client-side validation fashion?
1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
--
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--001a11c0024662b0590550a35262
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Seems to me an obvious use case for drive chains are to h=
ave high speed small transactions on a side chain, eventually cleared to th=
e main chain.<div dir=3D"auto"><br></div><div dir=3D"auto">Not sure why min=
ers would want this to fail any more than any other side chain, like Liquid=
or lightning.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On May 28,=
2017 5:23 PM, "Peter Todd via bitcoin-dev" <<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.o=
rg</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 cla=
ss=3D"quoted-text">On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wr=
ote:<br>
> Surprisingly, this requirement (or, more precisely, this incentive) do=
es<br>
> not effect miners relative to each other. The incentive to upgrade is =
only<br>
> for the purpose of preventing a "theft" -- defined as: an im=
proper<br>
> withdrawal from a sidechain. It is not about miner revenues or the abi=
lity<br>
> to mine generally (or conduct BMM specifically). The costs of such a t=
heft<br>
> (decrease in market price, decrease in future transaction fee levels) =
would<br>
> be shared collectively by all future miners. Therefore, it would have =
no<br>
> effect on miners relative to each other.<br>
<br>
</div>That's not at all true. If I'm a miner with a better capabili=
ty than another<br>
miner to prevent that theft, I have reasons to induce it to happen to give =
me<br>
political cover to pushing that other miner off the network.<br>
<br>
This is a very similar problem to what we had with zeroconf double-spending=
,<br>
where entities such as Coinbase tried to pay off miners to guarantee someth=
ing<br>
that wasn't possible in a geninely decrentralized system: safe zeroconf=
<br>
transactions.<br>
<div class=3D"quoted-text"><br>
> Moreover, miners have other recourse if they are unable to run the nod=
e.<br>
> They can adopt a policy of simply rejecting ("downvoting") a=
ny withdrawals<br>
> that they don't understand. This would pause the withdraw process =
until<br>
> enough miners understand enough of what is going on to proceed with it=
.<br>
<br>
</div>Why are you forcing miners to run this code at all?<br>
<br>
Equally, you're opening up miners to huge political risks, as rejecting=
all<br>
withdrawals is preventing users' from getting their money, which gives =
other<br>
miners a rational for kicking those miners off of Bitcoin entirely.<br>
<div class=3D"quoted-text"><br>
> Finally, the point in dispute is a single, infrequent, true/false ques=
tion.<br>
> So miners may resort to semi-trusted methods to supplement their decis=
ion.<br>
> In other words, they can just ask people they trust, if the withdrawal=
is<br>
> correct or not. It is up to users to decide if they are comfortable wi=
th<br>
> these risks, if/when they decide to deposit to a sidechain.<br>
<br>
</div>Why do you think this will be infrequent? Miners with a better abilit=
y to<br>
validate the drivechain have every reason to make these events more frequen=
t.<br>
<div class=3D"quoted-text"><br>
> It is a matter of comparing the costs and benefits. Ignoring theft, th=
e<br>
> costs are near-zero, and the benefits are >0. Specifically, they ar=
e: a<br>
> higher BTC price and greater transaction fees. Theft is discouraged by=
<br>
> attempting to tie a theft to a loss of confidence in the miners, as<br=
>
> described in the spec/website.<br>
> In general the incentives are very similar to those of Bitcoin itself.=
<br>
<br>
</div>This is also a very dubious security model - I would argue that Bitco=
in is much<br>
*more* valuable if miners do everything they can to ensure that drivechains=
<br>
fail, given the huge risks involved. I would also argue that users should d=
o<br>
user-activated-soft-forks to ensure they fail.<br>
<br>
By comparison, note Adam Back and my own efforts to ensure miners have a<br=
>
smaller part in the ecosystem, with things like committed (encrypted)<br>
transactions and my closed-seal-set/truth-list approach(1). We want to invo=
lve<br>
miners as little as possible in the consensus, not more.<br>
<br>
I have to ask: What use-cases do you actually see for drivechains? Why can&=
#39;t<br>
those use-cases be done in the much safer client-side validation fashion?<b=
r>
<br>
1) <a href=3D"https://petertodd.org/2016/closed-seal-sets-and-truth-lists-f=
or-privacy" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/2016=
/<wbr>closed-seal-sets-and-truth-<wbr>lists-for-privacy</a><br>
<div class=3D"elided-text"><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>
</div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--001a11c0024662b0590550a35262--
|
