Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.176 as permitted sender)
	client-ip=209.85.216.176; envelope-from=etotheipi@gmail.com;
	helo=mail-qc0-f176.google.com; 
Message-ID: <554BBDA2.7040508@gmail.com>
Date: Thu, 07 May 2015 15:31:46 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <554A91BE.6060105@bluematt.me>	<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>	<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>	<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>	<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>	<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>	<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>	<554BA032.4040405@bluematt.me>	<CANEZrP3yM9wsSPNgpOsXDk-DjUy5PW2XuRTvK2AyCNbVJ5hZHw@mail.gmail.com>	<CADJgMzti7ROH90APiwg4NOAT5+Av=4i295b8VN0sbSLr4+WWRw@mail.gmail.com>
	<CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
In-Reply-To: <CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------090900060507010707030009"
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

This is a multi-part message in MIME format.
--------------090900060507010707030009
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this.  I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:

(1) Blocks are essentially nearing "full" now.  And by "full" he means
that the reliability of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks).  I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions.  In other words, we're very close to the
effective limit in terms of maintaining the current "standard of
living", and with a year needed to raise the block time this actually is
urgent.

(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea.  It's really bad while Bitcoin is still growing, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability).  But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system.  It is a couple orders of magnitude too low
for any meaningful commercial activity to occur.  If we continue with a
cap of 7 tps forever, Bitcoin *will* fail.  Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure).  We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low. 

You can argue that side chains and payment channels could alleviate
this.  But how far off are they?  We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way.  Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.

We get asked all the time by corporate clients about scalability.  A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle.  We always assure them that 7 tps
is not the final answer. 

Satoshi didn't believe 1 MB blocks were the correct answer.  I
personally think this is critical to Bitcoin's long term future.   And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.

-Alan


On 05/07/2015 02:06 PM, Mike Hearn wrote:
>
>     I think you are rubbing against your own presupposition that
>     people must find and alternative right now. Quite a lot here do
>     not believe there is any urgency, nor that there is an immanent
>     problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all
> over again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--------------090900060507010707030009
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    This *is* urgent and needs to be handled right now, and I believe
    Gavin has the best approach to this.  I have heard Gavin's talks on
    increasing the block size, and the two most persuasive points to me
    were:<br>
    <br>
    (1) Blocks are essentially nearing "full" now.  And by "full" he
    means that the reliability of the network (from the average user
    perspective) is about to be impacted in a very negative way (I
    believe it was due to the inconsistent time between blocks).  I
    think Gavin said that his simulations showed 400 kB - 600 kB worth
    of transactions per 10 min (approx 3-4 tps) is where things start to
    behave poorly for certain classes of transactions.  In other words,
    we're very close to the effective limit in terms of maintaining the
    current "standard of living", and with a year needed to raise the
    block time this actually is urgent.<br>
    <br>
    (2) Leveraging fee pressure at 1MB to solve the problem is actually
    really a bad idea.  It's really bad while Bitcoin is still growing,
    and relying on fee pressure at 1 MB severely impacts attractiveness
    and adoption potential of Bitcoin (due to high fees and
    unreliability).  But more importantly, it ignores the fact that for
    a 7 tps is pathetic for a global transaction system.  It is a couple
    orders of magnitude too low for any meaningful commercial activity
    to occur.  If we continue with a cap of 7 tps forever, Bitcoin <b>will</b>
    fail.  Or at best, it will fail to be useful for the vast majority
    of the world (which probably leads to failure).  We shouldn't be
    talking about fee pressure until we hit 700 tps, which is probably
    still too low.  <br>
    <br>
    You can argue that side chains and payment channels could alleviate
    this.  But how far off are they?  We're going to hit effective 1MB
    limits long before we can leverage those in a meaningful way.  Even
    if everyone used them, getting a billion people onto the system just
    can't happen even at 1 transaction per year per person to get into a
    payment channel or move money between side chains.<br>
    <br>
    We get asked all the time by corporate clients about scalability.  A
    limit of 7 tps makes them uncomfortable that they are going to
    invest all this time into a system that has no chance of handling
    the economic activity that they expect it handle.  We always assure
    them that 7 tps is not the final answer.  <br>
    <br>
    Satoshi didn't believe 1 MB blocks were the correct answer.  I
    personally think this is critical to Bitcoin's long term future.  
    And I'm not sure what else Gavin could've done to push this along in
    a meaninful way.<br>
    <br>
    -Alan<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/07/2015 02:06 PM, Mike Hearn
      wrote:<br>
    </div>
    <blockquote
cite="mid:CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">
                <div class="gmail_extra">
                  <div class="gmail_quote">
                    <div>I think you are rubbing against your own
                      presupposition that people must find and
                      alternative right now. Quite a lot here do not
                      believe there is any urgency, nor that there is an
                      immanent problem that has to be solved before the
                      sky falls in.</div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I have explained why I believe there is some urgency,
              whereby "some urgency" I mean, assuming it takes months to
              implement, merge, test, release and for people to upgrade.</div>
            <div><br>
            </div>
            <div>But if it makes you happy, imagine that this discussion
              happens all over again next year and I ask the same
              question.</div>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
<a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------090900060507010707030009--