From: Jim Phillips <jim@ergophobia.org>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
Date: Mon, 25 May 2015 21:26:42 -0500 [thread overview]
Message-ID: <CANe1mWz4qTOw8JYC-m8x6ajdLfm+Y__L1jn+W0HmNhCJ0tX4Kw@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3AbNOW8G-4SyNZNLbD56TrB9c0zz8SCZPFacxDzDVt=g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2973 bytes --]
On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <mike@plan99.net> wrote:
This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down
> right now, but I showed years ago that you could keep up with VISA on a
> single well specced server with today's technology. Only people living in a
> dreamworld think that Bitcoin might actually have to match that level of
> transaction demand with today's hardware. As noted previously, "too many
> users" is simply not a problem Bitcoin has .... and may never have!
>
>
... And will certainly NEVER have if we can't solve the capacity problem
SOON.
In a former life, I was a capacity planner for Bank of America's mid-range
server group. We had one hard and fast rule. When you are typically
exceeding 75% of capacity on a given metric, it's time to expand capacity.
Period. You don't do silly things like adjusting the business model to
disincentivize use. Unless there's some flaw in the system and it's leaking
resources, if usage has increased to the point where you are at or near the
limits of capacity, you expand capacity. It's as simple as that, and I've
found that same rule fits quite well in a number of systems.
In Bitcoin, we're not leaking resources. There's no flaw. The system is
performing as intended. Usage is increasing because it works so well, and
there is huge potential for future growth as we identify more uses and
attract more users. There might be a few technical things we can do to
reduce consumption, but the metric we're concerned with right now is how
many transactions we can fit in a block. We've broken through the 75%
marker and are regularly bumping up against the 100% limit.
It is time to stop debating this and take action to expand capacity. The
only questions that should remain are how much capacity do we add, and how
soon can we do it. Given that most existing computer systems and networks
can easily handle 20MB blocks every 10 minutes, and given that that will
increase capacity 20-fold, I can't think of a single reason why we can't go
to 20MB as soon as humanly possible. And in a few years, when the average
block size is over 15MB, we bump it up again to as high as we can go then
without pushing typical computers or networks beyond their capacity. We can
worry about ways to slow down growth without affecting the usefulness of
Bitcoin as we get closer to the hard technical limits on our capacity.
And you know what else? If miners need higher fees to accommodate the costs
of bigger blocks, they can configure their nodes to only mine transactions
with higher fees.. Let the miners decide how to charge enough to pay for
their costs. We don't need to cripple the network just for them.
--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*
*This message was created with 100% recycled electrons. Please think twice
before printing.*
[-- Attachment #2: Type: text/html, Size: 4450 bytes --]
next prev parent reply other threads:[~2015-05-26 2:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 15:22 [Bitcoin-development] No Bitcoin For You Tom Harding
2015-05-17 2:31 ` Ryan X. Charles
2015-05-25 18:36 ` Mike Hearn
2015-05-26 2:26 ` Jim Phillips [this message]
2015-05-26 2:30 Thy Shizzle
2015-05-26 2:41 ` gabe appleton
2015-05-26 2:53 ` Jim Phillips
2015-05-26 2:51 Thy Shizzle
2015-05-26 3:02 Thy Shizzle
2015-05-26 3:23 ` Jim Phillips
2015-05-26 3:49 ` Jim Phillips
2015-05-26 5:43 ` gabe appleton
2015-05-26 8:29 ` Jim Phillips
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=CANe1mWz4qTOw8JYC-m8x6ajdLfm+Y__L1jn+W0HmNhCJ0tX4Kw@mail.gmail.com \
--to=jim@ergophobia.org \
--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