summaryrefslogtreecommitdiff
path: root/c1/3be3ce085634cc6f9b1e9ab5fe6ad5962195c4
blob: 8b553a7aa87fb2359fad8c87d36e289ab6c5c4cf (plain)
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
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 C3776A7C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Jul 2017 00:21:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com
	[209.85.220.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27EC986
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Jul 2017 00:21:08 +0000 (UTC)
Received: by mail-qk0-f181.google.com with SMTP id v143so6928040qkb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Jul 2017 17:21:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:to:cc:references:from:message-id:date:user-agent
	:mime-version:in-reply-to:content-language;
	bh=7sIS8Ez9umhdbV7zUzvoSPvoXU0Q3RoIuErDfEEnXbA=;
	b=nvT6cn39WA8W4yWtnhFibMvQtHWqYM1VbiZ7sKYIXyOzsBtpyeBL4K1kASiyGyMli1
	/Uw+LaGZCeOHHSc5CUu2AFI3t14OyZeTPOZHUR1nwRVKQvvP4GQkX/cg9jIMOb29cDoR
	d3RoHacqLyJHj15Q34Skcm33E1FOcvQaOc+ebRs5G4hXhhOlmbU587xOhiHm0y96DaBh
	R9NELRx1SrIFh2sQaDsgMSTOjMcqFnV4IPgSbcjKBcfDZTedW1ZFriojI/4PMeWdpIuz
	dgiwG0/EYBeCm2Y4Riovdvrq3LhiwGYw2qUwoT8RRkRbfLAD46lWFRRowRrKOgQoHZ6n
	mBsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:cc:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-language;
	bh=7sIS8Ez9umhdbV7zUzvoSPvoXU0Q3RoIuErDfEEnXbA=;
	b=n9Wn82Q1SSYDH7LbYKem/NYXGk7Xfrxmt944v+EJ4ROb8rmy8y1mFHY7ogXpCeu0+S
	jYPn757JtGHMJYxCcb5aMPftFJCWfa4jeJSi7jctZeD+T6F+vmMKA1UjK4NI9B0EcyLv
	65rfQk59siXQUuJSV8HGSFndnw1ooMS8zMWjHoWSOie3klvHKJdyWVpfR/jVF7DuihsU
	PD0Y0fGEFm0cb1EG/8tkm96/cuJSB+gDI/3PZh8vjKGMVKrnN0ESHWtbLEXam5uJYUaG
	Qqc36+JcSw25l3gJbVo8GE0O2BHKpEvlqHYDnKHFHHb+t9ZUvLfsx469y3XnRknQYiRz
	GTUA==
X-Gm-Message-State: AIVw113WqfVqr63bvNPy9KF55SrzVdKRp2KS15hk9j5VcY6YfAI4JBpj
	oMB7DIO0DEW1PA==
X-Received: by 10.55.142.67 with SMTP id q64mr3010056qkd.99.1499818867366;
	Tue, 11 Jul 2017 17:21:07 -0700 (PDT)
Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net.
	[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
	l15sm661098qtb.51.2017.07.11.17.21.06
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 11 Jul 2017 17:21:06 -0700 (PDT)
To: Tao Effect <contact@taoeffect.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
	<08078429-089f-9315-2f76-a08121c5378c@gmail.com>
	<D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <a9ad2dd0-a949-643f-9375-a95015020066@gmail.com>
Date: Tue, 11 Jul 2017 20:21:09 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
	Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com>
Content-Type: multipart/alternative;
	boundary="------------70E6B8F1939101E9A2607FCD"
Content-Language: en-US
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
X-Mailman-Approved-At: Wed, 12 Jul 2017 00:37:38 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap
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, 12 Jul 2017 00:21:08 -0000

This is a multi-part message in MIME format.
--------------70E6B8F1939101E9A2607FCD
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 7/11/2017 7:12 PM, Tao Effect wrote:
> Paul,
>
> There is a difference between replying to an email, and addressing the
> issues that were brought up in it.
>
> I did read your reply, and I chose not to respond to it because it did
> not address anything I said.

In that case you should clarify, which is exactly what you are doing now.

>
> Here's an example:
>
>> It would not be accurate to say that miners have "total" control. Miners
>> do control the destination of withdrawals, but they do not control the
>> withdrawal-duration nor the withdrawal-frequency.
>>
>> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
>> theft, but they can not change the fact that their malfeasance will be
>> [a] obvious, and [b] on display for a long period of time.
>
> Here, you admit that the security of the sidechains allows miners to
> steal bitcoins, something they cannot do currently.

If that were the case, then DC would need to be a hard fork. It so
happens that it is *not* the case -- if users choose to deposit to an
anyone-can-spend output, then miners can take the Bitcoins, which *is*
something that miners can do currently.

>
> You next tried to equate three different types of theft, what you
> called "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:
>
>> I do not think that any of the three stands out as being categorically
>> worse than the others
>
> To anyone who understands bitcoin, there is a very clear,
> unmistakeable difference between double-spending ("Classic Theft"),
> and *ownership* of the private key controlling the bitcoins.
>
> Similarly, to anyone who understands bitcoin, there is also a very
> clear, unmistakeable difference between censorship ("Channel Theft"),
> and *ownership* of the private key controlling the bitcoins.

I am not sure what you are disagreeing with. The three thefts involve
different attacker resources and behaviors, and in that way they are
different. But in all three cases the user has lost the BTC they would
have otherwise owned, and in that way they are not different.

And users are under no obligation to use DC, just as they are under no
obligation to open a LN channel (or use P2SH, etc).

>
> I am not sure how else to respond to that email, given that none of
> the issues were really addressed.
Other than your complaint about being freely given the option to upgrade
to software which will give you the option to freely opt-in to a
different security model that you can otherwise ignore, feel free to
bring up any other issues you feel need to be addressed.

> Drivechain is an unmistakeable weakening of Bitcoin's security
> guarantees. This you have not denied.
That is false. I do deny it. Per the logic of the soft fork, the
security properties are at best unchanged (as I think almost everyone
else on this list would acknowledge). And even for those users who
opt-in, I feel the risk of theft is low, as I explain in the very
passage you've quoted above.

And please try to avoid going off-topic -- this is supposed to be about
the idea of a new roadmap.

Paul

--------------70E6B8F1939101E9A2607FCD
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 7/11/2017 7:12 PM, Tao Effect wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com">
      Paul,
      <div class=""><br class="">
      </div>
      <div class="">There is a difference between replying to an email,
        and addressing the issues that were brought up in it.</div>
      <div class=""><br class="">
      </div>
      <div class="">I did read your reply, and I chose not to respond to
        it because it did not address anything I said.</div>
    </blockquote>
    <br>
    In that case you should clarify, which is exactly what you are doing
    now.<br>
    <br>
    <blockquote type="cite"
      cite="mid:D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com">
      <div class=""><br class="">
      </div>
      <div class="">Here's an example:</div>
      <div class=""><br class="">
      </div>
      <blockquote type="cite" class="">It would not be accurate to say
        that miners have "total" control. Miners<br class="">
        do control the destination of withdrawals, but they do not
        control the<br class="">
        withdrawal-duration nor the withdrawal-frequency.<br class="">
        <br class="">
        So, if miners wish to 'steal' from a sidechain, they _can_
        initiate a<br class="">
        theft, but they can not change the fact that their malfeasance
        will be<br class="">
        <div class="">
          <div class="">[a] obvious, and [b] on display for a long
            period of time.</div>
        </div>
      </blockquote>
      <div class="">
        <div class=""><br class="webkit-block-placeholder">
        </div>
        <div class="">Here, you admit that the security of the
          sidechains allows miners to steal bitcoins, something they
          cannot do currently.</div>
      </div>
    </blockquote>
    <br>
    If that were the case, then DC would need to be a hard fork. It so
    happens that it is *not* the case -- if users choose to deposit to
    an anyone-can-spend output, then miners can take the Bitcoins, which
    *is* something that miners can do currently.<br>
    <br>
    <blockquote type="cite"
      cite="mid:D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com">
      <div class="">
        <div class=""><br class="">
        </div>
        <div class="">You next tried to equate three different types of
          theft, what you called "Classic Theft", "Channel Theft", and
          "Drivechain Theft", saying:</div>
        <div class=""><br class="">
        </div>
        <blockquote type="cite" class="">
          <div class="">I do not think that any of the three stands out
            as being categorically</div>
          <div class="">worse than the others</div>
        </blockquote>
        <div class=""><br class="webkit-block-placeholder">
        </div>
        <div class="">To anyone who understands bitcoin, there is a very
          clear, unmistakeable difference between double-spending
          ("Classic Theft"), and *ownership* of the private key
          controlling the bitcoins.</div>
        <div class=""><br class="">
        </div>
        <div class="">Similarly, to anyone who understands bitcoin,
          there is also a very clear, unmistakeable difference between
          censorship ("Channel Theft"), and *ownership* of the private
          key controlling the bitcoins.<br>
        </div>
      </div>
    </blockquote>
    <br>
    I am not sure what you are disagreeing with. The three thefts
    involve different attacker resources and behaviors, and in that way
    they are different. But in all three cases the user has lost the BTC
    they would have otherwise owned, and in that way they are not
    different.<br>
    <br>
    And users are under no obligation to use DC, just as they are under
    no obligation to open a LN channel (or use P2SH, etc).<br>
    <br>
    <blockquote type="cite"
      cite="mid:D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com">
      <div class="">
        <div class=""><br class="">
        </div>
        <div class="">I am not sure how else to respond to that email,
          given that none of the issues were really addressed.<br>
        </div>
      </div>
    </blockquote>
    Other than your complaint about being freely given the option to
    upgrade to software which will give you the option to freely opt-in
    to a different security model that you can otherwise ignore, feel
    free to bring up any other issues you feel need to be addressed.<br>
    <br>
    <blockquote type="cite"
      cite="mid:D30D8852-EFF4-4AB3-9B97-53D622A1440A@taoeffect.com">
      <div class="">
        <div class="">Drivechain is an unmistakeable weakening of
          Bitcoin's security guarantees. This you have not denied.</div>
      </div>
    </blockquote>
    That is false. I do deny it. Per the logic of the soft fork, the
    security properties are at best unchanged (as I think almost
    everyone else on this list would acknowledge). And even for those
    users who opt-in, I feel the risk of theft is low, as I explain in
    the very passage you've quoted above.<br>
    <br>
    And please try to avoid going off-topic -- this is supposed to be
    about the idea of a new roadmap.<br>
    <br>
    Paul
  </body>
</html>

--------------70E6B8F1939101E9A2607FCD--