public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Angel Leon <gubatron@gmail.com>
To: Mike Hearn <mike@plan99.net>
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?
Date: Sat, 31 Jan 2015 20:08:57 +0000	[thread overview]
Message-ID: <CADZB0_YYXto3SJjq2FcZPUKwsHas3chmgdcxhwhU_Hh6QO1vZg@mail.gmail.com> (raw)
In-Reply-To: CANEZrP3+ca9Bumv=-2ot7T5s6cvGhN_dMqYmsxP7qP1V0WV4qg@mail.gmail.com

[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]

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 ;)
>

[-- Attachment #2: Type: text/html, Size: 4191 bytes --]

      reply	other threads:[~2015-01-31 20:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-31  0:48 [Bitcoin-development] Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today? Angel Leon
2015-01-31  2:58 ` Nick Simpson
2015-01-31 13:11   ` Wladimir
2015-02-01  6:50     ` Tom Harding
2015-01-31  2:58 ` Allen Piscitello
2015-01-31 17:04 ` Mike Hearn
2015-01-31 20:08   ` Angel Leon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADZB0_YYXto3SJjq2FcZPUKwsHas3chmgdcxhwhU_Hh6QO1vZg@mail.gmail.com \
    --to=gubatron@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox