summaryrefslogtreecommitdiff
path: root/85/11db98e2a70bcea32d8436da214d2de13fb02c
blob: 0125ad0122c0a53a53ef6d314a2770d0c0ab9271 (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
Return-Path: <gubatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B258F267
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 22:07:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com
	[209.85.213.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6982EEE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 22:07:13 +0000 (UTC)
Received: by igui7 with SMTP id i7so50085950igu.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Aug 2015 15:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=1aNnq6SLbo1JwLd1OeBL1NFLhKPwOIDvdvaRofStF20=;
	b=kXbRCK9q+uQB6oar73S1Y+ugmps9upEAlKvE+YA84nRH1iAQikyqXLNJOPjLCgL7g8
	02k89+YDNiViKb2GAjx0V4BUKLySDfphDe6o8g61dW9Agx/JrLwSyIFW3YuKavGOZCUx
	XStSDR/WDMKxDVdmxPsPnntYpIv4T3K5q5XQcISfSTVoaLxBJr+33mgHQa5I0ltTunAn
	qOIGPzSd7Sd9agRf1Jc/CYzP+pcKhpvy8dTDAPd7hE9LzbpM1ybPJfLHb4XjPlv/w+uJ
	mMWZkPx/ANtG/WyrsdhPtvkyOVT4HpFzUBuAwbYE4ox1ANDrKla3OY/A8CILrt7EFfd8
	GLgg==
X-Received: by 10.50.73.170 with SMTP id m10mr21386275igv.60.1439330832827;
	Tue, 11 Aug 2015 15:07:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.122.144 with HTTP; Tue, 11 Aug 2015 15:06:52 -0700 (PDT)
In-Reply-To: <CALqxMTHpFfOWa897+NX5bwjPb5Ayoqswkbwp5n+S+4vAV-VMpg@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
	<CABm2gDpwMQzju+Gsoe3qMi60MPr7OAiSuigy3RdA1xh-SwFzbw@mail.gmail.com>
	<CABm2gDoz4NMEQuQj6UHCYYCwihZrEC4Az8xDvTBwiZDf9eQ7-w@mail.gmail.com>
	<8181630.GdAj0CPZYc@coldstorage>
	<CABm2gDp2svO2G5bHs5AcjjN8dmP6P5nv0xriWez-pvzs2oBL5w@mail.gmail.com>
	<CALgxB7sQM5ObxyxDiN_BOyJrgsgfQ6PAtJi52dJENfWCRKywWg@mail.gmail.com>
	<CABm2gDq+2mXEN2hZY6_JYXAJX=Wxrxr6jm86P6g2YD4zzy-=Nw@mail.gmail.com>
	<CALgxB7sLsod9Kb-pwxGwCtPpWXsUusDE1nJ7p4nbFMG8mDWFtg@mail.gmail.com>
	<CAPg+sBjGVk1jHraLZTroRneL6L1HxZ-bTGaLNwakcDSDDHqauA@mail.gmail.com>
	<CALgxB7unOhWjoCcvGoCqzMnzwTL8XdJWt18kdiDSEeJ_cuiHqg@mail.gmail.com>
	<CALqxMTFfUdMuNsNnx-B+SPq7HvQyA+NkvFHGVYPiFHn-ZipVJw@mail.gmail.com>
	<CADZB0_Y-ddH8-rpfrUzfG1rvmC_Jy4cr8m_mC2JtLt-LiYgd_g@mail.gmail.com>
	<CALqxMTHpFfOWa897+NX5bwjPb5Ayoqswkbwp5n+S+4vAV-VMpg@mail.gmail.com>
From: Angel Leon <gubatron@gmail.com>
Date: Tue, 11 Aug 2015 18:06:52 -0400
Message-ID: <CADZB0_btVOvav5oHKnhrdjc4Sf33NyqdP4UFunJs6QQqt6K7Jg@mail.gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=089e01183996014f25051d105390
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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] Fees and the block-finding process
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: Tue, 11 Aug 2015 22:07:14 -0000

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

> So if they dont care about decentralisation, they'll be happy using cheaper
off-chain systems, right?

You betcha! Just talk to a regular people and try to sell them on the
different scenarios.

They will start using something cheaper/faster the minute it comes along
from the banking industry, just to give you a real world example, this week
I've been dreading the idea of having to go to the bank to make a couple of
cash deposits. If I could open my bank's web page right now and do a very
simple interbank transaction (without having to convince the to let me link
their accounts to mine, with the process that takes like 2 days when they
deposit 2 different cent amounts...) just here within the retarded US
banking system... which has clearly realized the threat from
cryptocurrencies as evidenced on many banker conferences this year.

They will come up with ways to allow us to do person to person transfers,
but this will surely be limited to transactions within the country,
international remittances still have a great chance of being disrupted by
Bitcoin, if and only if, it will be cheap, otherwise the western unions and
xooms of the world will still rule.

Please get out of our your academic cocoon for a bit, talk to real people,
try to convince them to use Bitcoin, and think how hard it will be to make
the sell if on top you tell them... "it costs more... but it's
decentralized!" LOL

http://twitter.com/gubatron

On Tue, Aug 11, 2015 at 5:34 PM, Adam Back <adam@cypherspace.org> wrote:

> So if they dont care about decentralisation, they'll be happy using
> cheaper off-chain systems, right?
>
> Adam
>
> On 11 August 2015 at 22:30, Angel Leon <gubatron@gmail.com> wrote:
> > tell that to people in poor countries, or even in first world countries.
> The
> > competitive thing here is a deal breaker for a lot of people who have no
> > clue/don't care for decentralization, they just want to send money from
> A to
> > B, like email.
> >
> > http://twitter.com/gubatron
> >
> > On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> I dont think Bitcoin being cheaper is the main characteristic of
> >> Bitcoin.  I think the interesting thing is trustlessness - being able
> >> to transact without relying on third parties.
> >>
> >> Adam
> >>
> >>
> >> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> > The only reason why Bitcoin has grown the way it has, and in fact the
> >> > only
> >> > reason why we're all even here on this mailing list talking about
> this,
> >> > is
> >> > because Bitcoin is growing, since it's "better money than other
> money".
> >> > One
> >> > of the key characteristics toward that is Bitcoin being inexpensive to
> >> > transact. If that characteristic is no longer true, then Bitcoin isn't
> >> > going
> >> > to grow, and in fact Bitcoin itself will be replaced by better money
> >> > that is
> >> > less expensive to transfer.
> >> >
> >> > So the importance of this issue cannot be overstated -- it's compete
> or
> >> > die
> >> > for Bitcoin -- because people want to transact with global consensus
> at
> >> > high
> >> > volume, and because technology exists to service that want, then it's
> >> > going
> >> > to be met. This is basic rules of demand and supply. I don't
> necessarily
> >> > disagree with your position on only wanting to support uncontroversial
> >> > commits, but I think it's important to get consensus on the
> criticality
> >> > of
> >> > the block size issue: do you agree, disagree, or not take a side, and
> >> > why?
> >> >
> >> >
> >> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <
> pieter.wuille@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
> >> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> >>>
> >> >>> Hitting the limit in and of itself is not necessarily a bad thing.
> The
> >> >>> question at hand is whether we should constrain that limit below
> what
> >> >>> technology is capable of delivering. I'm arguing that not only we
> >> >>> should
> >> >>> not, but that we could not even if we wanted to, since competition
> >> >>> will
> >> >>> deliver capacity for global consensus whether it's in Bitcoin or in
> >> >>> some
> >> >>> other product / fork.
> >> >>
> >> >>
> >> >> The question is not what the technology can deliver. The question is
> >> >> what
> >> >> price we're willing to pay for that. It is not a boolean "at this
> size,
> >> >> things break, and below it, they work". A small constant factor
> >> >> increase
> >> >> will unlikely break anything in the short term, but it will come with
> >> >> higher
> >> >> centralization pressure of various forms. There is discussion about
> >> >> whether
> >> >> these centralization pressures are significant, but citing that it's
> >> >> artificially constrained under the limit is IMHO a misrepresentation.
> >> >> It is
> >> >> constrained to aim for a certain balance between utility and risk,
> and
> >> >> neither extreme is interesting, while possibly still "working".
> >> >>
> >> >> Consensus rules are what keeps the system together. You can't simply
> >> >> switch to new rules on your own, because the rest of the system will
> >> >> end up
> >> >> ignoring you. These rules are there for a reason. You and I may agree
> >> >> about
> >> >> whether the 21M limit is necessary, and disagree about whether we
> need
> >> >> a
> >> >> block size limit, but we should be extremely careful with change. My
> >> >> position as Bitcoin Core developer is that we should merge consensus
> >> >> changes
> >> >> only when they are uncontroversial. Even when you believe a more
> >> >> invasive
> >> >> change is worth it, others may disagree, and the risk from
> disagreement
> >> >> is
> >> >> likely larger than the effect of a small block size increase by
> itself:
> >> >> the
> >> >> risk that suddenly every transaction can be spent twice (once on each
> >> >> side
> >> >> of the fork), the very thing that the block chain was designed to
> >> >> prevent.
> >> >>
> >> >> My personal opinion is that we should aim to do a block size increase
> >> >> for
> >> >> the right reasons. I don't think fear of rising fees or unreliability
> >> >> should
> >> >> be an issue: if fees are being paid, it means someone is willing to
> pay
> >> >> them. If people are doing transactions despite being unreliable,
> there
> >> >> must
> >> >> be a use for them. That may mean that some use cases don't fit
> anymore,
> >> >> but
> >> >> that is already the case.
> >> >>
> >> >> --
> >> >> Pieter
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev@lists.linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>

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

<div dir=3D"ltr"><span style=3D"font-size:13px">&gt; So if they dont care a=
bout decentralisation, they&#39;ll be happy using=C2=A0</span><span style=
=3D"font-size:13px">cheaper off-chain systems, right?</span><br><br>You bet=
cha! Just talk to a regular people and try to sell them on the different sc=
enarios.<br><br>They will start using something cheaper/faster the minute i=
t comes along from the banking industry, just to give you a real world exam=
ple, this week I&#39;ve been dreading the idea of having to go to the bank =
to make a couple of cash deposits. If I could open my bank&#39;s web page r=
ight now and do a very simple interbank transaction (without having to conv=
ince the to let me link their accounts to mine, with the process that takes=
 like 2 days when they deposit 2 different cent amounts...) just here withi=
n the retarded US banking system... which has clearly realized the threat f=
rom cryptocurrencies as evidenced on many banker conferences this year.<br>=
<br>They will come up with ways to allow us to do person to person transfer=
s, but this will surely be limited to transactions within the country, inte=
rnational remittances still have a great chance of being disrupted by Bitco=
in, if and only if, it will be cheap, otherwise the western unions and xoom=
s of the world will still rule.<br><br>Please get out of our your academic =
cocoon for a bit, talk to real people, try to convince them to use Bitcoin,=
 and think how hard it will be to make the sell if on top you tell them... =
&quot;it costs more... but it&#39;s decentralized!&quot; LOL</div><div clas=
s=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail_signature"><a =
href=3D"http://twitter.com/gubatron" target=3D"_blank">http://twitter.com/g=
ubatron</a><br></div></div>
<br><div class=3D"gmail_quote">On Tue, Aug 11, 2015 at 5:34 PM, Adam Back <=
span dir=3D"ltr">&lt;<a href=3D"mailto:adam@cypherspace.org" target=3D"_bla=
nk">adam@cypherspace.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">So if they dont care about decentralisation, they&#39;ll be happy usi=
ng<br>
cheaper off-chain systems, right?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Adam<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On 11 August 2015 at 22:30, Angel Leon &lt;<a href=3D"mailto:gubatron@gmail=
.com">gubatron@gmail.com</a>&gt; wrote:<br>
&gt; tell that to people in poor countries, or even in first world countrie=
s. The<br>
&gt; competitive thing here is a deal breaker for a lot of people who have =
no<br>
&gt; clue/don&#39;t care for decentralization, they just want to send money=
 from A to<br>
&gt; B, like email.<br>
&gt;<br>
&gt; <a href=3D"http://twitter.com/gubatron" rel=3D"noreferrer" target=3D"_=
blank">http://twitter.com/gubatron</a><br>
&gt;<br>
&gt; On Tue, Aug 11, 2015 at 5:23 PM, Adam Back 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;<br>
&gt;&gt; I dont think Bitcoin being cheaper is the main characteristic of<b=
r>
&gt;&gt; Bitcoin.=C2=A0 I think the interesting thing is trustlessness - be=
ing able<br>
&gt;&gt; to transact without relying on third parties.<br>
&gt;&gt;<br>
&gt;&gt; Adam<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; &gt; The only reason why Bitcoin has grown the way it has, and in =
fact the<br>
&gt;&gt; &gt; only<br>
&gt;&gt; &gt; reason why we&#39;re all even here on this mailing list talki=
ng about this,<br>
&gt;&gt; &gt; is<br>
&gt;&gt; &gt; because Bitcoin is growing, since it&#39;s &quot;better money=
 than other money&quot;.<br>
&gt;&gt; &gt; One<br>
&gt;&gt; &gt; of the key characteristics toward that is Bitcoin being inexp=
ensive to<br>
&gt;&gt; &gt; transact. If that characteristic is no longer true, then Bitc=
oin isn&#39;t<br>
&gt;&gt; &gt; going<br>
&gt;&gt; &gt; to grow, and in fact Bitcoin itself will be replaced by bette=
r money<br>
&gt;&gt; &gt; that is<br>
&gt;&gt; &gt; less expensive to transfer.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; So the importance of this issue cannot be overstated -- it&#3=
9;s compete or<br>
&gt;&gt; &gt; die<br>
&gt;&gt; &gt; for Bitcoin -- because people want to transact with global co=
nsensus at<br>
&gt;&gt; &gt; high<br>
&gt;&gt; &gt; volume, and because technology exists to service that want, t=
hen it&#39;s<br>
&gt;&gt; &gt; going<br>
&gt;&gt; &gt; to be met. This is basic rules of demand and supply. I don&#3=
9;t necessarily<br>
&gt;&gt; &gt; disagree with your position on only wanting to support uncont=
roversial<br>
&gt;&gt; &gt; commits, but I think it&#39;s important to get consensus on t=
he criticality<br>
&gt;&gt; &gt; of<br>
&gt;&gt; &gt; the block size issue: do you agree, disagree, or not take a s=
ide, and<br>
&gt;&gt; &gt; why?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille &lt;<a href=3D=
"mailto:pieter.wuille@gmail.com">pieter.wuille@gmail.com</a>&gt;<br>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoi=
n-dev<br>
&gt;&gt; &gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Hitting the limit in and of itself is not necessarily=
 a bad thing. The<br>
&gt;&gt; &gt;&gt;&gt; question at hand is whether we should constrain that =
limit below what<br>
&gt;&gt; &gt;&gt;&gt; technology is capable of delivering. I&#39;m arguing =
that not only we<br>
&gt;&gt; &gt;&gt;&gt; should<br>
&gt;&gt; &gt;&gt;&gt; not, but that we could not even if we wanted to, sinc=
e competition<br>
&gt;&gt; &gt;&gt;&gt; will<br>
&gt;&gt; &gt;&gt;&gt; deliver capacity for global consensus whether it&#39;=
s in Bitcoin or in<br>
&gt;&gt; &gt;&gt;&gt; some<br>
&gt;&gt; &gt;&gt;&gt; other product / fork.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; The question is not what the technology can deliver. The =
question is<br>
&gt;&gt; &gt;&gt; what<br>
&gt;&gt; &gt;&gt; price we&#39;re willing to pay for that. It is not a bool=
ean &quot;at this size,<br>
&gt;&gt; &gt;&gt; things break, and below it, they work&quot;. A small cons=
tant factor<br>
&gt;&gt; &gt;&gt; increase<br>
&gt;&gt; &gt;&gt; will unlikely break anything in the short term, but it wi=
ll come with<br>
&gt;&gt; &gt;&gt; higher<br>
&gt;&gt; &gt;&gt; centralization pressure of various forms. There is discus=
sion about<br>
&gt;&gt; &gt;&gt; whether<br>
&gt;&gt; &gt;&gt; these centralization pressures are significant, but citin=
g that it&#39;s<br>
&gt;&gt; &gt;&gt; artificially constrained under the limit is IMHO a misrep=
resentation.<br>
&gt;&gt; &gt;&gt; It is<br>
&gt;&gt; &gt;&gt; constrained to aim for a certain balance between utility =
and risk, and<br>
&gt;&gt; &gt;&gt; neither extreme is interesting, while possibly still &quo=
t;working&quot;.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Consensus rules are what keeps the system together. You c=
an&#39;t simply<br>
&gt;&gt; &gt;&gt; switch to new rules on your own, because the rest of the =
system will<br>
&gt;&gt; &gt;&gt; end up<br>
&gt;&gt; &gt;&gt; ignoring you. These rules are there for a reason. You and=
 I may agree<br>
&gt;&gt; &gt;&gt; about<br>
&gt;&gt; &gt;&gt; whether the 21M limit is necessary, and disagree about wh=
ether we need<br>
&gt;&gt; &gt;&gt; a<br>
&gt;&gt; &gt;&gt; block size limit, but we should be extremely careful with=
 change. My<br>
&gt;&gt; &gt;&gt; position as Bitcoin Core developer is that we should merg=
e consensus<br>
&gt;&gt; &gt;&gt; changes<br>
&gt;&gt; &gt;&gt; only when they are uncontroversial. Even when you believe=
 a more<br>
&gt;&gt; &gt;&gt; invasive<br>
&gt;&gt; &gt;&gt; change is worth it, others may disagree, and the risk fro=
m disagreement<br>
&gt;&gt; &gt;&gt; is<br>
&gt;&gt; &gt;&gt; likely larger than the effect of a small block size incre=
ase by itself:<br>
&gt;&gt; &gt;&gt; the<br>
&gt;&gt; &gt;&gt; risk that suddenly every transaction can be spent twice (=
once on each<br>
&gt;&gt; &gt;&gt; side<br>
&gt;&gt; &gt;&gt; of the fork), the very thing that the block chain was des=
igned to<br>
&gt;&gt; &gt;&gt; prevent.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; My personal opinion is that we should aim to do a block s=
ize increase<br>
&gt;&gt; &gt;&gt; for<br>
&gt;&gt; &gt;&gt; the right reasons. I don&#39;t think fear of rising fees =
or unreliability<br>
&gt;&gt; &gt;&gt; should<br>
&gt;&gt; &gt;&gt; be an issue: if fees are being paid, it means someone is =
willing to pay<br>
&gt;&gt; &gt;&gt; them. If people are doing transactions despite being unre=
liable, there<br>
&gt;&gt; &gt;&gt; must<br>
&gt;&gt; &gt;&gt; be a use for them. That may mean that some use cases don&=
#39;t fit anymore,<br>
&gt;&gt; &gt;&gt; but<br>
&gt;&gt; &gt;&gt; that is already the case.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; --<br>
&gt;&gt; &gt;&gt; Pieter<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; bitcoin-dev mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo=
/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@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>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>

--089e01183996014f25051d105390--