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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jrn@jrn.me.uk>) id 1Z5j3D-0004SI-Hr
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 23:16:51 +0000
X-ACL-Warn:
Received: from homie.mail.dreamhost.com ([208.97.132.208]
helo=homiemail-a7.g.dreamhost.com)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z5j3B-00038e-Or for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 23:16:51 +0000
Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 3E5C925C074
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 16:16:44 -0700 (PDT)
Received: from [10.9.1.135] (unknown [89.238.129.18])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: jrn@jrn.me.uk)
by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 8EA8E25C072
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 16:16:43 -0700 (PDT)
Message-ID: <5583515E.9080304@jrn.me.uk>
Date: Fri, 19 Jun 2015 00:16:46 +0100
From: Ross Nicoll <jrn@jrn.me.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <55828737.6000007@riseup.net> <CABm2gDoa7KxsgvREo3yiNjfd6AeayqAqkjMe2rvX8yyxR_ddcA@mail.gmail.com> <55831CAB.2080303@jrn.me.uk>
<1867667.WXWC1C9quc@crushinator> <CAOG=w-scXm-46sp2NgR2UUp20R5ujuaAzW-jU_Owh20C4Xc=9A@mail.gmail.com> <CAJHLa0Mhnma8_ys2ckEA+dLT-EWnqO4j8YKMSaf3Tvv_K14czQ@mail.gmail.com>
<CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com>
In-Reply-To: <CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------040102080406070502080008"
X-Spam-Score: 0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [208.97.132.208 listed in list.dnswl.org]
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5j3B-00038e-Or
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
to Remove Commit Access from Other Developers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2015 23:16:51 -0000
This is a multi-part message in MIME format.
--------------040102080406070502080008
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
I'm struggling to illustrate how incredibly low 7 transactions per
second is, not just for a payment network, but even just for a clearance
network (i.e. to balance transactions between institutions and/or
chains). As an example, the Clearing House Interbank Payments System
(CHIPS) is a US-only, inter-bank only clearance network, which handled
about 3.5 transactions per second (average) in 2014
(https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en).
While it seems likely the US population of 300 million makes more
transactions individually than many other countries, and therefore we
can't simply multiply that by 20 to estimate what a global clearance
network might require, hopefully it's clear that if Bitcoin is to scale
globally, it needs substantially more transaction throughput even if
main chain transactions become something for banks and the super rich. I
don't know how much more, but I can't look at the 8MB reportedly backed
by a number of mining pools and say it's clearly insufficient, at least.
I should emphasise that I don't think we need to jump straight to 8MB
(or otherwise), if a scaling protocol can be decided upon that would be
ideal, but we should be planning ahead while it's still relatively easy
to make these changes.
Ross
On 18/06/2015 23:33, Mark Friedenbach wrote:
> On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik@bitpay.com
> <mailto:jgarzik@bitpay.com>> wrote:
>
>
> The whole point is getting out in front of the need, to prevent
> significant negative impact to users when blocks are consistently
> full.
>
> To do that, you need to (a) plan forward, in order to (b) set a
> hard fork date in the future.
>
>
> Or alternatively, fix the reasons why users would have negative
> experiences with full blocks, chiefly:
>
> * Get safe forms of replace-by-fee and child-pays-for-parent
> finished and in 0.12.
> * Develop cross-platform libraries for managing micropayment
> channels, and get wallet authors to adopt
> * Use fidelity bonds, solvency proofs, and other tricks to minimize
> the risk of already deployed off-chain solutions as an interim measure
> until:
> * Deploy soft-fork changes for truly scalable solutions like
> Lightning Network.
>
> Not raising the block size limit does not mean doing nothing to solve
> the problem.
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------040102080406070502080008
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
I'm struggling to illustrate how incredibly low 7 transactions per
second is, not just for a payment network, but even just for a
clearance network (i.e. to balance transactions between institutions
and/or chains). As an example, the Clearing House Interbank Payments
System (CHIPS) is a US-only, inter-bank only clearance network,
which handled about 3.5 transactions per second (average) in 2014
(<a class=3D"moz-txt-link-freetext" href=3D"https://www.theclearinghouse.=
org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20th=
rough%20may%202015.pdf?la=3Den">https://www.theclearinghouse.org/~/media/=
tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%=
202015.pdf?la=3Den</a>).<br>
<br>
While it seems likely the US population of 300 million makes more
transactions individually than many other countries, and therefore
we can't simply multiply that by 20 to estimate what a global
clearance network might require, hopefully it's clear that if
Bitcoin is to scale globally, it needs substantially more
transaction throughput even if main chain transactions become
something for banks and the super rich. I don't know how much more,
but I can't look at the 8MB reportedly backed by a number of mining
pools and say it's clearly insufficient, at least.<br>
<br>
I should emphasise that I don't think we need to jump straight to
8MB (or otherwise), if a scaling protocol can be decided upon that
would be ideal, but we should be planning ahead while it's still
relatively easy to make these changes.<br>
<br>
Ross<br>
<br>
<div class=3D"moz-cite-prefix">On 18/06/2015 23:33, Mark Friedenbach
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOG=3Dw-tf7qz9XSkDg5POKtFLkHWDA=3D=3Djf2iVxVL8wz1hqcAVOg@mai=
l.gmail.com"
type=3D"cite">
<div dir=3D"ltr">On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <span
dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:jgarzik@bitpay.com" target=3D"_blank">jgarzik@=
bitpay.com</a>></span>
wrote:<br>
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div dir=3D"ltr">The whole point is getting out in front of
the need, to prevent significant negative impact to
users when blocks are consistently full.
<div><br>
</div>
<div>To do that, you need to (a) plan forward, in order
to (b) set a hard fork date in the future.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Or alternatively, fix the reasons why users would have
negative experiences with full blocks, chiefly:<br>
<br>
</div>
<div>=A0 * Get safe forms of replace-by-fee and
child-pays-for-parent finished and in 0.12.<br>
</div>
<div>=A0 * Develop cross-platform libraries for managing
micropayment channels, and get wallet authors to adopt <br>
</div>
<div>=A0 * Use fidelity bonds, solvency proofs, and other
tricks to minimize the risk of already deployed off-chain
solutions as an interim measure until:<br>
</div>
<div>=A0 * Deploy soft-fork changes for truly scalable
solutions like Lightning Network.<br>
<br>
</div>
<div>Not raising the block size limit does not mean doing
nothing to solve the problem.<br>
</div>
</div>
<br>
</div>
</div>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset>
<br>
<pre wrap=3D"">----------------------------------------------------=
--------------------------
</pre>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset>
<br>
<pre wrap=3D"">_______________________________________________
Bitcoin-development mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Bitcoin-development@=
lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.sourceforge.net/=
lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/l=
istinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------040102080406070502080008--
|
