From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yx4xx-0004s3-JE for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 02:51:41 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of outlook.com designates 65.54.190.210 as permitted sender) client-ip=65.54.190.210; envelope-from=thyshizzle@outlook.com; helo=BAY004-OMC4S8.hotmail.com; Received: from bay004-omc4s8.hotmail.com ([65.54.190.210]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Yx4xv-0002uW-Lw for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 02:51:41 +0000 Received: from BAY403-EAS100 ([65.54.190.201]) by BAY004-OMC4S8.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 25 May 2015 19:51:33 -0700 X-TMN: [R6n3b/hDNSIuIfr9PL0mjxGFm2OEHXyS] X-Originating-Email: [thyshizzle@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_0864ac4b-0e08-403e-a223-bea3050b8535_" MIME-Version: 1.0 To: gabe appleton From: Thy Shizzle Date: Tue, 26 May 2015 12:51:00 +1000 X-OriginalArrivalTime: 26 May 2015 02:51:33.0974 (UTC) FILETIME=[E04F0760:01D0975E] X-Spam-Score: -0.5 (/) 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 (thyshizzle[at]outlook.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.54.190.210 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_REMOTE_IMAGE Message contains an external image X-Headers-End: 1Yx4xv-0002uW-Lw Cc: Dev , Bitcoin Subject: Re: [Bitcoin-development] No Bitcoin For You 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: Tue, 26 May 2015 02:51:41 -0000 --_0864ac4b-0e08-403e-a223-bea3050b8535_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I wouldn't say same trade-off because you need the whole 20mb block before = you can start to use it where as a 1mb block can be used quicker thus trans= actions found in tge block quicker etc. As for tge higher rate of orphans= =2C I think this would be complimented by a faster correction rate=2C so if= you're pumping out blocks at a rate of 1 per minute=2C if we get a fork an= d the next block comes in 10 minutes and is the decider=2C it took 10 minut= es to determine which block is the orphan. But at a rate of 1 block per 1 m= inute then it only takes 1 minute to resolve the orphan (obviously this is = very simplified) so I'm not so sure that orphan rate is a big issue here. I= ndeed you would need to draw upon more confirmations for easier block creat= ion but surely that is not an issue? Why would sync time be longer as opposed to 20mb blocks? ________________________________ From: gabe appleton Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:41 PM To: Thy Shizzle Cc: Jim Phillips=3B Mike Hearn=3B Bitcoin Dev Subject: Re: [Bitcoin-development] No Bitcoin For You But don't you see the same trade-off in the end there? You're still propagating the same amount of data over the same amount of time=2C so unle= ss I misunderstand=2C the costs of such a move should be approximately the sam= e=2C just in different areas. The risks as I understand are as follows: 20MB: 1. Longer per-block propagation (eventually) 2. Longer processing time (eventually) 3. Longer sync time 1 Minute: 1. Weaker individual confirmations (approx. equal per confirmation*time) 2. Higher orphan rate (immediately) 3. Longer sync time That risk-set makes me want a middle-ground approach. Something where the immediate consequences aren't all that strong=2C and where we have some ide= a of what to do in the future. Is there any chance we can get decent network simulations at various configurations (5MB/4min=2C etc)? Perhaps re-appropriate the testnet? On Mon=2C May 25=2C 2015 at 10:30 PM=2C Thy Shizzle wrote: > Nah don't make blocks 20mb=2C then you are slowing down block propagatio= n > and blowing out conf tikes as a result. Just decrease the time it takes t= o > make a 1mb block=2C then you still see the same propagation times today a= nd > just increase the transaction throughput. > ------------------------------ > From: Jim Phillips > Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM > To: Mike Hearn > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] No Bitcoin For You > > > On Mon=2C May 25=2C 2015 at 1:36 PM=2C Mike Hearn wrote= : > > This meme about datacenter-sized nodes has to die. The Bitcoin wiki is > down right now=2C but I showed years ago that you could keep up with VISA= on > a single well specced server with today's technology. Only people living = in > a dreamworld think that Bitcoin might actually have to match that level o= f > transaction demand with today's hardware. As noted previously=2C "too man= y > users" is simply not a problem Bitcoin has .... and may never have! > > > ... And will certainly NEVER have if we can't solve the capacity problem > SOON. > > In a former life=2C I was a capacity planner for Bank of America's > mid-range server group. We had one hard and fast rule. When you are > typically exceeding 75% of capacity on a given metric=2C it's time to exp= and > capacity. Period. You don't do silly things like adjusting the business > model to disincentivize use. Unless there's some flaw in the system and > it's leaking resources=2C if usage has increased to the point where you a= re > at or near the limits of capacity=2C you expand capacity. It's as simple = as > that=2C and I've found that same rule fits quite well in a number of syst= ems. > > In Bitcoin=2C we're not leaking resources. There's no flaw. The system i= s > performing as intended. Usage is increasing because it works so well=2C a= nd > there is huge potential for future growth as we identify more uses and > attract more users. There might be a few technical things we can do to > reduce consumption=2C but the metric we're concerned with right now is ho= w > many transactions we can fit in a block. We've broken through the 75% > marker and are regularly bumping up against the 100% limit. > > It is time to stop debating this and take action to expand capacity. The > only questions that should remain are how much capacity do we add=2C and = how > soon can we do it. Given that most existing computer systems and networks > can easily handle 20MB blocks every 10 minutes=2C and given that that wil= l > increase capacity 20-fold=2C I can't think of a single reason why we can'= t go > to 20MB as soon as humanly possible. And in a few years=2C when the avera= ge > block size is over 15MB=2C we bump it up again to as high as we can go th= en > without pushing typical computers or networks beyond their capacity. We c= an > worry about ways to slow down growth without affecting the usefulness of > Bitcoin as we get closer to the hard technical limits on our capacity. > > And you know what else? If miners need higher fees to accommodate the > costs of bigger blocks=2C they can configure their nodes to only mine > transactions with higher fees.. Let the miners decide how to charge enoug= h > to pay for their costs. We don't need to cripple the network just for the= m. > > -- > *James G. Phillips IV* > > > *"Don't bunt. Aim out of the ball park. Aim for the company of immortals.= " > -- David Ogilvy * > > *This message was created with 100% recycled electrons. Please think > twice before printing.* > > > > -------------------------------------------------------------------------= ----- > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics=2C stats and reports that give you Actionable Insight= s > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510=3B117567292=3By > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --_0864ac4b-0e08-403e-a223-bea3050b8535_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I wo= uldn't say same trade-off because you need the whole 20mb block before you = can start to use it where as a 1mb block can be used quicker thus transacti= ons found in tge block quicker etc. As for tge higher rate of orphans=2C I think this would be complimented by a fast= er correction rate=2C so if you're pumping out blocks at a rate of 1 per mi= nute=2C if we get a fork and the next block comes in 10 minutes and is the = decider=2C it took 10 minutes to determine which block is the orphan. But at a rate of 1 block per 1 minute then it o= nly takes 1 minute to resolve the orphan (obviously this is very simplified= ) so I'm not so sure that orphan rate is a big issue here. Indeed you would= need to draw upon more confirmations for easier block creation but surely that is not an issue?

Why would sync time be longer as opposed to 20mb blocks?
From: gabe appleton
Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:41 PM
To: Thy Shizzle
Cc: Jim Phillips=3B Mike Hearn=3B Bitcoin Dev
Subject: Re: [Bitcoin-development] No Bitcoin For You

But don't you see the same trade-off in the end there? You= 're still propagating the same amount of data over the same amount of time= =2C so unless I misunderstand=2C the costs of such a move should be approxi= mately the same=2C just in different areas. The risks as I understand are as follows:

20MB:

  1. Longer per-block propagation (eventually)
  2. Longer processing tim= e (eventually)
  3. Longer sync time
1 Minute:
  1. Weaker individual confirmations (approx. equal per confirmation*time)
  2. Higher orphan rate (immediately)
  3. Longer sync time
That risk-set makes me want a middle-ground approach. Something where = the immediate consequences aren't all that strong=2C and where we have some= idea of what to do in the future. Is there any chance we can get decent ne= twork simulations at various configurations (5MB/4min=2C etc)? Perhaps re-appropriate the testnet?

On Mon=2C May 25=2C 2015 at 10:30 PM=2C Thy Sh= izzle <=3Bthyshizzl= e@outlook.com>=3B wrote:
Nah don't= make blocks 20mb=2C then you are slowing down block propagation and blowin= g out conf tikes as a result. Just decrease the time it takes to make a 1mb= block=2C then you still see the same propagation times today and just increase the transaction throughput.
From: <= a href=3D"mailto:jim@ergophobia.org" target=3D"_blank">Jim Phillips
Sent: = =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM
To: <= a href=3D"mailto:mike@plan99.net" target=3D"_blank">Mike Hearn Cc: <= a href=3D"mailto:bitcoin-development@lists.sourceforge.net" target=3D"_blan= k">Bitcoin Dev
Subject: R= e: [Bitcoin-development] No Bitcoin For You

... And will certainly NEVER have if we can't solve the capacity probl= em SOON. =3B

In a former life=2C I was a capacity planner for Bank of America's mid= -range server group. We had one hard and fast rule. When you are typically = exceeding 75% of capacity on a given metric=2C it's time to expand capacity= . Period. You don't do silly things like adjusting the business model to disincentivize use. Unless there's so= me flaw in the system and it's leaking resources=2C if usage has increased = to the point where you are at or near the limits of capacity=2C you expand = capacity. It's as simple as that=2C and I've found that same rule fits quite well in a number of systems. =3B<= /div>

In Bitcoin=2C we're not leaking resources. There's no flaw. The system= is performing as intended. Usage is increasing because it works so well=2C= and there is huge potential for future growth as we identify more uses and= attract more users. There might be a few technical things we can do to reduce consumption=2C but the metric w= e're concerned with right now is how many transactions we can fit in a bloc= k. We've broken through the 75% marker and are regularly bumping up against= the 100% limit.

It is time to stop debating this and take action to expand capacity. T= he only questions that should remain are how much capacity do we add=2C and= how soon can we do it. Given that most existing computer systems and netwo= rks can easily handle 20MB blocks every 10 minutes=2C and given that that will increase capacity 20-fold=2C = I can't think of a single reason why we can't go to 20MB as soon as humanly= possible. And in a few years=2C when the average block size is over 15MB= =2C we bump it up again to as high as we can go then without pushing typical computers or networks beyond their capacit= y. We can worry about ways to slow down growth without affecting the useful= ness of Bitcoin as we get closer to the hard technical limits on our capaci= ty.

And you know what else? If miners need higher fees to accommodate the = costs of bigger blocks=2C they can configure their nodes to only mine trans= actions with higher fees.. Let the miners decide how to charge enough to pa= y for their costs. We don't need to cripple the network just for them.

"=3BDon't bunt. Aim out of the ball park. Aim = for the company of immortals."=3B -- David Ogilvy

 =3BThis message was created with 100% = recycled electrons. Please think twice before printing.


---------------------------------------------------------------------------= ---
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+=3B applications
Performance metrics=2C stats and reports that give you Actionable Insights<= br> Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510=3B117567292=3By<= /a>
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--_0864ac4b-0e08-403e-a223-bea3050b8535_--