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 ) 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 ; 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> <554BA032.4040405@bluematt.me> <554BBDA2.7040508@gmail.com> Date: Fri, 8 May 2015 04:51:35 +0300 Message-ID: From: Joel Joonatan Kaartinen To: Bitcoin Development 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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 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't remember seeing suggested anywhere.

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's a backlog of real transactions. It= 'd also provide for an indirect mechanism for increasing the maximum bl= ock 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:
=20 =20 =20
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's tal= ks on increasing the block size, and the two most persuasive points to me were:

(1) Blocks are essentially nearing "full" now.=C2=A0 And by &= quot;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).=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'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.=C2=A0 It'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 = will 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't = be talking about fee pressure until we hit 700 tps, which is probably still too low.=C2=A0

You can argue that side chains and payment channels could alleviate this.=C2=A0 But how far off are they?=C2=A0 We'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'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.=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

Satoshi didn't believe 1 MB blocks were the correct answer.=C2=A0 I personally think this is critical to Bitcoin's long term future. = =C2=A0 And I'm not sure what else Gavin could've done to push this alo= ng 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 mo= nths 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=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.
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-de=
velopment


-----------------------------------------------------------------------= -------
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e013d04eeb1c2dd05158844fa--