Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YHbTg-00042o-BO for bitcoin-development@lists.sourceforge.net; Sat, 31 Jan 2015 17:05:00 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.180 as permitted sender) client-ip=209.85.212.180; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f180.google.com; Received: from mail-wi0-f180.google.com ([209.85.212.180]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YHbTe-0007gK-TQ for bitcoin-development@lists.sourceforge.net; Sat, 31 Jan 2015 17:05:00 +0000 Received: by mail-wi0-f180.google.com with SMTP id h11so7946689wiw.1 for ; Sat, 31 Jan 2015 09:04:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.107.164 with SMTP id hd4mr6532715wib.7.1422723892853; Sat, 31 Jan 2015 09:04:52 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.9 with HTTP; Sat, 31 Jan 2015 09:04:52 -0800 (PST) In-Reply-To: References: Date: Sat, 31 Jan 2015 18:04:52 +0100 X-Google-Sender-Auth: 3FFYrVtnPeXtnw-m3cE_Pm089j8 Message-ID: From: Mike Hearn To: Angel Leon Content-Type: multipart/alternative; boundary=e89a8f3ba0853f4236050df5b8a7 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1YHbTe-0007gK-TQ Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 17:05:00 -0000 --e89a8f3ba0853f4236050df5b8a7 Content-Type: text/plain; charset=UTF-8 > > "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 ;) --e89a8f3ba0853f4236050df5b8a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"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 qui= ntiple what Visa handles across the entire world. With only 300 million use= rs and primarily online usage (?) this claim feels a little suspect to me.<= /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 a= re waiting for). It's hard to imagine that they sustained anything clos= e 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&#= 39;d need ~15 Gigabytes per block to be broadcast and hashed by all the ful= l nodes every 10 minutes, eating good 2Tb of storage daily... do miners hav= e enough bandwidth and CPU power to handle this?=C2=A0

There's a discussion of such things here that mig= ht be useful:

It discusses various optimisations, like not actually sending t= x data twice.

I wouldn't worry about it too mu= ch. It took decades for Visa to even approach 10,000 txns/sec. PayPal, I be= lieve, still "only" handles a few hundred. And those services had= the benefits of minimal competition, working in people's local currenc= ies, integrated dispute mediation and not representing any real threat to t= he political status quo. Bitcoin isn't going to be needing to handle Al= ipay's level of traffic any time soon.=C2=A0

F= rankly, scaling is a nice problem to have, it means you're popular. It&= #39;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 ha= ndle them ;)
--e89a8f3ba0853f4236050df5b8a7--