public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ken Friece <kfriece@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Analysis paralysis and the blocksize debate
Date: Thu, 6 Aug 2015 12:33:13 -0400	[thread overview]
Message-ID: <CAKujSOFC+8DaGjpQ06iVkZGFUBnSs6fhW2aPFFJLXYoAJDbB2g@mail.gmail.com> (raw)

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

I am a long time Bitcoin user, miner, investor, full node operator, and
distributed real-time system software engineer.

Out of the all currently proposed blocksize increase solutions, I support
BIP101 (or something like it) and find the current blocksize debate very
frustrating, so I will try to systematically debunk some common arguments
against BIP101 below.

   1.

   We should not increase the blocksize because we'll just end up hitting
   the limit again at a future time.


   -

      If a reasonable blocksize increase like BIP101 that scales with
      technology is implemented, it's not a given that we will hit the
blocksize
      limit (consistently full blocks over an extended period of time) again in
      the future. Stating that we will definitely hit the blocksize limit again
      in the future is pure speculation about future bitcoin transaction volume
      that can't possibly be known at this time, and is nothing but conjecture.
      If technology increases faster than bitcoin transaction volume, simply
      scaling the Bitcoin blocksize could keep up with future demand.
If Bitcoin
      is successful beyond our wildest dreams and future transaction volume
      outstrips future blockchain space, alternative solutions like
sidechains or
      the lightning network will have more time to be implemented.


   1.

   The full node count will go down if we increase the blocksize because it
   will be more costly to run a full node.


   -

      I'm not sure this is true. I currently run a full node on a higher
      end consumer PC with a higher end home network connection, but if the
      blocksize limit is not raised and transaction fees increase such
that it is
      no longer economical for me to access the bitcoin blockchain directly, I
      will no longer run a full node to support the network. Bitcoin
is no longer
      interesting to me if it gets to the point where the average user
is priced
      off the blockchain. Users that have direct access to the blockchain are
      more likely to run full nodes. If Bitcoin ever becomes purely a limited,
      small settlement network, I will no longer support it and move onto
      something else.


   1.

   The blocksize can only be increased if there is developer “consensus”
   and the change is not “controversial”.


   -

      Any blocksize increase will the deemed “controversial” and lack
      “consensus”, but doing nothing in the face of consistently full
blocks and
      rising transaction fees is also “controversial” and will lack
“consensus”.
      Inaction, maintaining the status quo, and blocking a blocksize
increase in
      the face of consistently full blocks and rising transaction fees
is just as
      controversial as increasing the blocksize.


   1.

   Don't increase the blocksize now with all the promising work going on
   with sidechains and the lightning network.


   -

      KISS (keep it simple, stupid). When dealing with a highly complex,
      mission critical system, there needs to be a very compelling reason to
      choose a much more complex solution over a simple solution like BIP101.
      Sidechains and the lightning network are much more complex than
BIP101 and
      introduce new points of failure. It's hard enough to get folks
to trust the
      Bitcoin network after 7 years, so it will likely take years until
      sidechains and the lightning network are proven enough to be trusted by
      users.


   1.

   Some miners will be at a disadvantage with larger blocks.


   -

      As folks have pointed out multiple times, network speed is just one
      of many variables that impact mining profitability. I don't believe for a
      second that every miner in China (57% of the network) would be negatively
      impacted by larger blocks because some of them either have decent network
      connections or connect to mining pools with decent network connections.
      Miners will be given ample notice of a blocksize increase before
it occurs,
      so they will have time to make plans to deal with larger blocks. More
      transactions per block should also increase miner profitability because
      more transactions equals more users equals more transaction fees!

In conclusion, I think the next year is a make or break year for Bitcoin
and hope the developers do everything they can to come up with a reasonable
long term growth plan to put Bitcoin in the best possible position to be
successful.

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

                 reply	other threads:[~2015-08-06 16:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=CAKujSOFC+8DaGjpQ06iVkZGFUBnSs6fhW2aPFFJLXYoAJDbB2g@mail.gmail.com \
    --to=kfriece@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