From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5FGU-0006Te-Pi for bitcoin-development@lists.sourceforge.net; Wed, 17 Jun 2015 15:28:34 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of hotmail.com designates 65.55.34.217 as permitted sender) client-ip=65.55.34.217; envelope-from=raystonn@hotmail.com; helo=COL004-OMC4S15.hotmail.com; Received: from col004-omc4s15.hotmail.com ([65.55.34.217]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z5FGT-0007Rf-5i for bitcoin-development@lists.sourceforge.net; Wed, 17 Jun 2015 15:28:34 +0000 Received: from COL131-DS14 ([65.55.34.199]) by COL004-OMC4S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Wed, 17 Jun 2015 08:28:27 -0700 X-TMN: [pGXl6ZnoGUL2w74rJlOxGubDF35kzeSS] X-Originating-Email: [raystonn@hotmail.com] Message-ID: From: "Raystonn ." To: "Mike Hearn" , "Adam Back" References: In-Reply-To: Date: Wed, 17 Jun 2015 08:28:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01D0A8D7.898F2880" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-OriginalArrivalTime: 17 Jun 2015 15:28:27.0519 (UTC) FILETIME=[41FA90F0:01D0A912] X-Spam-Score: 0.0 (/) 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 (raystonn[at]hotmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.34.217 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message 1.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5FGT-0007Rf-5i Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] soft-fork block size increase(extensionblocks) 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: Wed, 17 Jun 2015 15:28:34 -0000 ------=_NextPart_000_0026_01D0A8D7.898F2880 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wow. That email was delayed by the list for quite some time. It was = sent on 6/1. From: Raystonn .=20 Sent: Monday, June 01, 2015 12:02 PM To: Mike Hearn ; Adam Back=20 Cc: Bitcoin Dev=20 Subject: Re: [Bitcoin-development] soft-fork block size = increase(extensionblocks) I also need to argue for increasing the default block limit to the full = 1MB in the next release. We=E2=80=99re already hitting that limit in = bursts of transactions, which puts pressure on the average displayed in = the below graphs. From: raystonn@hotmail.com=20 Sent: Monday, June 01, 2015 11:39 AM To: Mike Hearn ; Adam Back=20 Cc: Bitcoin Dev=20 Subject: Re: [Bitcoin-development] soft-fork block size increase = (extensionblocks) > And we're not going to get to VISA scale any time soon No, not at these block size limits. The closer we get to the maximum = block size, the slower we grow the average block size toward it. Number = of transactions per day is of course highly correlated with average = block size. Based on these graphs we can expect that hitting 1 million = transactions per day will be impossible without raising the maximum = block size. https://blockchain.info/charts/avg-block-size?showDataPoints=3Dfalse&show= _header=3Dtrue&daysAverageString=3D7×pan=3Dall&scale=3D1&address=3D https://blockchain.info/charts/n-transactions?showDataPoints=3Dfalse&time= span=3Dall&show_header=3Dtrue&daysAverageString=3D7&scale=3D1&address=3D = From: Mike Hearn=20 Sent: Monday, June 01, 2015 11:01 AM To: Adam Back=20 Cc: Bitcoin Dev=20 Subject: Re: [Bitcoin-development] soft-fork block size increase = (extensionblocks) (at reduced security if it has software that doesnt understand it)=20 Well, yes. Isn't that rather key to the issue? Whereas by simply = increasing the block size, SPV wallets don't care (same security and = protocol as before) and fully validating wallets can be updated with a = very small code change. A 1MB client wont even understand the difference between a 1MB and 8MB out payment.=20 Let's say an old client makes a payment that only gets confirmed in an = extension block. The wallet will think the payment is unconfirmed and = show that to the user forever, no? Can you walk through the UX for each case? If I am not misremembering, I think you've sided typically with the huge block, big data center only end of the spectrum. =20 It would be Satoshi, that argued that. I think there must be a communication issue here somewhere. I'm not sure = how this meme has taken hold amongst you guys, as I am the guy who wrote = the scalability page back in 2011: https://en.bitcoin.it/wiki/Scalability It says: The core Bitcoin network can scale to much higher transaction rates = than are seen today, assuming that nodes in the network are primarily = running on high end servers rather than desktops.=20 By "much higher rates" I meant VISA scale and by "high end server" I = meant high end by today's standards not tomorrows. There's a big = difference between a datacenter and a single server! By definition a = single server is not a datacenter, although it would be conventional to = place it in one. But even with the most wildly optimistic growth = imaginable, I couldn't foresee a time when you needed more than a single = machine to keep up with the transaction stream.=20 And we're not going to get to VISA scale any time soon: I don't think = I've ever argued we will. If it does happen it would presumably be = decades away. Again, short of some currently unimagined killer app. So I don't believe I've ever argued this, and honestly I kinda feel = people are putting words in my mouth. -------------------------------------------------------------------------= ------- -------------------------------------------------------------------------= ----- -------------------------------------------------------------------------= ------- _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -------------------------------------------------------------------------= ------- -------------------------------------------------------------------------= ----- -------------------------------------------------------------------------= ------- _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ------=_NextPart_000_0026_01D0A8D7.898F2880 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wow.  That email was delayed by the list for quite some = time.  It=20 was sent on 6/1.
From: Raystonn .
Sent: Monday, June 01, 2015 12:02 PM
Subject: Re: [Bitcoin-development] soft-fork block size=20 increase(extensionblocks)
 
I also need to argue for increasing the default block limit to the = full 1MB=20 in the next release.  We=E2=80=99re already hitting that limit in = bursts of=20 transactions, which puts pressure on the average displayed in the below=20 graphs.
 
Sent: Monday, June 01, 2015 11:39 AM
Subject: Re: [Bitcoin-development] soft-fork block size = increase=20 (extensionblocks)
 
> And = we're not going=20 to get to VISA scale any time soon
 
No, not at these block size limits.  = The closer=20 we get to the maximum block size, the slower we grow the average block = size=20 toward it.  Number of transactions per day is of course highly = correlated=20 with average block size.  Based on these graphs we can expect that = hitting=20 1 million transactions per day will be impossible without raising the = maximum=20 block size.
 
 
https://blockchain.info/charts/avg-block-siz= e?showDataPoints=3Dfalse&show_header=3Dtrue&daysAverageString=3D7= &timespan=3Dall&scale=3D1&address=3D
 
 
 
https://blockchain.info/charts/n-transaction= s?showDataPoints=3Dfalse&timespan=3Dall&show_header=3Dtrue&da= ysAverageString=3D7&scale=3D1&address=3D=20
 
 
 
From: Mike Hearn
Sent: Monday, June 01, 2015 11:01 AM
Subject: Re: [Bitcoin-development] soft-fork block size = increase=20 (extensionblocks)
 
(at=20 reduced security if it has software that doesnt understand it) =
 
Well, yes. Isn't that rather key to the issue?  Whereas by = simply=20 increasing the block size, SPV wallets don't care (same security and = protocol as=20 before) and fully validating wallets can be updated with a very small = code=20 change.
 
A=20 1MB client wont even understand the difference between a 1MB and = 8MB
out=20 payment.
 
Let's say an old client makes a payment that only gets confirmed in = an=20 extension block. The wallet will think the payment is unconfirmed and = show that=20 to the user forever, no?
 
Can you walk through the UX for each case?
 
If=20 I am not misremembering, I think you've sided typically
with the = huge=20 block, big data center only end of the spectrum. 
 
It would be Satoshi, that argued that.
 
I think there must be a communication issue here somewhere. I'm not = sure=20 how this meme has taken hold amongst you guys, as I am the guy who wrote = the=20 scalability page back in 2011:
 
https://en.bitcoin.it/wik= i/Scalability
 
It says:
 
The=20 core Bitcoin network can scale to much higher transaction rates than = are seen=20 today, assuming that nodes in the network are primarily running on = high end=20 servers rather than desktops. =

By=20 "much higher rates" I meant VISA scale and by "high end server" I meant = high end=20 by today's standards not tomorrows. There's a big difference between a=20 datacenter and a single server! By=20 definition a single server is not a datacenter, although it would be=20 conventional to place it in one. But even=20 with the most wildly optimistic growth imaginable, I couldn't foresee a = time=20 when you needed more than a single machine to keep up with the = transaction=20 stream.

And=20 we're not going to get to VISA scale any time soon: I don't think I've = ever=20 argued we will. If it does happen it would presumably be decades away. = Again,=20 short of some currently unimagined killer app.

So I=20 don't believe I've ever argued this, and honestly I kinda feel people = are=20 putting words in my mouth.

-------------------------------------------------------------------------= -----

_______________________________________________
Bitcoin-development = mailing=20 list
Bitcoin-development@lists.sourceforge.net
https://lists.source= forge.net/lists/listinfo/bitcoin-development
<= /DIV>

-------------------------------------------------------------------------= -----

_______________________________________________
Bitcoin-development = mailing=20 list
Bitcoin-development@lists.sourceforge.net
https://lists.source= forge.net/lists/listinfo/bitcoin-development
= ------=_NextPart_000_0026_01D0A8D7.898F2880--