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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gubatron@gmail.com>) id 1YHeLv-00055V-Ir
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Jan 2015 20:09:11 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.53 as permitted sender)
client-ip=209.85.216.53; envelope-from=gubatron@gmail.com;
helo=mail-qa0-f53.google.com;
Received: from mail-qa0-f53.google.com ([209.85.216.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YHeLu-0004nY-BE
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Jan 2015 20:09:11 +0000
Received: by mail-qa0-f53.google.com with SMTP id n4so24484370qaq.12
for <bitcoin-development@lists.sourceforge.net>;
Sat, 31 Jan 2015 12:09:04 -0800 (PST)
X-Received: by 10.229.125.133 with SMTP id y5mr25903198qcr.17.1422734944754;
Sat, 31 Jan 2015 12:09:04 -0800 (PST)
MIME-Version: 1.0
References: <CADZB0_aWkSApjRA-WQcVsonOTpZNX8=G=iuY3k+dKSwDq=xM6A@mail.gmail.com>
<CANEZrP3+ca9Bumv=-2ot7T5s6cvGhN_dMqYmsxP7qP1V0WV4qg@mail.gmail.com>
From: Angel Leon <gubatron@gmail.com>
Date: Sat, 31 Jan 2015 20:08:57 +0000
Message-ID: <CADZB0_YYXto3SJjq2FcZPUKwsHas3chmgdcxhwhU_Hh6QO1vZg@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a1133d996fdfbd3050df84a5d
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gubatron[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
X-Headers-End: 1YHeLu-0004nY-BE
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Is there a way to estimate the maximum
number of transactions per minute Bitcoin can handle as it is today?
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: Sat, 31 Jan 2015 20:09:11 -0000
--001a1133d996fdfbd3050df84a5d
Content-Type: text/plain; charset=UTF-8
My concerns come from 2 projects that could easily raise the current
transaction volume 10x daily in the short term, perhaps even 100x a year
from now after the media blows it out.
Think legal bittorrent file sales: ebooks, indie music (albums and
singles), films, art, stock photography.
Think p2p amazon (OpenBazaar) and how that could grow exponentially in
terms of transactional volume when ecommerce penetrates geos currently
underserved.
Thanks for your explanations. it seems as of now we must rely on the likes
of centralized solutions like Bitpay, Coinbase to manage the transactional
volume we expect, or just wait for the technology to be ready finally
handle it in a real p2p fashion, no intermediaries.
On Sat, Jan 31, 2015, 6:04 PM Mike Hearn <mike@plan99.net> wrote:
> "Alipay handled up to 2.85 million transactions per minute, and 54 percent
>> of its transactions are made via mobile device."
>>
>
> I know China is a very big place but even so - 47,500 transactions per
> second would be almost quintiple what Visa handles across the entire world.
> With only 300 million users and primarily online usage (?) this claim feels
> a little suspect to me.
>
> Given the wording "up to 2.85 million" I wonder if that is some freak
> spike caused by people's behaviour being synchronised externally (e.g. a
> fixed start time for the sale that people are waiting for). It's hard to
> imagine that they sustained anything close to that for the entire day.
>
> So this is really a discussion about peak performance.
>
> If you average every transaction around 250 bytes, then you'd need ~15
>> Gigabytes per block to be broadcast and hashed by all the full nodes every
>> 10 minutes, eating good 2Tb of storage daily... do miners have enough
>> bandwidth and CPU power to handle this?
>>
>
> There's a discussion of such things here that might be useful:
>
> https://en.bitcoin.it/wiki/Scalability
>
> It discusses various optimisations, like not actually sending tx data
> twice.
>
> I wouldn't worry about it too much. It took decades for Visa to even
> approach 10,000 txns/sec. PayPal, I believe, still "only" handles a few
> hundred. And those services had the benefits of minimal competition,
> working in people's local currencies, integrated dispute mediation and not
> representing any real threat to the political status quo. Bitcoin isn't
> going to be needing to handle Alipay's level of traffic any time soon.
>
> Frankly, scaling is a nice problem to have, it means you're popular. It'd
> be a mistake to just blindly assume Bitcoin will take over the world.
> Growing market share is difficult. Worry more about how to get 300 million
> crazy users than the precise broadcast protocol that'd be needed to handle
> them ;)
>
--001a1133d996fdfbd3050df84a5d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">My concerns come from 2 projects that could easily raise the=
current transaction volume 10x daily in the short term,=C2=A0 perhaps even=
100x a year from now after the media blows it out.</p>
<p dir=3D"ltr">Think legal bittorrent file sales: ebooks, indie music (albu=
ms and singles), films, art, stock photography.</p>
<p dir=3D"ltr">Think p2p amazon (OpenBazaar) and how that could grow expone=
ntially in terms of transactional volume when ecommerce penetrates geos cur=
rently underserved.</p>
<p dir=3D"ltr">Thanks for your explanations. it seems as of now we must rel=
y on the likes of centralized solutions like Bitpay, Coinbase to manage the=
transactional volume we expect, or just wait for the technology to be read=
y finally handle it in a real p2p fashion, no intermediaries. <br><br><br><=
/p>
<br><div class=3D"gmail_quote">On Sat, Jan 31, 2015, 6:04 PM=C2=A0Mike Hear=
n <<a href=3D"mailto:mike@plan99.net">mike@plan99.net</a>> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><span sty=
le=3D"color:rgb(0,0,0);font-family:NHG,'Helvetica Neue',Helvetica,A=
rial,sans-serif;font-size:14px;line-height:20px">"Alipay handled up to=
2.85 million transactions per minute, and 54 percent of its transactions a=
re made via mobile device."</span></div></div></blockquote><div><br></=
div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div>I know China is a very big place but even so - 47,50=
0 transactions per second would be almost quintiple what Visa handles acros=
s the entire world. With only 300 million users and primarily online usage =
(?) this claim feels a little suspect to me.</div><div><br></div><div>Given=
the wording "up to 2.85 million" I wonder if that is some freak =
spike caused by people's behaviour being synchronised externally (e.g. =
a fixed start time for the sale that people are waiting for). It's hard=
to imagine that they sustained anything close to that for the entire day.<=
/div><div><br></div><div>So this is really a discussion about peak performa=
nce.</div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">If=
you average every transaction around 250 bytes, then you'd need ~15 Gi=
gabytes per block to be broadcast and hashed by all the full nodes every 10=
minutes, eating good 2Tb of storage daily... do miners have enough bandwid=
th and CPU power to handle this?=C2=A0<br></div></blockquote><div><br></div=
></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div>There's a discussion of such things here that mig=
ht be useful:</div><div><br></div><div><a href=3D"https://en.bitcoin.it/wik=
i/Scalability" target=3D"_blank">https://en.bitcoin.it/wiki/Scalability</a>=
<br></div><div><br></div><div>It discusses various optimisations, like not =
actually sending tx data twice.</div><div><br></div><div>I wouldn't wor=
ry about it too much. It took decades for Visa to even approach 10,000 txns=
/sec. PayPal, I believe, still "only" handles a few hundred. And =
those services had the benefits of minimal competition, working in people&#=
39;s local currencies, integrated dispute mediation and not representing an=
y real threat to the political status quo. Bitcoin isn't going to be ne=
eding to handle Alipay's level of traffic any time soon.=C2=A0</div><di=
v><br></div><div>Frankly, scaling is a nice problem to have, it means you&#=
39;re popular. It'd be a mistake to just blindly assume Bitcoin will ta=
ke over the world. Growing market share is difficult. Worry more about how =
to get 300 million crazy users than the precise broadcast protocol that'=
;d be needed to handle them ;)</div></div></div></div>
</blockquote></div>
--001a1133d996fdfbd3050df84a5d--
|
