Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C44D28CE for ; Thu, 6 Aug 2015 16:33:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F2DB16F for ; Thu, 6 Aug 2015 16:33:15 +0000 (UTC) Received: by lbbtg9 with SMTP id tg9so8212487lbb.1 for ; Thu, 06 Aug 2015 09:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Q9jGgWSGLxcu/pXzIv3dKCys1H4NQ+EOMyipFmoH70s=; b=DJbdz0xD1RRYTjG7rtecSrig7RNptZ4h/V/yD8eXPttiFgPy4LQZz70T/JKay4Z2YT 379x6ixWFp5748HLxbJYX981q9m86Oe4IR72WlQRDXRLhzgMky+rn5w1xEsTGPePbdG3 jhnLvxk3/fFv/gWU04dyRQgcynPWISHimoY7ytfzroG2+FJtlhgfj+7srmvq9InbosSw Waz0qi5c4asHsNzUFaYbfM7nG7sRWXMFj89qejtycJolnEWMcVn5wfmU68mEzD5jYM4B z/aIkjw4Dxl/h0+jImZSxRuXbuO0jgjzuMC8flkDMn61cUiULYrpXMeBDc87qagxxhsI Stbw== MIME-Version: 1.0 X-Received: by 10.112.164.74 with SMTP id yo10mr3189369lbb.124.1438878793386; Thu, 06 Aug 2015 09:33:13 -0700 (PDT) Received: by 10.25.145.199 with HTTP; Thu, 6 Aug 2015 09:33:13 -0700 (PDT) Date: Thu, 6 Aug 2015 12:33:13 -0400 Message-ID: From: Ken Friece To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11c25ba25ad23e051ca713db X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Analysis paralysis and the blocksize debate X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:33:16 -0000 --001a11c25ba25ad23e051ca713db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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) agai= n in the future. Stating that we will definitely hit the blocksize limit a= gain in the future is pure speculation about future bitcoin transaction vo= lume that can't possibly be known at this time, and is nothing but conject= ure. If technology increases faster than bitcoin transaction volume, simpl= y 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 a= re more likely to run full nodes. If Bitcoin ever becomes purely a limit= ed, 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 =E2=80=9Cconse= nsus=E2=80=9D and the change is not =E2=80=9Ccontroversial=E2=80=9D. - Any blocksize increase will the deemed =E2=80=9Ccontroversial=E2=80= =9D and lack =E2=80=9Cconsensus=E2=80=9D, but doing nothing in the face of consist= ently full blocks and rising transaction fees is also =E2=80=9Ccontroversial=E2=80=9D and w= ill lack =E2=80=9Cconsensus=E2=80=9D. 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 t= o choose a much more complex solution over a simple solution like BIP10= 1. 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 f= or a second that every miner in China (57% of the network) would be negati= vely impacted by larger blocks because some of them either have decent net= work connections or connect to mining pools with decent network connection= s. 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 becau= se 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. --001a11c25ba25ad23e051ca713db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 futur= e 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.=20

  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 b= e increased if there is developer =E2=80=9Cconsensus=E2=80=9D and the change= is not =E2=80=9Ccontroversial=E2=80=9D.

    =09

    • Any blocksize increase will the deemed =E2=80=9Ccontroversial=E2=80=9D and lack =E2=80=9Cconsensus=E2=80= =9D, but doing nothing in the face of consistently full blocks and rising transaction fees is also =E2=80=9Ccontroversial=E2=80=9D and will lack =E2=80=9Cconsensus=E2=80=9D. 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 b= locksize now with all the promising work going on with sidechains and the lightning network.

    =09

    • 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.

    =09

    • 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!=20

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.

--001a11c25ba25ad23e051ca713db--