public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Michael Naber <mickeybob@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it
Date: Tue, 30 Jun 2015 11:34:33 -0400	[thread overview]
Message-ID: <CALgxB7uvtKCNM-nH+aqqPa4KNf5O6Gx4GmgZY7Oq8=A24wCrfA@mail.gmail.com> (raw)

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

As you know I'm trying to lobby for a block size increase to a static 8MB.

I'm happy to try to get the testing done that people want done for this,
but I think the real crux of this issue is that we need to get consensus
that we intend to continually push the block size upward as bounded only by
technology.

Imagine an engineer (Gavin) at Boeing (Bitcoin Core) said he was going to
build an airplane (block) that was going to move 8x as many people
(transactions) as today’s planes (blocks), all while costing about the same
amount to operate. Imagine he then went on to tell you that he expects to
double the plane’s (block's) capacity every two years!

Without full planes (blocks), will the airlines (miners) go out of
business, since planes (blocks) will never be full and the cost to add
people (transactions) to a plane (block) will approach zero? Probably not.
Airlines (miners) still have to pay for pilots, security screening staff,
fuel, etc (engineers, hash rate, electricity, etc) so even if their
airplanes (blocks) can hold limitless people (transactions), they would
still have to charge sufficient fees to stay in business.

What tests do you need done to move to 8MB? Pitch in and help get those
tests done; agree that we'll run more tests next year or the year after
when technology might allow for 16 MB blocks. Do you really want to be the
guy holding back bigger planes? Do you really want to artificially
constrain block size below what technology allows?

In the face of such strong market demand for increased capacity in globally
aware global consensus, do you really think you can prevent supply from
meeting demand when the technology exists to deliver it? Do you really want
to force a fork because you and others won't agree to a simple raise to a
static 8MB?

Do what's best for Bitcoin and define what needs to get done to agree to a
simple block size increase to a static 8MB.

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

             reply	other threads:[~2015-06-30 15:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30 15:34 Michael Naber [this message]
2015-06-30 16:03 ` [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it Richard Moore
2015-06-30 16:15 ` Venzen Khaosan
2015-06-30 16:25   ` Peter Todd
2015-06-30 16:35     ` Michael Naber
2015-06-30 19:59       ` Bryan Cheng

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='CALgxB7uvtKCNM-nH+aqqPa4KNf5O6Gx4GmgZY7Oq8=A24wCrfA@mail.gmail.com' \
    --to=mickeybob@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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