<div dir="ltr">Having observed the customer support nightmare it tends to cause for a small exchange service when 100% full blocks happen, I&#39;ve been thinking that the limit really should be dynamic and respond to demand and the amount of fees offered. It just doesn&#39;t feel right when it takes ages to burn through the backlog when 100% full is hit for a while. So, while pondering this, I got an idea that I think has a chance of working that I can&#39;t remember seeing suggested anywhere.<div><br></div><div>How about basing the maximum valid size for a block on the total bitcoin days destroyed in that block? That should still stop transaction spam but naturally expand the block size when there&#39;s a backlog of real transactions. It&#39;d also provide for an indirect mechanism for increasing the maximum block size based on fees if there&#39;s a lot of fees but little bitcoin days destroyed. In such a situation there&#39;d be incentive to pay someone to spend an older txout to expand the maximum. I realize this is a rather half baked idea, but it seems worth considering.</div><div><br></div><div><div>- Joel<br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 7, 2015 at 10:31 PM, Alan Reiner <span dir="ltr">&lt;<a href="mailto:etotheipi@gmail.com" target="_blank">etotheipi@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div 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&#39;s talks on
    increasing the block size, and the two most persuasive points to me
    were:<br>
    <br>
    (1) Blocks are essentially nearing &quot;full&quot; now.  And by &quot;full&quot; 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&#39;re very close to the effective limit in terms of maintaining the
    current &quot;standard of living&quot;, 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&#39;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&#39;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&#39;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&#39;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&#39;t believe 1 MB blocks were the correct answer.  I
    personally think this is critical to Bitcoin&#39;s long term future.  
    And I&#39;m not sure what else Gavin could&#39;ve done to push this along in
    a meaninful way.<span class="HOEnZb"><font color="#888888"><br>
    <br>
    -Alan</font></span><div><div class="h5"><br>
    <br>
    <br>
    <div>On 05/07/2015 02:06 PM, Mike Hearn
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <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 &quot;some urgency&quot; 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></fieldset>
      <br>
      </div></div><span class=""><pre>------------------------------------------------------------------------------
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 href="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target="_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a></pre>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Bitcoin-development mailing list
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>------------------------------------------------------------------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target="_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div></div></div></div>