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
|
Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 80944899
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Mar 2017 15:59:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
[209.85.213.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E609123
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Mar 2017 15:59:22 +0000 (UTC)
Received: by mail-vk0-f43.google.com with SMTP id z204so96216047vkd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Mar 2017 08:59:22 -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=Skt5JdmvcyrpinC0nsq8KQRv08dqTJJXnoj6UT1B81o=;
b=qG4vm+Anr2Yjm7lENBKsw0SG/E9K6SMYOyDudhHzhgyJW0nThxDbP5w7HxW/ufgRKU
AUPweI4OLzacGNf+7qXWgLZpv2X0ulN8gr+k88X0BgftUPRkkkf6LRoS/KsJBubTgzil
nC+B53kW450OZACROLWpCYMh4+xFzv/o/OgkzDEBA0a7X18Fu3gokMumpo/1GG3+E9y8
WwwtxzIRB/m30f0VemhUSorKG0bbnKg0QonjcvFoNWxl/SfmjbWKJOPNsO2YBrwV6goE
NYsk1NY/hxWOqghMBgIhYPY0tloqDy4gvE6MMYGZUAM47TM4teOLE/SKDfe8XI1MchgL
aIqw==
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=Skt5JdmvcyrpinC0nsq8KQRv08dqTJJXnoj6UT1B81o=;
b=R2cvlJ+2eDFYCECbOc9dBfbniYRfAqiaPSdwsVIa+K8UwLH3Mb2F4oNmjB3+fWYEic
mOvWHkX40n3+Fe3AQEejd3FhsKRHzvj7IYi0Q7OuZG+a0wJaP6fSYLq/gsYBmcvKXCXV
twnnBQsuxY1DAkA5BxOyq/C+lTLd2Iqyq52cdfCILBqbPuzYtg0izZPZ/sqJQZW2OyZF
J4HTzoqneAo9rdfNOGUOLrXh9pW2PfMGtKrBlwX+gwrTzNacpoKWTxUWExlCBOTNanfp
UMCMm7h1ET5gm8QqUILl3CA8+fxgI2OkHTbGWnREucElehVldgbWY9kOnnuj13LDGWiF
eG9w==
X-Gm-Message-State: AFeK/H2a4gTG9FQtI3TXmWlI6I9fGLQ5rMe18KunNkHtDCPBputHO0WbIpAK707+kre5yb8DlM92EiLpC+ppjA==
X-Received: by 10.31.84.66 with SMTP id i63mr1622507vkb.157.1490975961255;
Fri, 31 Mar 2017 08:59:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Fri, 31 Mar 2017 08:59:19 -0700 (PDT)
In-Reply-To: <SINPR04MB1949BE883C69CFF1477AFAEFC2370@SINPR04MB1949.apcprd04.prod.outlook.com>
References: <CAEgR2PEG1UMqY0hzUH4YE_an=qOvQUgfXreSRsoMWfFWxG3Vqg@mail.gmail.com>
<CAFVRnyq9Qgw88RZqenjQTDZHEWeuNCdh12Dq7wCGZdu9ZuEN9w@mail.gmail.com>
<CAD1TkXvd4yLHZDAdMi78WwJ_siO1Vt7=DgYiBmP45ffVveuHBg@mail.gmail.com>
<SINPR04MB1949AB581C6870184445E0C4C2340@SINPR04MB1949.apcprd04.prod.outlook.com>
<CAD1TkXsj53JRYhqot2aHSQR+HEDKm7+6S5kGtaLYBCoc24PuWg@mail.gmail.com>
<SINPR04MB1949A0AF3AD33B4664417068C2370@SINPR04MB1949.apcprd04.prod.outlook.com>
<CAD1TkXtPZ7w+qYqr_hvyeq95aJ2ge1YYkoC1taDkzv1vEMKpog@mail.gmail.com>
<SINPR04MB1949BE883C69CFF1477AFAEFC2370@SINPR04MB1949.apcprd04.prod.outlook.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Fri, 31 Mar 2017 08:59:19 -0700
Message-ID: <CAD1TkXvXYX0f+jMMc41vhANuKfw-rNg9tUOG0bCS=T-YGYYjPw@mail.gmail.com>
To: Luv Khemani <luvb@hotmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
LOTS_OF_MONEY, 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: Fri, 31 Mar 2017 17:07:45 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
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: Fri, 31 Mar 2017 15:59:23 -0000
> Peter Todd has demonstrated this on mainstream SPV wallets,
> https://www.linkedin.com/pulse/peter-todds-fraud-proofs-talk-mit-bitcoin-expo-2016-mark-morris
Correct me if I'm wrong, but nothing possible if the client software
was electrum-like and used two independent sources for verification.
No?
> Do thought experiments and take it to the extremes where nobody runs a node, what can miners do now which they could not do before?
This and the next point are just reductio ad absurdem, since no one is
suggesting anything of the sort. Even in that situation, I can't think
of anything miners could do if clients used more than one independent
source for verification, ala electrum question above.
> Why don't exchanges run SPV nodes?
No one is suggesting anything like this. The cost of running a node
that could handle 300% of the 2015 worldwide nonbitcoin transaction
volume today would be a rounding error for most exchanges even if
prices didn't rise.
On Fri, Mar 31, 2017 at 1:19 AM, Luv Khemani <luvb@hotmail.com> wrote:
>> Err, no, that's what happens when you double click the Ethereum icon
>
> instead of the Bitcoin icon. Just because you run "Bitcoin SPV"
> instead of "Bitcoin Verify Everyone's Else's Crap" doesn't mean you're
> somehow going to get Ethereum payments. Your verification is just
> different and the risks that come along with that are different. It's
> only confusing if you make it confusing.
>
> This is false. You could get coins which don't even exist as long as a
> miner mined the invalid transaction.
> Peter Todd has demonstrated this on mainstream SPV wallets,
> https://www.linkedin.com/pulse/peter-todds-fraud-proofs-talk-mit-bitcoin-expo-2016-mark-morris
>
> The only reason SPV wallets do not accept ethereum payments is because of
> transaction/block format differences.
> SPV wallets have no clue what is a valid bitcoin, they trust miners fully.
>
> In the event of a hardfork, SPV wallets will blindly follow the longest
> chain.
>
>> If every block that is mined for them is deliberately empty because of
> an attacker, that's nonfunctional. You can use whatever semantics you
> want to describe that situation, but that's clearly what I meant.
>
> Not sure why you are bringing this up, this is not the case today nor does
> it have anything to do with blocksize.
>
>> As above, if someone operates Bitcoin in SPV mode they are not
> magically at risk of getting Dashcoins. They send and receive
> Bitcoins just like everyone else running Bitcoin software. There's no
> confusion about it and it doesn't have anything to do with hashrates
> of anyone.
>
> As mentioned earlier, you are at risk of receiving made up money.
> SPV has everything to do with hashrate, it trusts hashrate fully.
> Crafting a bitcoin transaction paying you money that i do not have is not
> difficult, as long as a miner mines a block with it, your SPV wallet will
> accept it.
>
>> The debate is a choice between nodes paying more to allow greater growth
>> and adoption,
> or nodes constraining adoption in favor of debatable security
> concerns.
>
> Onchain transactions are not the only way to use Bitcoin the currency.
> Trades you do on an exchange are not onchain, yet transacted with Bitcoin.
>
>> And even if there was, the software would choose it for you?
>
> People choose the software, not the other way round.
>
>> Yes you do, if the segment options are known (and if they aren't,
> running a node likely won't help you choose either, it will choose by
> accident and you'll have no idea). You would get to choose whose
> verifications to request/check from, and thus choose which segment to
> follow, if any.
>
> SPV does not decide, they follow longest chain.
> Centralised/Server based wallets follow the server they are connecting to.
> Full Nodes do not depend on a 3rd party to decide if the money received is
> valid.
>
>> Are you really this dense? If the cost of on-chain transactions
> rises, numerous use cases get killed off. At $0.10 per tx you
> probably won't buy in-game digital microtransactions with it, but you
> might buy coffee with it. At $1 per tx, you probably won't buy coffee
> with it but you might pay your ISP bill with it. At $20 per tx, you
> probably won't pay your ISP bill with it, but you might pay your rent.
> At $300 per tx you probably won't use it for anything, but a company
> purchasing goods from China might. At $4000 per tx that company
> probably won't use it, but international funds settlement for
> million-dollar transactions might use it.
>> At each fee step along the way you kill of hundreds or thousands of
> possible uses of Bitcoin. Killing those off means fewer people will
> use it, so they will use something else instead.
>
> No need to get personal.
> As mentioned earlier, all these low value transactions can happen offchain.
> None of the use cases will be killed off. We have sub dollar trades
> happening on exchanges offchain.
>
>> The average person doesn't need that level of security.
>
> Precisely why they do not need to be on-chain.
>
> It is clear to me that you have not yet grasped Bitcoin's security model,
> especially the role Full-Nodes play in it.
> Id suggest you do some more reading up and thinking about it.
> Do thought experiments and take it to the extremes where nobody runs a node,
> what can miners do now which they could not do before?
> Why don't exchanges run SPV nodes?
>
> Further correspondence will not be fruitful until you grasp this.
>
>
>
> On Thu, Mar 30, 2017 at 9:21 PM, Luv Khemani <luvb@hotmail.com> wrote:
>>
>> > Nodes don't do politics. People do, and politics is a lot larger with a
>> > lot more moving parts than just node operation.
>>
>>
>> Node operation is making a stand on what money you will accept.
>>
>> Ie Your local store will only accept US Dollars and not Japanese Yen.
>> Without being able to run a node, you have no way to independently determine
>> what you are receiving, you could be paid Zimbawe Dollars and wouldn't know
>> any better.
>>
>>
>> > Full nodes protect from nothing if the chain they attempt to use is
>> > nonfunctional.
>>
>> This is highly subjective.
>> Just because it is nonfunctional to you, does not mean it is nonfunctional
>> to existing users.
>>
>> > This power is far more complicated than just nodes.
>>
>> I never implied otherwise.
>>
>> > You're implying that node operation == political participation.
>>
>> Ofcourse it is. Try paying for my goods using BU/Ehtereum/Dash/etc.. or a
>> Bitcoin forked with inflation, you will not get any goods regardless of how
>> much hashrate those coins have.
>>
>> > Miners being distributed in enough countries and locations to avoid any
>> > single outside attacker group from having enough leverage to prevent
>> > transaction inclusion, and miners also having enough
>> > incentives(philosophical or economic) to refuse to collude towards
>> > transaction exclusion.
>>
>> It's good that you see the importance of this. You should also take into
>> consideration the number of independent mining entities it takes to achieve
>> 51% hashrate. It will be of little use to have thousands on independent
>> miners/pools if 3 large pools make up 51% of hash rate and collude to
>> attack the network.
>>
>> > If users refused to get on board, exchanges would follow users. If
>> > miners refused to get on board, the attempt would be equally dead in the
>> > water. It would require a majority of users, businesses and miners to
>> > change the limit;
>>
>> > Nodes have absolutely no say in the matter if they can't segment the
>> > network, and even if they could their impact could be repaired. Users !=
>> > Nodes.
>>
>> Nodes define which network they want to follow. Without a Node, you don't
>> even get to decide which segement you are on. Either miners decide( for SPV
>> wallets) or your wallet's server decides(Node). You have no control without
>> a
>>
>> >> What makes transactions irreversible
>> >Nodes have absolutely no say in the matter, they always follow the
>> > longest chain unless a hardfork was applied.
>>
>> My bad here, hashpower decides order. This is the sole reason we have
>> mining, to order transactions.
>>
>> > Mutual destruction comes from the market forces on the exchanges, and
>> > they could give a rats ass whether you run a node or not.
>>
>> Ability to run a node and validate rules => Confidence in currency =>
>> Higher demand => Higher exchange rate
>>
>> I would not be holding any Bitcoins if it was unfeasible for me to run a
>> Node and instead had to trust some 3rd party that the currency was not being
>> inflated/censored. Bitcoin has value because of it's trustless properties.
>> Otherwise, there is no difference between cryptocurrencies and fiat.
>>
>> > Literally the only reason we have 10s of billions of dollars of value is
>> > because speculation, which includes nearly all Bitcoin users/holders and
>> > almost all businesses and miners. While Bitcoin borrows useful features
>> > from gold, it has more possible uses, including uses that were never
>> > possible before Bitcoin existed, and we believe that gives it huge
>> > potential.
>> > The ability of other systems to do transactions, like visa or cash, come
>> > with the limitations of those systems. Bitcoin was designed to break those
>> > limitations and STILL provide the ability to do transactions. We might all
>> > agree Bitcoin isn't going to ever solve the microtransaction problem, at
>> > least not on-chain, but saying Bitcoin doesn't need utility is just foolish.
>> > Gold doesn't need utility, gold has 4,000 years of history. We don't.
>> > There's no reason those blocksize increases can't be tied to or related
>> > to usage increases
>>
>> Blocksize has nothing to do with utility, only cost of on-chain
>> transactions.
>> OTOH increasing the blocksize has alot to do with introducing the very
>> limitations that Visa/Cash have.
>> Why would you risk destroying Bitcoin's primary proposition (removing
>> limitations of Cash/Visa) for insignificant capacity increase?
>>
>> > That's like saying it would be better to do nothing so someone else
>> > solves our problem for us than it would be for us to do what we can to solve
>> > it ourselves. Someone else solving our problem may very well be Ethereum,
>> > and "solving it for us" is pulling Bitcoin investments, users and nodes away
>> > into Ethereum.
>>
>> Who says nothing is being done? Segwit, Lightning, pre-loaded wallets like
>> Coinbase are all solutions.
>>
>>
>>
>>
>> On Thu, Mar 30, 2017 at 12:11 AM, Luv Khemani <luvb@hotmail.com> wrote:
>>>
>>>
>>> >> If home users are not running their own full nodes, then home users
>>> >> have to trust and rely on other, more powerful nodes to represent them. Of
>>> >> course, the more powerful nodes, simply by nature of having more power, are
>>> >> going to have different opinions and objectives from the users.
>>>
>>> >I think you're conflating mining with node operation here. Node users
>>> > only power is to block the propagation of certain things. Since miners also
>>> > have a node endpoint, they can cut the node users out of the equation by
>>> > linking with eachother directly - something they already do out of
>>> > practicality for propagation. Node users do not have the power to arbitrate
>>> > consensus, that is why we have blocks and PoW.
>>>
>>> You are only looking at technical aspects and missing the political
>>> aspect.
>>>
>>> Node users decide what a Bitcoin is. It matters not how much hash power
>>> is behind a inflationary supply chain fork, full nodes protect the user from
>>> the change of any properties of Bitcoin which they do not agree with. The
>>> ability to retain this power for users is of prime importance and is
>>> arguably what gives Bitcoin most of it's value. Any increase in the cost to
>>> run a full node is an increase in cost to maintain monetary sovereignty. The
>>> ability for a user to run a node is what keeps the miners honest and
>>> prevents them from rewriting any of Bitcoin's rules.
>>>
>>> If it's still difficult to grasp the above paragraph, ask yourself the
>>> following questions,
>>> - What makes Bitcoin uncensorable
>>> - What gives confidence that the 21 million limit will be upheld
>>> - What makes transactions irreversible
>>> - If hashpower was king as you make it to be, why havn't miners making up
>>> majority hashrate who want bigger blocks been able to change the blocksize?
>>>
>>> The market is not storing 10s of billions of dollars in Bitcoin despite
>>> all it's risks because it is useful for everyday transactions, that is a
>>> solved problem in every part of the world (Cash/Visa/etc..).
>>>
>>> Having said that, i fully empathise with your view that increasing
>>> transaction fees might allow competitors to gain marketshare for low value
>>> use cases. By all means, we should look into ways of solving the problem.
>>> But all these debates around blocksize is a total waste of time. Even if we
>>> fork to 2MB, 5MB, 10MB. It is irrelevant in the larger picture, transaction
>>> capacity will still be too low for global usage in the medium-long term. The
>>> additional capacity from blocksize increases are linear improvements with
>>> very large systemic costs compared with the userbase and usage which is
>>> growing exponentially. Lightning potentially offers a couple or orders of
>>> magnitude of scaling and will make blocksize a non-issue for years to come.
>>> Even if it fails to live up to the hype, you should not discount the market
>>> innovating solutions when there is money to be made.
>>>
>>
|