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