summaryrefslogtreecommitdiff
path: root/53/e4fe94acd6177b7354e4297f749df8269f080f
blob: 54a9bf5a1ceab1b39a9d8e96f968c1c5ea1f67c0 (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
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
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DBB299C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 09:38:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
	[209.85.212.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 09F17F7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 09:38:01 +0000 (UTC)
Received: by wicmv11 with SMTP id mv11so13550329wic.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 02:38:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=GPoAyvH6+xaULZFAC0btlydj44doBlZ65DHO6QJg1xs=;
	b=LZ614hw2D7bnNyezSi0ZjKf0rv0G/8lN2dzZKrpaovjP6hM1zcOUDLTv6+SayCJ40w
	PzgNm097LPX+lX3La5LDpPzD1iM5ZXW2ExoTdEm2gNcfm5Xevz6eJHdyEkssJycDTaSq
	8WvUg5Dj6UPsPnSr/D4SPEaFmL8VXdaDeN+SLmAkVpeKx6xsw86apy8Xn2L8zQNOIStg
	oKkmZclt/ZDfbPeMkd3+i6QyC3ULrIHj3Vc5CBmdP+Toq8yErpOFLuAdGMkRStcNA/PB
	BY8tgOvv6H9ehLaoZ93kmAAjmgG33M4SgM4tB69LzDQYMeh/vrnIcAfD/hyi5XMk3RBL
	CvPg==
X-Gm-Message-State: ALoCoQkIy7q0NirW4vFrH49S2hNtnYiqgSmtPYK4AJWoGwQfGNUh1w1j+hbkY2WUZ0zpJT6L3ezg
MIME-Version: 1.0
X-Received: by 10.181.13.169 with SMTP id ez9mr4082550wid.92.1438249080550;
	Thu, 30 Jul 2015 02:38:00 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 02:38:00 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 02:38:00 -0700 (PDT)
In-Reply-To: <55B9EB68.9020703@mail.bihthai.net>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
	<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
	<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
	<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
	<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>
	<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>
	<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
	<55B94FAD.7040205@mail.bihthai.net>
	<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
	<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
	<55B9EB68.9020703@mail.bihthai.net>
Date: Thu, 30 Jul 2015 11:38:00 +0200
Message-ID: <CABm2gDpJjimF486qca=JGQ0h6k9qzike-hjVUU2NhOuCzbBkow@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: venzen@mail.bihthai.net
Content-Type: multipart/alternative; boundary=f46d0438eb9f8b8e18051c147572
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham 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] Why Satoshi's temporary anti-spam measure
	isn'ttemporary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 30 Jul 2015 09:38:04 -0000

--f46d0438eb9f8b8e18051c147572
Content-Type: text/plain; charset=UTF-8

It is important ro note that even if lightning was never developed, the
block size remains at 1 MB forever and fees rise to 10 usd per transaction,
such "high fees" are still extremely competitive with non-decentralized
payment systems that have proportional fees. For example, 10 usd is still
lower than 1% when you are moving more than 1000 usd. I know, this doesn't
work for micro-transactions, but I don't think Bitcoin can be useful for
micro-transactions in the long term unless something like lightning payment
channels is deployed. Until we accept the second fact, it will be very hard
to discuss any projection of future usage. I think that believing that all
the transactions of the entire world population can be made in-chain while
keeping bitcoin decentralized is incredibly naive. Not even nasdaq has that
capacity (and if full node's require nasdaq's capacity, I don't think we
can talk about a decentralized system anymore).
On Jul 30, 2015 11:16 AM, "Venzen Khaosan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Adam,
>
> - From your explanation it is evident that fast, cheap bitcoin
> transactions are possible. It is encouraging that Bitcoin _can_ indeed
> compete with Visa, Paypal, et al. via Layer 2 protocols such as Lightning.
>
> The youtube interview with you and Greg re: Lightning requires some
> concentration and I'll have to watch it another couple of times to
> better grasp everything that is explained about the protocol and its
> interaction with Bitcoin.
>
> Thank you for your considered and informative response, else Raystonn
> and I might have gotten in an unnecessary scrap about fees, economics
> and what not.
>
> regards,
> Venzen Khaosan
>
>
>
> On 07/30/2015 10:49 AM, Adam Back wrote:
> > I dont think people consider other blockchains as a competitive
> > threat.  A PoW-blockchain is a largely singleton data structure
> > for security reasons (single highest hashrate), it is hard for an
> > alternative chain to bootstrap or provide meaningful security.
> > Secondly the world largely lacks expertise to maintain a blockchain
> > to bitcoin's security level, perhaps you can see a hint of this in
> > the recently disclosed security vulnerability by Pieter Wuille and
> > Gregory Maxwell.  Calls to this as an argument are not resonating
> > and probably not helping your argument.  Bitcoin has security
> > properties, and a competing system cant achieve better properties
> > by bypassing security, any blockchain faces the same fundamental
> > security / decentralisation limitations.
> >
> > Secondly Bitcoin can obviously compete with itself with different
> > parameters and defacto *does* today.  I think it is a safe
> > estimate that > 99% of Bitcoin transactions right now are happening
> > in Bitcoin related systems with various degrees of audit,
> > reconciliation, provable reserves etc.  I think we can expect this
> > to continue and become more secure via more reconciliation, and
> > longer term via lightning or Bitcoin sidechains with different
> > parameters.  It is a different story to have a single central
> > system (Bitcoin with parameters changed to the point of
> > centralisation failure) vs having multiple choices, because some
> > transactions can more easily use relatively centralised systems (eg
> > micropayments), and more interestingly the combination of a secure
> > and decentralised layer 1 plus choices of less decentralised layer
> > 2 options, can be interesting because the layer 2 is provided cover
> > from attack.  There is less to be gained by attacking relatively
> > centralised layer 2 because any payments at risk of policy abuse
> > (which is typically a small subset) can easily switch to layer 1.
> > That in itself makes layer 2 transactions also less susceptible to
> > policy abuse.  Further lightning it appears from work so far should
> > add significant scale while retaining trustlessness and a good
> > degree of decentralisation.
> >
> > Finally you seem to be focusing on "artificial" limits where that
> > is not the issue under consideration.  The limits are technical
> > and relating to decentralisation and security.  I wont go over them
> > again as this topic has been covered many times in recent months.
> > Any chain that tried to go to extreme parameters (very low block
> > intervals, or very large blocksizes) would have the same
> > decentralisation problems as Bitcoin would if it did the same
> > thing.  There are a number of alt coins that have failed as a
> > result of poor parameter choices, there are inherent security
> > limits.
> >
> > Adam
> >
> > ps Etiquette note for yourself and others: please dont be
> > repetitive or attempt to be forceful.  Many people have spent many
> > years understanding this very complex system, from my own
> > experience it is rare indeed to think of an entirely new concept or
> > analysis, that hasnt' been long considered and put to bed 3 or 4
> > years ago. Thoughtful polite and constructive comments are welcome
> > but I recommend to not start from an assumption that you have a
> > clear and better insight than the entire technical community,
> > because I have to say from my own experience that is very rarely
> > the case.  It can be useful to test theories on #bitcoin IRC
> > channel to find out what has been already concluded, find the
> > references and avoid having to have that hashed out on this list
> > which is trying to be focussed on technical solutions.
> >
> >
> > On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>> Cheapest way to send value? Is this what Bitcoin is trying to
> >>> do? So all of the smart contract, programmable money, consensus
> >>> coding and tremendous developer effort is bent to the consumer
> >>> demand for cheaper fees. Surely thou jests!
> >>
> >>
> >> These other features can be replicated into any alternative
> >> blockchain, including those with lower fees.  In the open-source
> >> world of cryptocurrency, no feature will remain a value-add for
> >> very long after it has been identified to be such.  Anything
> >> adding value will quickly be absorbed into competing alternative
> >> blockchains.  That will leave economic policy as the
> >> distinguishing factor.
> >>
> >>> ... it is not the case ... that reluctance to concede blocksize
> >>> is an attempt to constrain capacity. Greg Maxwell thoroughly
> >>> explained in this thread that the protocol's current state of
> >>> development relies on  blocksize for security and, ultimately,
> >>> as a means of protecting its degree of decentralization.
> >>
> >>
> >> A slow or lack of increase to maximum transaction rate will cause
> >> pressure on fees.  Whether this is the desired goal is not
> >> relevant.  Everyone has agreed this will be the outcome.  As to a
> >> smaller block size being needed for additional decentralization,
> >> one must simply ask how much we are all willing to pay for that
> >> additional decentralization.  It is likely that the benefit
> >> thereto will have to be demonstrated by some power attacking and
> >> destroying a less decentralized currency before the benefit of
> >> this feature is given monetary value by the market.  Until then,
> >> value will bleed to the network with the least friction, because
> >> it will have the greatest ability to grow its network effect.
> >> That means the blockchain with adequate features and cheapest
> >> fees will eventually have the largest market share.
> >>
> >>
> >> -----Original Message----- From: Venzen Khaosan Sent: Wednesday,
> >> July 29, 2015 3:11 PM To: Raystonn . Cc:
> >> bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev]
> >> Why Satoshi's temporary anti-spam measure isn'ttemporary
> >>
> > Raystonn, I'm aware that you're addressing your question to Greg
> > Maxwell, however a point you keep stating as fact calls for
> > reference:
> >
> > On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: [snip]
> >>>>
> >>>> How do you plan to address the bleeding of value from Bitcoin
> >>>> to alternative lower-fee blockchains created by the
> >>>> artificially-high bitcoin transaction fees when users begin
> >>>> looking for the cheapest way to send value?
> >
> > Cheapest way to send value? Is this what Bitcoin is trying to do?
> > So all of the smart contract, programmable money, consensus coding
> > and tremendous developer effort is bent to the consumer demand for
> > cheaper fees. Surely thou jests!
> >
> >>>> Modern economic study has shown that liquidity moves to the
> >>>> location of least friction.
> >
> > Modern economic study? Can you please provide a link or reference
> > to the study you are referring to.
> >
> > "liquidity moves to the location of least friction"
> >
> > This sounds like "econo-speak" and makes no sense. The definition
> > of Liquidity is the degree to which an asset/security can be bought
> > or sold in the market without affecting the price.
> >
> > That is why bitcoin is said to have low liquidity: buying or
> > selling only 100 BTC visibly affects the exchange price. You
> > probably mean "people like cheap fees", which is true, but as
> > others have said, because of Bitcoin's powerful features, they are
> > willing to pay higher fees and wait longer for transactions to
> > execute.
> >
> > As for your public cross-examination of Greg Maxwell, your case
> > seems to  be made on the assumption that limiting the size of the
> > blockchain is an attempt to artificially raise tx fees, but it is
> > not the case (as you and others repeatedly argue) that reluctance
> > to concede blocksize is an attempt to constrain capacity. Greg
> > Maxwell thoroughly explained in this thread that the protocol's
> > current state of development relies on  blocksize for security and,
> > ultimately, as a means of protecting its degree of
> > decentralization.
> >
> > Surely, this is an obvious concern even for those who are
> > campaigning for the hare-brained ideal of making Bitcoin a "faster,
> > cheaper alternative" to visa or paypal? If we lose
> > decentralization, we lose the whole thing, right? Incorrect or
> > correct?
> >> _______________________________________________ bitcoin-dev
> >> mailing list bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVuetlAAoJEGwAhlQc8H1m2TkH/jKx7V9vCZbOjbxAlfjnR0ai
> +QDxMm0K0sL/MlsLVm0FAHwGiKhYJnEeXiZJlXu0eiUz35JALDMtSQiVbQzcHAc2
> GvyW3tWUh6+uSfYhsnImQXxlDgCUKIgZvtTM900OWcGXZeLU3W5UdUK5+ietHK0/
> 1HbZgcljqke+nSsH2aCagd/iNdwCIUcfapsUgB6iPWtZQfLg6SHi8CjbG/Th5Na7
> fpA5yJlO4N+Q2JpOVId/LfC7loDCEZtPtYA5NZAsDcEcSIXUycCoGL8LNMIFGJNe
> Ko2RNqGeIkb/x8T2USxlkrNUZx/CCF201MMClPLC/LXX1bEMDvO8F0m1TBR1ptg=
> =106o
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--f46d0438eb9f8b8e18051c147572
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">It is important ro note that even if lightning was never dev=
eloped, the block size remains at 1 MB forever and fees rise to 10 usd per =
transaction, such &quot;high fees&quot; are still extremely competitive wit=
h non-decentralized payment systems that have proportional fees. For exampl=
e, 10 usd is still lower than 1% when you are moving more than 1000 usd. I =
know, this doesn&#39;t work for micro-transactions, but I don&#39;t think B=
itcoin can be useful for micro-transactions in the long term unless somethi=
ng like lightning payment channels is deployed. Until we accept the second =
fact, it will be very hard to discuss any projection of future usage. I thi=
nk that believing that all the transactions of the entire world population =
can be made in-chain while keeping bitcoin decentralized is incredibly naiv=
e. Not even nasdaq has that capacity (and if full node&#39;s require nasdaq=
&#39;s capacity, I don&#39;t think we can talk about a decentralized system=
 anymore).</p>
<div class=3D"gmail_quote">On Jul 30, 2015 11:16 AM, &quot;Venzen Khaosan v=
ia bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attr=
ibution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<=
br>
Hash: SHA1<br>
<br>
Adam,<br>
<br>
- From your explanation it is evident that fast, cheap bitcoin<br>
transactions are possible. It is encouraging that Bitcoin _can_ indeed<br>
compete with Visa, Paypal, et al. via Layer 2 protocols such as Lightning.<=
br>
<br>
The youtube interview with you and Greg re: Lightning requires some<br>
concentration and I&#39;ll have to watch it another couple of times to<br>
better grasp everything that is explained about the protocol and its<br>
interaction with Bitcoin.<br>
<br>
Thank you for your considered and informative response, else Raystonn<br>
and I might have gotten in an unnecessary scrap about fees, economics<br>
and what not.<br>
<br>
regards,<br>
Venzen Khaosan<br>
<br>
<br>
<br>
On 07/30/2015 10:49 AM, Adam Back wrote:<br>
&gt; I dont think people consider other blockchains as a competitive<br>
&gt; threat.=C2=A0 A PoW-blockchain is a largely singleton data structure<b=
r>
&gt; for security reasons (single highest hashrate), it is hard for an<br>
&gt; alternative chain to bootstrap or provide meaningful security.<br>
&gt; Secondly the world largely lacks expertise to maintain a blockchain<br=
>
&gt; to bitcoin&#39;s security level, perhaps you can see a hint of this in=
<br>
&gt; the recently disclosed security vulnerability by Pieter Wuille and<br>
&gt; Gregory Maxwell.=C2=A0 Calls to this as an argument are not resonating=
<br>
&gt; and probably not helping your argument.=C2=A0 Bitcoin has security<br>
&gt; properties, and a competing system cant achieve better properties<br>
&gt; by bypassing security, any blockchain faces the same fundamental<br>
&gt; security / decentralisation limitations.<br>
&gt;<br>
&gt; Secondly Bitcoin can obviously compete with itself with different<br>
&gt; parameters and defacto *does* today.=C2=A0 I think it is a safe<br>
&gt; estimate that &gt; 99% of Bitcoin transactions right now are happening=
<br>
&gt; in Bitcoin related systems with various degrees of audit,<br>
&gt; reconciliation, provable reserves etc.=C2=A0 I think we can expect thi=
s<br>
&gt; to continue and become more secure via more reconciliation, and<br>
&gt; longer term via lightning or Bitcoin sidechains with different<br>
&gt; parameters.=C2=A0 It is a different story to have a single central<br>
&gt; system (Bitcoin with parameters changed to the point of<br>
&gt; centralisation failure) vs having multiple choices, because some<br>
&gt; transactions can more easily use relatively centralised systems (eg<br=
>
&gt; micropayments), and more interestingly the combination of a secure<br>
&gt; and decentralised layer 1 plus choices of less decentralised layer<br>
&gt; 2 options, can be interesting because the layer 2 is provided cover<br=
>
&gt; from attack.=C2=A0 There is less to be gained by attacking relatively<=
br>
&gt; centralised layer 2 because any payments at risk of policy abuse<br>
&gt; (which is typically a small subset) can easily switch to layer 1.<br>
&gt; That in itself makes layer 2 transactions also less susceptible to<br>
&gt; policy abuse.=C2=A0 Further lightning it appears from work so far shou=
ld<br>
&gt; add significant scale while retaining trustlessness and a good<br>
&gt; degree of decentralisation.<br>
&gt;<br>
&gt; Finally you seem to be focusing on &quot;artificial&quot; limits where=
 that<br>
&gt; is not the issue under consideration.=C2=A0 The limits are technical<b=
r>
&gt; and relating to decentralisation and security.=C2=A0 I wont go over th=
em<br>
&gt; again as this topic has been covered many times in recent months.<br>
&gt; Any chain that tried to go to extreme parameters (very low block<br>
&gt; intervals, or very large blocksizes) would have the same<br>
&gt; decentralisation problems as Bitcoin would if it did the same<br>
&gt; thing.=C2=A0 There are a number of alt coins that have failed as a<br>
&gt; result of poor parameter choices, there are inherent security<br>
&gt; limits.<br>
&gt;<br>
&gt; Adam<br>
&gt;<br>
&gt; ps Etiquette note for yourself and others: please dont be<br>
&gt; repetitive or attempt to be forceful.=C2=A0 Many people have spent man=
y<br>
&gt; years understanding this very complex system, from my own<br>
&gt; experience it is rare indeed to think of an entirely new concept or<br=
>
&gt; analysis, that hasnt&#39; been long considered and put to bed 3 or 4<b=
r>
&gt; years ago. Thoughtful polite and constructive comments are welcome<br>
&gt; but I recommend to not start from an assumption that you have a<br>
&gt; clear and better insight than the entire technical community,<br>
&gt; because I have to say from my own experience that is very rarely<br>
&gt; the case.=C2=A0 It can be useful to test theories on #bitcoin IRC<br>
&gt; channel to find out what has been already concluded, find the<br>
&gt; references and avoid having to have that hashed out on this list<br>
&gt; which is trying to be focussed on technical solutions.<br>
&gt;<br>
&gt;<br>
&gt; On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt; Cheapest way to send value? Is this what Bitcoin is trying to<=
br>
&gt;&gt;&gt; do? So all of the smart contract, programmable money, consensu=
s<br>
&gt;&gt;&gt; coding and tremendous developer effort is bent to the consumer=
<br>
&gt;&gt;&gt; demand for cheaper fees. Surely thou jests!<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; These other features can be replicated into any alternative<br>
&gt;&gt; blockchain, including those with lower fees.=C2=A0 In the open-sou=
rce<br>
&gt;&gt; world of cryptocurrency, no feature will remain a value-add for<br=
>
&gt;&gt; very long after it has been identified to be such.=C2=A0 Anything<=
br>
&gt;&gt; adding value will quickly be absorbed into competing alternative<b=
r>
&gt;&gt; blockchains.=C2=A0 That will leave economic policy as the<br>
&gt;&gt; distinguishing factor.<br>
&gt;&gt;<br>
&gt;&gt;&gt; ... it is not the case ... that reluctance to concede blocksiz=
e<br>
&gt;&gt;&gt; is an attempt to constrain capacity. Greg Maxwell thoroughly<b=
r>
&gt;&gt;&gt; explained in this thread that the protocol&#39;s current state=
 of<br>
&gt;&gt;&gt; development relies on=C2=A0 blocksize for security and, ultima=
tely,<br>
&gt;&gt;&gt; as a means of protecting its degree of decentralization.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; A slow or lack of increase to maximum transaction rate will cause<=
br>
&gt;&gt; pressure on fees.=C2=A0 Whether this is the desired goal is not<br=
>
&gt;&gt; relevant.=C2=A0 Everyone has agreed this will be the outcome.=C2=
=A0 As to a<br>
&gt;&gt; smaller block size being needed for additional decentralization,<b=
r>
&gt;&gt; one must simply ask how much we are all willing to pay for that<br=
>
&gt;&gt; additional decentralization.=C2=A0 It is likely that the benefit<b=
r>
&gt;&gt; thereto will have to be demonstrated by some power attacking and<b=
r>
&gt;&gt; destroying a less decentralized currency before the benefit of<br>
&gt;&gt; this feature is given monetary value by the market.=C2=A0 Until th=
en,<br>
&gt;&gt; value will bleed to the network with the least friction, because<b=
r>
&gt;&gt; it will have the greatest ability to grow its network effect.<br>
&gt;&gt; That means the blockchain with adequate features and cheapest<br>
&gt;&gt; fees will eventually have the largest market share.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; -----Original Message----- From: Venzen Khaosan Sent: Wednesday,<b=
r>
&gt;&gt; July 29, 2015 3:11 PM To: Raystonn . Cc:<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a> Subject: Re: [bitcoin-dev]<br>
&gt;&gt; Why Satoshi&#39;s temporary anti-spam measure isn&#39;ttemporary<b=
r>
&gt;&gt;<br>
&gt; Raystonn, I&#39;m aware that you&#39;re addressing your question to Gr=
eg<br>
&gt; Maxwell, however a point you keep stating as fact calls for<br>
&gt; reference:<br>
&gt;<br>
&gt; On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: [snip]<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; How do you plan to address the bleeding of value from Bitc=
oin<br>
&gt;&gt;&gt;&gt; to alternative lower-fee blockchains created by the<br>
&gt;&gt;&gt;&gt; artificially-high bitcoin transaction fees when users begi=
n<br>
&gt;&gt;&gt;&gt; looking for the cheapest way to send value?<br>
&gt;<br>
&gt; Cheapest way to send value? Is this what Bitcoin is trying to do?<br>
&gt; So all of the smart contract, programmable money, consensus coding<br>
&gt; and tremendous developer effort is bent to the consumer demand for<br>
&gt; cheaper fees. Surely thou jests!<br>
&gt;<br>
&gt;&gt;&gt;&gt; Modern economic study has shown that liquidity moves to th=
e<br>
&gt;&gt;&gt;&gt; location of least friction.<br>
&gt;<br>
&gt; Modern economic study? Can you please provide a link or reference<br>
&gt; to the study you are referring to.<br>
&gt;<br>
&gt; &quot;liquidity moves to the location of least friction&quot;<br>
&gt;<br>
&gt; This sounds like &quot;econo-speak&quot; and makes no sense. The defin=
ition<br>
&gt; of Liquidity is the degree to which an asset/security can be bought<br=
>
&gt; or sold in the market without affecting the price.<br>
&gt;<br>
&gt; That is why bitcoin is said to have low liquidity: buying or<br>
&gt; selling only 100 BTC visibly affects the exchange price. You<br>
&gt; probably mean &quot;people like cheap fees&quot;, which is true, but a=
s<br>
&gt; others have said, because of Bitcoin&#39;s powerful features, they are=
<br>
&gt; willing to pay higher fees and wait longer for transactions to<br>
&gt; execute.<br>
&gt;<br>
&gt; As for your public cross-examination of Greg Maxwell, your case<br>
&gt; seems to=C2=A0 be made on the assumption that limiting the size of the=
<br>
&gt; blockchain is an attempt to artificially raise tx fees, but it is<br>
&gt; not the case (as you and others repeatedly argue) that reluctance<br>
&gt; to concede blocksize is an attempt to constrain capacity. Greg<br>
&gt; Maxwell thoroughly explained in this thread that the protocol&#39;s<br=
>
&gt; current state of development relies on=C2=A0 blocksize for security an=
d,<br>
&gt; ultimately, as a means of protecting its degree of<br>
&gt; decentralization.<br>
&gt;<br>
&gt; Surely, this is an obvious concern even for those who are<br>
&gt; campaigning for the hare-brained ideal of making Bitcoin a &quot;faste=
r,<br>
&gt; cheaper alternative&quot; to visa or paypal? If we lose<br>
&gt; decentralization, we lose the whole thing, right? Incorrect or<br>
&gt; correct?<br>
&gt;&gt; _______________________________________________ bitcoin-dev<br>
&gt;&gt; mailing list <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
iQEcBAEBAgAGBQJVuetlAAoJEGwAhlQc8H1m2TkH/jKx7V9vCZbOjbxAlfjnR0ai<br>
+QDxMm0K0sL/MlsLVm0FAHwGiKhYJnEeXiZJlXu0eiUz35JALDMtSQiVbQzcHAc2<br>
GvyW3tWUh6+uSfYhsnImQXxlDgCUKIgZvtTM900OWcGXZeLU3W5UdUK5+ietHK0/<br>
1HbZgcljqke+nSsH2aCagd/iNdwCIUcfapsUgB6iPWtZQfLg6SHi8CjbG/Th5Na7<br>
fpA5yJlO4N+Q2JpOVId/LfC7loDCEZtPtYA5NZAsDcEcSIXUycCoGL8LNMIFGJNe<br>
Ko2RNqGeIkb/x8T2USxlkrNUZx/CCF201MMClPLC/LXX1bEMDvO8F0m1TBR1ptg=3D<br>
=3D106o<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--f46d0438eb9f8b8e18051c147572--