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
|
Return-Path: <jrn@jrn.me.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 16B0CB8B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 19:18:04 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a1.g.dreamhost.com (homie.mail.dreamhost.com
[208.97.132.208])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 1F6D1143
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 19:18:03 +0000 (UTC)
Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 6FB7734806E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 12:18:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to
:references:from:message-id:date:mime-version:in-reply-to:
content-type; s=jrn.me.uk; bh=ix5IoE5oS8mCuBFHewVmO/44Wtc=; b=eQ
ANqmMcZsCl1ovyMwmmK51lyMkAEGyckkC78dv4cBaKjy0Eg9ntAEfHRtskHCLmLT
OGme2uctzXiRrQeQ0SpnEXWYALvrud8pdxFj/WX8kZ1kUi03TJDgg9ZUcjmVIhqg
tmF5IvXpLuYZQthGs3qzZLrh0nBkrNOS5kM/M4uSI=
Received: from [192.168.0.6] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net
[86.30.131.63])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: jrn@jrn.me.uk)
by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPSA id D6BE934806C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 12:18:01 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
<CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com>
<CAPg+sBg=sn7djO_8H16NDg7S7m7_0eTcrgLVofMWQ2ANz+jw9w@mail.gmail.com>
<CADm_WcbQog_UCV=JPHyqTRxKbaGY7jedtHE_D8jJSe_thMg05w@mail.gmail.com>
<CAPg+sBhrBUSfPdMjbLthLEFD17zBC3LoWf9LvZsOD1Vp0D78BQ@mail.gmail.com>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <558DA56F.3010703@jrn.me.uk>
Date: Fri, 26 Jun 2015 20:18:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CAPg+sBhrBUSfPdMjbLthLEFD17zBC3LoWf9LvZsOD1Vp0D78BQ@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------090100020403090408000201"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
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: Fri, 26 Jun 2015 19:18:04 -0000
This is a multi-part message in MIME format.
--------------090100020403090408000201
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
I'd argue that at the point where there's consistently more transactions
than the network can handle, there are two significant risks. Firstly,
that people don't care enough to pay the transaction fees required to
get their transaction prioritised over another's, and secondly that as
transactions start outright failing (which will happen with enough
transactions backlogged) the network is considered unreliable, the
currency illiquid, and there's a virtual "bank rush" to get into a more
usable currency.
I understand the desire to use current demand to model future, however I
feel there's a lack of understanding of just how inadequate the main
chain is as a global clearance network. My go-to example for this is
CHIPS (US-only, inter-bank only clearance) which already handles
slightly over 3 transactions per second on average across a year
(https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en).
If Bitcoin is to be used across a wider portion of the world's
population, and/or beyond clearance between financial institutions, it
needs larger blocks. This is not about handling the several orders of
magnitude more transactions that would be required to replace credit
cards or cash, but simply to enabling other technologies to perform that
scaling.
Also, and I'm aware most on this list do understand the situation better
than this, I find it immensely frustrating to see people suggesting that
Greece or other large groups should adopt Bitcoin, while there's clearly
inadequate support (on chain or off) to do so.
Ross
On 26/06/2015 19:34, Pieter Wuille wrote:
>
> > If you wait until the need to increase block size
>
> It is this sentence I disagree with. Why would there be a need?
> Bitcoin provides utility at any block size, and potentially more with
> larger blocks.
>
> But no matter what, I believe the economy will adapt to what is
> available. And setting a precedent that increasing the size "because
> of a need" is reasonable is to me essentially the same as saying the
> size should forever scale to whatever people want.
>
> I believe the most important effect of a limit block size - people
> deciding not to use (on chain) Bitcoin transactions, is already
> happening, and it will keep happening at any scale.
>
> Either the resulting market is one which can live with high
> variability in confirmation times, and blocks will end up being nearly
> full. Or maybe the current fill level is what is acceptable, and we
> don't see much growth beyond this, only a change in what it is used for.
>
> --
> Pieter
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------090100020403090408000201
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I'd argue that at the point where there's consistently more
transactions than the network can handle, there are two significant
risks. Firstly, that people don't care enough to pay the transaction
fees required to get their transaction prioritised over another's,
and secondly that as transactions start outright failing (which will
happen with enough transactions backlogged) the network is
considered unreliable, the currency illiquid, and there's a virtual
"bank rush" to get into a more usable currency.<br>
<br>
I understand the desire to use current demand to model future,
however I feel there's a lack of understanding of just how
inadequate the main chain is as a global clearance network. My go-to
example for this is CHIPS (US-only, inter-bank only clearance) which
already handles slightly over 3 transactions per second on average
across a year
(<a class="moz-txt-link-freetext" href="https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en">https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en</a>).
If Bitcoin is to be used across a wider portion of the world's
population, and/or beyond clearance between financial institutions,
it needs larger blocks. This is not about handling the several
orders of magnitude more transactions that would be required to
replace credit cards or cash, but simply to enabling other
technologies to perform that scaling.<br>
<br>
Also, and I'm aware most on this list do understand the situation
better than this, I find it immensely frustrating to see people
suggesting that Greece or other large groups should adopt Bitcoin,
while there's clearly inadequate support (on chain or off) to do so.<br>
<br>
Ross<br>
<br>
<div class="moz-cite-prefix">On 26/06/2015 19:34, Pieter Wuille
wrote:<br>
</div>
<blockquote
cite="mid:CAPg+sBhrBUSfPdMjbLthLEFD17zBC3LoWf9LvZsOD1Vp0D78BQ@mail.gmail.com"
type="cite">
<p dir="ltr">> If you wait until the need to increase block
size </p>
<p dir="ltr">It is this sentence I disagree with. Why would there
be a need? Bitcoin provides utility at any block size, and
potentially more with larger blocks.</p>
<p dir="ltr">But no matter what, I believe the economy will adapt
to what is available. And setting a precedent that increasing
the size "because of a need" is reasonable is to me essentially
the same as saying the size should forever scale to whatever
people want.</p>
<p dir="ltr">I believe the most important effect of a limit block
size - people deciding not to use (on chain) Bitcoin
transactions, is already happening, and it will keep happening
at any scale.</p>
<p dir="ltr">Either the resulting market is one which can live
with high variability in confirmation times, and blocks will end
up being nearly full. Or maybe the current fill level is what is
acceptable, and we don't see much growth beyond this, only a
change in what it is used for.</p>
<p dir="ltr">-- <br>
Pieter<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------090100020403090408000201--
|
