path: root/2f/b9d22061b15dd0ea7ea48442c8dba6c7c436ef

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 <thyshizzle@outlook.com>) 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: <BAY403-EAS100C211D1C5E57BFB80BFE6C2CC0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_0864ac4b-0e08-403e-a223-bea3050b8535_"
MIME-Version: 1.0
To: gabe appleton <gappleto97@gmail.com>
From: Thy Shizzle <thyshizzle@outlook.com>
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-development@lists.sourceforge.net>, 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: <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: 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<mailto:gappleto97@gmail.com>
Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:41 PM
To: Thy Shizzle<mailto:thyshizzle@outlook.com>
Cc: Jim Phillips<mailto:jim@ergophobia.org>=3B Mike Hearn<mailto:mike@plan9=
9.net>=3B Bitcoin Dev<mailto:bitcoin-development@lists.sourceforge.net>
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 <thyshizzle@outlook.com=
>
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 <jim@ergophobia.org>
> Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM
> To: Mike Hearn <mike@plan99.net>
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] No Bitcoin For You
>
>
> On Mon=2C May 25=2C 2015 at 1:36 PM=2C Mike Hearn <mike@plan99.net> 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*
> <https://plus.google.com/u/0/113107039501292625391/posts>
>
> *"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"

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dutf-8">
</head>
<body>
<div>
<div style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B">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?<br>
<br>
Why would sync time be longer as opposed to 20mb blocks?</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">From:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:gappleto97@gmail.com">gabe appleton</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Sent:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">=E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:41 PM</span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">To:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:thyshizzle@outlook.com">Thy Shizzle</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Cc:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:jim@ergophobia.org">Jim Phillips</a>=3B
<a href=3D"mailto:mike@plan99.net">Mike Hearn</a>=3B <a href=3D"mailto:bitc=
oin-development@lists.sourceforge.net">
Bitcoin Dev</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Subject:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">Re: [Bitcoin-development] No Bitcoin For You</span><br>
<br>
</div>
<div>
<div dir=3D"ltr">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:
<div><br>
</div>
<div>20MB:</div>
<div><br>
</div>
<div>
<ol>
<li>Longer per-block propagation (eventually)</li><li>Longer processing tim=
e (eventually)</li><li>Longer sync time</li></ol>
<div>1 Minute:</div>
</div>
<div>
<ol>
<li>Weaker individual confirmations (approx. equal per confirmation*time)</=
li><li>Higher orphan rate (immediately)</li><li>Longer sync time</li></ol>
<div>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?</div>
</div>
</div>
<div class=3D"x_gmail_extra"><br>
<div class=3D"x_gmail_quote">On Mon=2C May 25=2C 2015 at 10:30 PM=2C Thy Sh=
izzle <span dir=3D"ltr">
&lt=3B<a href=3D"mailto:thyshizzle@outlook.com" target=3D"_blank">thyshizzl=
e@outlook.com</a>&gt=3B</span> wrote:<br>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex=3B border-le=
ft:1px #ccc solid=3B padding-left:1ex">
<div>
<div>
<div style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt">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.</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">From:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt"><=
a href=3D"mailto:jim@ergophobia.org" target=3D"_blank">Jim Phillips</a></sp=
an><br>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">Sent:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt">=
=E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM</span><br>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">To:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt"><=
a href=3D"mailto:mike@plan99.net" target=3D"_blank">Mike Hearn</a></span><b=
r>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">Cc:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt"><=
a href=3D"mailto:bitcoin-development@lists.sourceforge.net" target=3D"_blan=
k">Bitcoin Dev</a></span><br>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">Subject:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt">R=
e: [Bitcoin-development] No Bitcoin For You</span><br>
<br>
</div>
<div>
<div class=3D"x_h5">
<div>
<div dir=3D"ltr">
<div><br>
<div>On Mon=2C May 25=2C 2015 at 1:36 PM=2C Mike Hearn <span dir=3D"ltr">&l=
t=3B<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a=
>&gt=3B</span> wrote:</div>
<div><br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex=3B border-left-width:1px=3B b=
order-left-color:rgb(204=2C204=2C204)=3B border-left-style:solid=3B padding=
-left:1ex">
<div dir=3D"ltr">
<div>
<div>
<div>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 of transaction demand with today's=
 hardware. As noted previously=2C &quot=3Btoo many users&quot=3B is simply =
not a problem Bitcoin has .... and may never have!</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<div>... And will certainly NEVER have if we can't solve the capacity probl=
em SOON.&nbsp=3B</div>
<div><br>
</div>
<div>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.&nbsp=3B<=
/div>
<div><br>
</div>
<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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br clear=3D"all">
<div>
<div>
<div>--
<div><b>James G. Phillips IV</b>&nbsp=3B<a href=3D"https://plus.google.com/=
u/0/113107039501292625391/posts" target=3D"_blank" style=3D"font-size:x-sma=
ll"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"></a>&nbs=
p=3B</div>
</div>
<div><font size=3D"1"><i>&quot=3BDon't bunt. Aim out of the ball park. Aim =
for the company of immortals.&quot=3B -- David Ogilvy<br>
</i></font>
<div><font size=3D"1"><br>
</font></div>
</div>
<div><font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fug=
ue/16/leaf.png">&nbsp=3B<em style=3D"font-family:verdana=2Cgeneva=2Csans-se=
rif=3B line-height:16px=3B color:green">This message was created with 100% =
recycled electrons. Please think twice before printing.</em></font></div>
<div><font size=3D"1"><em style=3D"font-family:verdana=2Cgeneva=2Csans-seri=
f=3B line-height:16px=3B color:green"><br>
</em></font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50&#43=3B applications<br>
Performance metrics=2C 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=3B117567292=3By" tar=
get=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510=3B117567292=3By<=
/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>
</body>
</html>

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