path: root/2d/de7590251fbfe825a65899a8dd05000b6a3773

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 <gappleto97@gmail.com>) id 1Yx7eA-0002EF-Bi
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 05:43:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.171 as permitted sender)
	client-ip=209.85.192.171; envelope-from=gappleto97@gmail.com;
	helo=mail-pd0-f171.google.com; 
Received: from mail-pd0-f171.google.com ([209.85.192.171])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yx7e8-0007po-01
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 05:43:26 +0000
Received: by pdfh10 with SMTP id h10so82734507pdf.3
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 25 May 2015 22:43:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.70.22.131 with SMTP id d3mr45825277pdf.67.1432618998278;
	Mon, 25 May 2015 22:43:18 -0700 (PDT)
Received: by 10.66.194.168 with HTTP; Mon, 25 May 2015 22:43:17 -0700 (PDT)
Received: by 10.66.194.168 with HTTP; Mon, 25 May 2015 22:43:17 -0700 (PDT)
In-Reply-To: <CANe1mWw2os6GUbRiyegn=Z+2ZM_J8x76rD4uh_0C3z+ix8aK+A@mail.gmail.com>
References: <BAY403-EAS63EE0AAE718842E0E3EFD6C2CC0@phx.gbl>
	<CANe1mWw-yJv=1_aLc+T8Mq1XgUv8VeDxHee-hVzQNH0hFs1ryg@mail.gmail.com>
	<CANe1mWw2os6GUbRiyegn=Z+2ZM_J8x76rD4uh_0C3z+ix8aK+A@mail.gmail.com>
Date: Tue, 26 May 2015 01:43:17 -0400
Message-ID: <CANJO25LfwscmT06gwk3D==+=Cj6eBt9dUCHwyrGAs6U9Eoi5Uw@mail.gmail.com>
From: gabe appleton <gappleto97@gmail.com>
To: Jim Phillips <jim@ergophobia.org>
Content-Type: multipart/alternative; boundary=047d7b6d87187daf180516f59aa0
X-Spam-Score: -0.3 (/)
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
	(gappleto97[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (gappleto97[at]gmail.com)
	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
	0.0 T_REMOTE_IMAGE         Message contains an external image
X-Headers-End: 1Yx7e8-0007po-01
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 05:43:26 -0000

--047d7b6d87187daf180516f59aa0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sync time wouldn't be longer compared to 20MB, it would (eventually) be
longer under either setup.

Also, and this is probably a silly concern, but wouldn't changing block
time change the supply curve? If we cut the rate in half or a power of two,
that affects nothing, but if we want to keep it in round numbers, we need
to do it by 10, 5, or 2. I feel like most people would bank for 10 or 5,
both of which change the supply curve due to truncation.

Again, it's a trivial concern, but probably one that should be addressed.
On May 25, 2015 11:52 PM, "Jim Phillips" <jim@ergophobia.org> wrote:

> Incidentally, even once we have the "Internet of Things" brought on by 21=
,
> Inc. or whoever beats them to it, I would expect the average home to have
> only a single full node "hub" receiving the blockchain and broadcasting
> transactions created by all the minor SPV connected devices running withi=
n
> the house. The in-home full node would be peered with high bandwidth
> full-node relays running at the ISP or in the cloud. There are more than
> enough ISPs and cloud compute providers in the world such that there shou=
ld
> be no concern at all about centralization of relays. Full nodes could som=
e
> day become as ubiquitous on the Internet as authoritative DNS servers. An=
d
> just like DNS servers, if you don't trust the nodes your ISP creates or
> it's too slow or censors transactions, there's nothing preventing you fro=
m
> peering with nodes hosted by the Googles or OpenDNSs out there, or runnin=
g
> your own if you're really paranoid and have a few extra bucks for a VPS.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe>
>
> *"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.*
>
> On Mon, May 25, 2015 at 10:23 PM, Jim Phillips <jim@ergophobia.org> wrote=
:
>
>> I don't see how the fact that my 2Mbps connection causes me to not be a
>> very good relay has any bearing on whether or not the network as a whole
>> would be negatively impacted by a 20MB block. My inability to rapidly
>> propagate blocks doesn't really harm the network. It's only if MOST rela=
ys
>> are as slow as mine that it creates an issue. I'm one node in thousands
>> (potentially tens or hundreds of thousands if/when Bitcoin goes
>> mainstream). And I'm an individual. There's no reason at all for me to r=
un
>> a full node from my home, except to have my own trusted and validated co=
py
>> of the blockchain on a computer I control directly. I don't need to act =
as
>> a relay for that and as long as I can download blocks faster than they a=
re
>> created I'm fine. Also, I can easily afford a VPS server or several to r=
un
>> full nodes as relays if I am feeling altruistic. It's actually cheaper f=
or
>> me to lease a VPS than to keep my own home PC on 24/7, which is why I ha=
ve
>> 2 of them.
>>
>> And as a business, the cost of a server and bandwidth to run a full node
>> is a drop in the bucket. I'm involved in several projects where we have
>> full nodes running on leased servers with multiple 1Gbps connections. It=
's
>> an almost zero cost. Those nodes could handle 20MB blocks today without
>> thinking about it, and I'm sure our nodes are just a few amongst thousan=
ds
>> just like them. I'm not at all concerned about the network being too
>> centralized.
>>
>> What concerns me is the fact that we are using edge cases like my home P=
C
>> as a lame excuse to debate expanding the capacity of the network.
>>
>> --
>> *James G. Phillips IV*
>> <https://plus.google.com/u/0/113107039501292625391/posts>
>> <http://www.linkedin.com/in/ergophobe>
>>
>> *"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.*
>>
>> On Mon, May 25, 2015 at 10:02 PM, Thy Shizzle <thyshizzle@outlook.com>
>> wrote:
>>
>>>  Indeed Jim, your internet connection makes a good reason why I don't
>>> like 20mb blocks (right now). It would take you well over a minute to
>>> download the block before you could even relay it on, so much slow down=
 in
>>> propagation! Yes I do see how decreasing the time to create blocks is a=
 bit
>>> of a band-aid fix, and to use tge term I've seen mentioned here "kickin=
g
>>> the can down the road" I agree that this is doing this, however as you =
say
>>> bandwidth is our biggest enemy right now and so hopefully by the time w=
e
>>> exceed the capacity gained by the decrease in block time, we can then l=
ook
>>> to bump up block size because hopefully 20mbps connections will be base=
line
>>> by then etc.
>>>  ------------------------------
>>> From: Jim Phillips <jim@ergophobia.org>
>>> Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:53 PM
>>> To: Thy Shizzle <thyshizzle@outlook.com>
>>> Cc: Mike Hearn <mike@plan99.net>; Bitcoin Dev
>>> <bitcoin-development@lists.sourceforge.net>
>>>
>>> Subject: Re: [Bitcoin-development] No Bitcoin For You
>>>
>>>  Frankly I'm good with either way. I'm definitely in favor of faster
>>> confirmation times.
>>>
>>>  The important thing is that we need to increase the amount of
>>> transactions that get into blocks over a given time frame to a point th=
at
>>> is in line with what current technology can handle. We can handle WAY m=
ore
>>> than we are doing right now. The Bitcoin network is not currently Disk,
>>> CPU, or RAM bound.. Not even close. The metric we're closest to being
>>> restricted by would be Network bandwidth. I live in a developing countr=
y.
>>> 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps
>>> connections are affordable). That equates to about 17MB per minute, or =
170x
>>> more capacity than what I need to receive a full copy of the blockchain=
 if
>>> I only talk to one peer. If I relay to say 10 peers, I can still handle=
 17x
>>> larger block sizes on a slow 2Mbps connection.
>>>
>>>  Also, even if we reduce the difficulty so that we're doing 1MB blocks
>>> every minute, that's still only 10MB every 10 minutes. Eventually we're
>>> going to have to increase that, and we can only reduce the confirmation
>>> period so much. I think someone once said 30 seconds or so is about the
>>> shortest period you can practically achieve.
>>>
>>>  --
>>> *James G. Phillips IV*
>>> <https://plus.google.com/u/0/113107039501292625391/posts>
>>> <http://www.linkedin.com/in/ergophobe>
>>>
>>> *"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.*
>>>
>>> On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle <thyshizzle@outlook.com>
>>> wrote:
>>>
>>>  Nah don't make blocks 20mb, then you are slowing down block
>>> propagation and blowing out conf tikes as a result. Just decrease the t=
ime
>>> it takes to make a 1mb block, then you still see the same propagation t=
imes
>>> today and 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, May 25, 2015 at 1:36 PM, Mike Hearn <mike@plan99.net> wrote:
>>>
>>>   This meme about datacenter-sized nodes has to die. The Bitcoin wiki
>>> is down right now, but I showed years ago that you could keep up with V=
ISA
>>> on a single well specced server with today's technology. Only people li=
ving
>>> in a dreamworld think that Bitcoin might actually have to match that le=
vel
>>> of transaction demand with today's hardware. As noted previously, "too =
many
>>> 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, 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, 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, if usage has increased to the point where you a=
re
>>> at or near the limits of capacity, you expand capacity. It's as simple =
as
>>> that, and I've found that same rule fits quite well in a number of syst=
ems.
>>>
>>>  In Bitcoin, we're not leaking resources. There's no flaw. The system
>>> is performing as intended. Usage is increasing because it works so well=
,
>>> 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, 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, =
and
>>> how soon can we do it. Given that most existing computer systems and
>>> networks can easily handle 20MB blocks every 10 minutes, and given that
>>> that will increase capacity 20-fold, I can't think of a single reason w=
hy
>>> we can't go to 20MB as soon as humanly possible. And in a few years, wh=
en
>>> the average block size is over 15MB, we bump it up again to as high as =
we
>>> can go then without pushing typical computers or networks beyond their
>>> capacity. We can 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, they can configure their nodes to only mine
>>> transactions with higher fees.. Let the miners decide how to charge eno=
ugh
>>> to pay for their costs. We don't need to cripple the network just for t=
hem.
>>>
>>>  --
>>> *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, 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
>
>

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

<p dir=3D"ltr">Sync time wouldn&#39;t be longer compared to 20MB, it would =
(eventually) be longer under either setup.</p>
<p dir=3D"ltr">Also, and this is probably a silly concern, but wouldn&#39;t=
 changing block time change the supply curve? If we cut the rate in half or=
 a power of two, that affects nothing, but if we want to keep it in round n=
umbers, we need to do it by 10, 5, or 2. I feel like most people would bank=
 for 10 or 5, both of which change the supply curve due to truncation.</p>
<p dir=3D"ltr">Again, it&#39;s a trivial concern, but probably one that sho=
uld be addressed.</p>
<div class=3D"gmail_quote">On May 25, 2015 11:52 PM, &quot;Jim Phillips&quo=
t; &lt;<a href=3D"mailto:jim@ergophobia.org">jim@ergophobia.org</a>&gt; wro=
te:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>Incidentally, even once we have the &quot;Internet of Things&quot; brought=
 on by 21, Inc. or whoever beats them to it, I would expect the average hom=
e to have only a single full node &quot;hub&quot; receiving the blockchain =
and broadcasting transactions created by all the minor SPV connected device=
s running within the house. The in-home full node would be peered with high=
 bandwidth full-node relays running at the ISP or in the cloud. There are m=
ore than enough ISPs and cloud compute providers in the world such that the=
re should be no concern at all about centralization of relays. Full nodes c=
ould some day become as ubiquitous on the Internet as authoritative DNS ser=
vers. And just like DNS servers, if you don&#39;t trust the nodes your ISP =
creates or it&#39;s too slow or censors transactions, there&#39;s nothing p=
reventing you from peering with nodes hosted by the Googles or OpenDNSs out=
 there, or running your own if you&#39;re really paranoid and have a few ex=
tra bucks for a VPS.<br><div class=3D"gmail_extra"><br clear=3D"all"><div><=
div><div>--<div><b>James G. Phillips IV</b>=C2=A0<a href=3D"https://plus.go=
ogle.com/u/0/113107039501292625391/posts" style=3D"font-size:x-small" targe=
t=3D"_blank"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"=
></a>=C2=A0<a href=3D"http://www.linkedin.com/in/ergophobe" target=3D"_blan=
k"><img src=3D"http://developer.linkedin.com/sites/default/files/LinkedIn_L=
ogo16px.png"></a></div></div><div><font size=3D"1"><i>&quot;Don&#39;t bunt.=
 Aim out of the ball park. Aim for the company of immortals.&quot; -- David=
 Ogilvy<br></i></font><div><font size=3D"1"><br></font></div></div><div><fo=
nt size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fugue/16/le=
af.png">=C2=A0<em style=3D"background-color:rgb(255,255,255);font-family:ve=
rdana,geneva,sans-serif;line-height:16px;color:green">This message was crea=
ted with 100% recycled electrons. Please think twice before printing.</em><=
/font></div></div></div>
<br><div class=3D"gmail_quote">On Mon, May 25, 2015 at 10:23 PM, Jim Philli=
ps <span dir=3D"ltr">&lt;<a href=3D"mailto:jim@ergophobia.org" target=3D"_b=
lank">jim@ergophobia.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">I don&#39;t see how the fact that my 2Mbps connectio=
n causes me to not be a very good relay has any bearing on whether or not t=
he network as a whole would be negatively impacted by a 20MB block. My inab=
ility to rapidly propagate blocks doesn&#39;t really harm the network. It&#=
39;s only if MOST relays are as slow as mine that it creates an issue. I&#3=
9;m one node in thousands (potentially tens or hundreds of thousands if/whe=
n Bitcoin goes mainstream). And I&#39;m an individual. There&#39;s no reaso=
n at all for me to run a full node from my home, except to have my own trus=
ted and validated copy of the blockchain on a computer I control directly. =
I don&#39;t need to act as a relay for that and as long as I can download b=
locks faster than they are created I&#39;m fine. Also, I can easily afford =
a VPS server or several to run full nodes as relays if I am feeling altruis=
tic. It&#39;s actually cheaper for me to lease a VPS than to keep my own ho=
me PC on 24/7, which is why I have 2 of them.<div><br></div><div>And as a b=
usiness, the cost of a server and bandwidth to run a full node is a drop in=
 the bucket. I&#39;m involved in several projects where we have full nodes =
running on leased servers with multiple 1Gbps connections. It&#39;s an almo=
st zero cost. Those nodes could handle 20MB blocks today without thinking a=
bout it, and I&#39;m sure our nodes are just a few amongst thousands just l=
ike them. I&#39;m not at all concerned about the network being too centrali=
zed.</div><div><br></div><div>What concerns me is the fact that we are usin=
g edge cases like my home PC as a lame excuse to debate expanding the capac=
ity of the network.</div></div><div class=3D"gmail_extra"><span><br clear=
=3D"all"><div><div><div>--<div><b>James G. Phillips IV</b>=C2=A0<a href=3D"=
https://plus.google.com/u/0/113107039501292625391/posts" style=3D"font-size=
:x-small" target=3D"_blank"><img src=3D"https://ssl.gstatic.com/images/icon=
s/gplus-16.png"></a>=C2=A0<a href=3D"http://www.linkedin.com/in/ergophobe" =
target=3D"_blank"><img src=3D"http://developer.linkedin.com/sites/default/f=
iles/LinkedIn_Logo16px.png"></a></div></div><div><font size=3D"1"><i>&quot;=
Don&#39;t bunt. Aim out of the ball park. Aim for the company of immortals.=
&quot; -- 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/1=
156/fugue/16/leaf.png">=C2=A0<em style=3D"background-color:rgb(255,255,255)=
;font-family:verdana,geneva,sans-serif;line-height:16px;color:green">This m=
essage was created with 100% recycled electrons. Please think twice before =
printing.</em></font></div></div></div>
<br></span><div><div><div class=3D"gmail_quote">On Mon, May 25, 2015 at 10:=
02 PM, Thy Shizzle <span dir=3D"ltr">&lt;<a href=3D"mailto:thyshizzle@outlo=
ok.com" target=3D"_blank">thyshizzle@outlook.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">



<div>
<div>
<div style=3D"font-family:Calibri,sans-serif;font-size:11pt">Indeed Jim, yo=
ur internet connection makes a good reason why I don&#39;t like 20mb blocks=
 (right now). It would take you well over a minute to download the block be=
fore you could even relay it on, so
 much slow down in propagation! Yes I do see how decreasing the time to cre=
ate blocks is a bit of a band-aid fix, and to use tge term I&#39;ve seen me=
ntioned here &quot;kicking the can down the road&quot; I agree that this is=
 doing this, however as you say bandwidth is our
 biggest enemy right now and so hopefully by the time we exceed the capacit=
y gained by the decrease in block time, we can then look to bump up block s=
ize because hopefully 20mbps connections will be baseline by then etc.</div=
>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">From:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:jim@ergophobia.org" target=3D"_blank">Jim Phillips</a></span><b=
r>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Sent:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt">=E2=80=
=8E26/=E2=80=8E05/=E2=80=8E2015 12:53 PM</span><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">To:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:thyshizzle@outlook.com" target=3D"_blank">Thy Shizzle</a></span=
><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Cc:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:mike@plan99.net" target=3D"_blank">Mike Hearn</a>;
<a href=3D"mailto:bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin Dev</a></span><div><div><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Subject:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt">Re: [B=
itcoin-development] No Bitcoin For You</span><br>
<br>
</div></div></div><div><div>
<div>
<div dir=3D"ltr">Frankly I&#39;m good with either way. I&#39;m definitely i=
n favor of faster confirmation times.=C2=A0
<div><br>
</div>
<div>The important thing is that we need to increase the amount of transact=
ions that get into blocks over a given time frame to a point that is in lin=
e with what current technology can handle. We can handle WAY more than we a=
re doing right now. The Bitcoin
 network is not currently Disk, CPU, or RAM bound.. Not even close. The met=
ric we&#39;re closest to being restricted by would be Network bandwidth. I =
live in a developing country. 2Mbps is a typical broadband speed here (alth=
ough 5Mbps and 10Mbps connections are
 affordable). That equates to about 17MB per minute, or 170x more capacity =
than what I need to receive a full copy of the blockchain if I only talk to=
 one peer. If I relay to say 10 peers, I can still handle 17x larger block =
sizes on a slow 2Mbps connection.
<div><br>
</div>
<div>Also, even if we reduce the difficulty so that we&#39;re doing 1MB blo=
cks every minute, that&#39;s still only 10MB every 10 minutes. Eventually w=
e&#39;re going to have to increase that, and we can only reduce the confirm=
ation period so much. I think someone once said
 30 seconds or so is about the shortest period you can practically achieve.=
</div>
</div>
</div>
<div><br clear=3D"all">
<div>
<div>
<div>--
<div><b>James G. Phillips IV</b>=C2=A0<a href=3D"https://plus.google.com/u/=
0/113107039501292625391/posts" style=3D"font-size:x-small" target=3D"_blank=
"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"></a>=C2=A0=
<a href=3D"http://www.linkedin.com/in/ergophobe" target=3D"_blank"><img src=
=3D"http://developer.linkedin.com/sites/default/files/LinkedIn_Logo16px.png=
"></a></div>
</div>
<div><font size=3D"1"><i>&quot;Don&#39;t bunt. Aim out of the ball park. Ai=
m for the company of immortals.&quot; -- 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">=C2=A0<em style=3D"background-color:rgb(255,255,255);font-f=
amily:verdana,geneva,sans-serif;line-height:16px;color:green">This message =
was created with 100% recycled electrons.
 Please think twice before printing.</em></font></div>
</div>
</div>
<br>
<div>On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle <span dir=3D"ltr">
&lt;<a href=3D"mailto:thyshizzle@outlook.com" target=3D"_blank">thyshizzle@=
outlook.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div>
<div>
<div style=3D"font-family:Calibri,sans-serif;font-size:11pt">Nah don&#39;t =
make blocks 20mb, then you are slowing down block propagation and blowing o=
ut conf tikes as a result. Just decrease the time it takes to make a 1mb bl=
ock, 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,sans-serif;font-size:11pt;font-weight:bo=
ld">From:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:jim@ergophobia.org" target=3D"_blank">Jim Phillips</a></span><b=
r>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Sent:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt">=E2=80=
=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM</span><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">To:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:mike@plan99.net" target=3D"_blank">Mike Hearn</a></span><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Cc:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt"><a hre=
f=3D"mailto:bitcoin-development@lists.sourceforge.net" target=3D"_blank">Bi=
tcoin Dev</a></span><br>
<span style=3D"font-family:Calibri,sans-serif;font-size:11pt;font-weight:bo=
ld">Subject:
</span><span style=3D"font-family:Calibri,sans-serif;font-size:11pt">Re: [B=
itcoin-development] No Bitcoin For You</span><br>
<br>
</div>
<div>
<div>
<div>
<div dir=3D"ltr">
<div><br>
<div>On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</s=
pan> wrote:</div>
<div><br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;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, but I showed years ago that you could keep up with VISA on=
 a single well specced server with today&#39;s technology. Only people livi=
ng in a dreamworld think that Bitcoin
 might actually have to match that level of transaction demand with today&#=
39;s hardware. As noted previously, &quot;too many users&quot; is simply no=
t 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&#39;t solve the capacity p=
roblem SOON.=C2=A0</div>
<div><br>
</div>
<div>In a former life, I was a capacity planner for Bank of America&#39;s m=
id-range server group. We had one hard and fast rule. When you are typicall=
y exceeding 75% of capacity on a given metric, it&#39;s time to expand capa=
city. Period. You don&#39;t do silly things
 like adjusting the business model to disincentivize use. Unless there&#39;=
s some flaw in the system and it&#39;s leaking resources, if usage has incr=
eased to the point where you are at or near the limits of capacity, you exp=
and capacity. It&#39;s as simple as that, and
 I&#39;ve found that same rule fits quite well in a number of systems.=C2=
=A0</div>
<div><br>
</div>
<div>In Bitcoin, we&#39;re not leaking resources. There&#39;s no flaw. The =
system is performing as intended. Usage is increasing because it works so w=
ell, 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, but the metric we&=
#39;re concerned with right now is how many transactions we can fit in a bl=
ock. We&#39;ve broken through the 75% marker and are regularly bumping up a=
gainst 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, and h=
ow soon can we do it. Given that most existing computer systems and network=
s can easily handle 20MB blocks
 every 10 minutes, and given that that will increase capacity 20-fold, I ca=
n&#39;t think of a single reason why we can&#39;t go to 20MB as soon as hum=
anly possible. And in a few years, when the average block size is over 15MB=
, 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, they can configure their nodes to only mine transac=
tions with higher fees.. Let the miners decide how to charge enough to pay =
for their costs. We don&#39;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>=C2=A0<a href=3D"https://plus.google.com/u/=
0/113107039501292625391/posts" style=3D"font-size:x-small" target=3D"_blank=
"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"></a>=C2=A0=
</div>
</div>
<div><font size=3D"1"><i>&quot;Don&#39;t bunt. Aim out of the ball park. Ai=
m for the company of immortals.&quot; -- 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">=C2=A0<em style=3D"font-family:verdana,geneva,sans-serif;li=
ne-height:16px;color:green">This message was created with 100% recycled ele=
ctrons. Please think twice before printing.</em></font></div>
<div><font size=3D"1"><em style=3D"font-family:verdana,geneva,sans-serif;li=
ne-height:16px;color:green"><br>
</em></font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div></div></div>

</blockquote></div><br></div></div></div>
</blockquote></div><br></div></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>

--047d7b6d87187daf180516f59aa0--