path: root/74/44d38f0b93d761d835813aa7e62ee246fc4ced

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <joel.kaartinen@gmail.com>) id 1YqXS2-0006BN-V8
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 01:51:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.173 as permitted sender)
	client-ip=209.85.214.173; envelope-from=joel.kaartinen@gmail.com;
	helo=mail-ob0-f173.google.com; 
Received: from mail-ob0-f173.google.com ([209.85.214.173])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqXS1-0005tf-6j
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 01:51:42 +0000
Received: by obbkp3 with SMTP id kp3so45434477obb.3
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 07 May 2015 18:51:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.35.42 with SMTP id e10mr1225934oej.26.1431049895787; Thu,
	07 May 2015 18:51:35 -0700 (PDT)
Received: by 10.202.49.16 with HTTP; Thu, 7 May 2015 18:51:35 -0700 (PDT)
In-Reply-To: <554BBDA2.7040508@gmail.com>
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>
	<554BBDA2.7040508@gmail.com>
Date: Fri, 8 May 2015 04:51:35 +0300
Message-ID: <CAGKSKfX2We2OmNPRKNMN5VtykTGVi8szfJp+QZG6yvyVvrWVdQ@mail.gmail.com>
From: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e013d04eeb1c2dd05158844fa
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(joel.kaartinen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YqXS1-0005tf-6j
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 01:51:43 -0000

--089e013d04eeb1c2dd05158844fa
Content-Type: text/plain; charset=UTF-8

Having observed the customer support nightmare it tends to cause for a
small exchange service when 100% full blocks happen, I've been thinking
that the limit really should be dynamic and respond to demand and the
amount of fees offered. It just doesn'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't remember seeing suggested anywhere.

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's a backlog of real
transactions. It'd also provide for an indirect mechanism for increasing
the maximum block size based on fees if there's a lot of fees but little
bitcoin days destroyed. In such a situation there'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.

- Joel

On Thu, May 7, 2015 at 10:31 PM, Alan Reiner <etotheipi@gmail.com> wrote:

>  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 listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

--089e013d04eeb1c2dd05158844fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"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 tak=
es 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 th=
at I can&#39;t remember seeing suggested anywhere.<div><br></div><div>How a=
bout basing the maximum valid size for a block on the total bitcoin days de=
stroyed in that block? That should still stop transaction spam but naturall=
y 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 bl=
ock 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=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, May 7, 2015 at 10:31 PM, Alan Reiner <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:etotheipi@gmail.com" target=3D"_blank">etotheipi@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    This *is* urgent and needs to be handled right now, and I believe
    Gavin has the best approach to this.=C2=A0 I have heard Gavin&#39;s tal=
ks 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.=C2=A0 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).=C2=A0 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.=C2=A0 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.=C2=A0 It&#39;s really bad while Bitcoin is still gro=
wing,
    and relying on fee pressure at 1 MB severely impacts attractiveness
    and adoption potential of Bitcoin (due to high fees and
    unreliability).=C2=A0 But more importantly, it ignores the fact that fo=
r
    a 7 tps is pathetic for a global transaction system.=C2=A0 It is a coup=
le
    orders of magnitude too low for any meaningful commercial activity
    to occur.=C2=A0 If we continue with a cap of 7 tps forever, Bitcoin <b>=
will</b>
    fail.=C2=A0 Or at best, it will fail to be useful for the vast majority
    of the world (which probably leads to failure).=C2=A0 We shouldn&#39;t =
be
    talking about fee pressure until we hit 700 tps, which is probably
    still too low.=C2=A0 <br>
    <br>
    You can argue that side chains and payment channels could alleviate
    this.=C2=A0 But how far off are they?=C2=A0 We&#39;re going to hit effe=
ctive 1MB
    limits long before we can leverage those in a meaningful way.=C2=A0 Eve=
n
    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.=C2=A0=
 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.=C2=A0 We always assur=
e
    them that 7 tps is not the final answer.=C2=A0 <br>
    <br>
    Satoshi didn&#39;t believe 1 MB blocks were the correct answer.=C2=A0 I
    personally think this is critical to Bitcoin&#39;s long term future. =
=C2=A0
    And I&#39;m not sure what else Gavin could&#39;ve done to push this alo=
ng in
    a meaninful way.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
    <br>
    -Alan</font></span><div><div class=3D"h5"><br>
    <br>
    <br>
    <div>On 05/07/2015 02:06 PM, Mike Hearn
      wrote:<br>
    </div>
    </div></div><blockquote type=3D"cite"><div><div class=3D"h5">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
              <div dir=3D"ltr">
                <div class=3D"gmail_extra">
                  <div class=3D"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 mo=
nths to
              implement, merge, test, release and for people to upgrade.</d=
iv>
            <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=3D""><pre>-----------------------------------=
-------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud=20
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=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a></pr=
e>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Bitcoin-development mailing list
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</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=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div></div></div>

--089e013d04eeb1c2dd05158844fa--