summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJim Phillips <jim@ergophobia.org>2015-05-26 03:29:31 -0500
committerbitcoindev <bitcoindev@gnusha.org>2015-05-26 08:30:11 +0000
commit5cf533208c816ec1a1907c078f3d16e85c2878d0 (patch)
tree0520df2a6eb1be064e055bb5ec0c7df13440a003
parentaa814fd01877fab57482461d09fcee37a19747bd (diff)
downloadpi-bitcoindev-5cf533208c816ec1a1907c078f3d16e85c2878d0.tar.gz
pi-bitcoindev-5cf533208c816ec1a1907c078f3d16e85c2878d0.zip
Re: [Bitcoin-development] No Bitcoin For You
-rw-r--r--3d/b2beea067009b049f180d732bba458626be220748
1 files changed, 748 insertions, 0 deletions
diff --git a/3d/b2beea067009b049f180d732bba458626be220 b/3d/b2beea067009b049f180d732bba458626be220
new file mode 100644
index 000000000..181fe5276
--- /dev/null
+++ b/3d/b2beea067009b049f180d732bba458626be220
@@ -0,0 +1,748 @@
+Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
+ helo=mx.sourceforge.net)
+ by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <jim@ergophobia.org>) id 1YxAFX-0007jK-5b
+ for bitcoin-development@lists.sourceforge.net;
+ Tue, 26 May 2015 08:30:11 +0000
+X-ACL-Warn:
+Received: from mail-wi0-f179.google.com ([209.85.212.179])
+ by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
+ (Exim 4.76) id 1YxAFU-0004G4-D8
+ for bitcoin-development@lists.sourceforge.net;
+ Tue, 26 May 2015 08:30:11 +0000
+Received: by wichy4 with SMTP id hy4so72118411wic.1
+ for <bitcoin-development@lists.sourceforge.net>;
+ Tue, 26 May 2015 01:30:02 -0700 (PDT)
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20130820;
+ h=x-gm-message-state:mime-version:in-reply-to:references:from:date
+ :message-id:subject:to:cc:content-type;
+ bh=tnuAhuRWFvOaD39f8FrEq9cyNdi90o809u8zZLLWQBY=;
+ b=WPDpa2QvTuFqAE72StS0rPHwAYuWvCLwAHyx6Tq+WxqWwl8cEzJfqV4cDvVSM0L6rZ
+ DbMWpKWQQFTZ0D33wssCMuu3k0Hv2Fcnqkr0TxUldZoiJzvm4Uw0gj8m6CuA9CZVoi/v
+ FC96U+x7X5vz+WQgUu9Ah5kcgt2BmfkBuwaSpBIH47NwRxb3ZNI8E+DMkzZKgCyRik1Q
+ JSHscN4STOAwwU8Hvl9E6qsp6uUBd3XanLslH8TyyWHr7yhR073+LD1Xc4BWxIA4q1s5
+ 56HjIYmDpRIfoa4UOYAaxZlhlNrbpdPVSyfi+1u6EaynIe+86P8A+GrQ0pP57zdUsKO+
+ Fv7Q==
+X-Gm-Message-State: ALoCoQnFly4c75KcA7MLKSRTbFnPouFXAbZxXjRwYEh9nuiJZwcCbW2AwHOeBjWk2g+ZTHHXYCTs
+X-Received: by 10.180.107.138 with SMTP id hc10mr38531256wib.2.1432629002308;
+ Tue, 26 May 2015 01:30:02 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.194.246.69 with HTTP; Tue, 26 May 2015 01:29:31 -0700 (PDT)
+In-Reply-To: <CANJO25LfwscmT06gwk3D==+=Cj6eBt9dUCHwyrGAs6U9Eoi5Uw@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>
+ <CANJO25LfwscmT06gwk3D==+=Cj6eBt9dUCHwyrGAs6U9Eoi5Uw@mail.gmail.com>
+From: Jim Phillips <jim@ergophobia.org>
+Date: Tue, 26 May 2015 03:29:31 -0500
+Message-ID: <CANe1mWzK-8PM-7tPKGhEUAYmC058QXge7Ncz+uCX_h9Xbxon_g@mail.gmail.com>
+To: gabe appleton <gappleto97@gmail.com>
+Content-Type: multipart/alternative; boundary=e89a8f235739c721580516f7ee72
+X-Spam-Score: 1.1 (+)
+X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
+ See http://spamassassin.org/tag/ for more details.
+ 1.0 HTML_MESSAGE BODY: HTML included in message
+ 0.0 T_REMOTE_IMAGE Message contains an external image
+ 0.1 AWL AWL: Adjusted score from AWL reputation of From: address
+X-Headers-End: 1YxAFU-0004G4-D8
+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 08:30:11 -0000
+
+--e89a8f235739c721580516f7ee72
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+I think all the suggestions recommending cutting the block time down also
+suggest reducing the rewards to compensate.
+
+--
+*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 Tue, May 26, 2015 at 12:43 AM, gabe appleton <gappleto97@gmail.com>
+wrote:
+
+> 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 tw=
+o,
+> 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 within the house. The in-home full node would be peered with hig=
+h
+>> 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 should be no concern at all about centralization of relays. Full
+>> nodes could some day become as ubiquitous on the Internet as authoritati=
+ve
+>> DNS servers. And just like DNS servers, if you don't trust the nodes you=
+r
+>> ISP creates or it's too slow or censors transactions, there's nothing
+>> preventing you from peering with nodes hosted by the Googles or OpenDNSs
+>> out there, or running 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 whol=
+e
+>>> 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 rel=
+ays
+>>> 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 =
+run
+>>> a full node from my home, except to have my own trusted and validated c=
+opy
+>>> 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 =
+are
+>>> created I'm fine. Also, I can easily afford a VPS server or several to =
+run
+>>> full nodes as relays if I am feeling altruistic. It's actually cheaper =
+for
+>>> me to lease a VPS than to keep my own home PC on 24/7, which is why I h=
+ave
+>>> 2 of them.
+>>>
+>>> And as a business, the cost of a server and bandwidth to run a full nod=
+e
+>>> 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. I=
+t'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 thousa=
+nds
+>>> 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
+>>> PC 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 dow=
+n 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 "kicki=
+ng
+>>>> 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 =
+we
+>>>> exceed the capacity gained by the decrease in block time, we can then =
+look
+>>>> to bump up block size because hopefully 20mbps connections will be bas=
+eline
+>>>> 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 t=
+hat
+>>>> is in line with what current technology can handle. We can handle WAY =
+more
+>>>> 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 count=
+ry.
+>>>> 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 blockchai=
+n if
+>>>> I only talk to one peer. If I relay to say 10 peers, I can still handl=
+e 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'r=
+e
+>>>> going to have to increase that, and we can only reduce the confirmatio=
+n
+>>>> period so much. I think someone once said 30 seconds or so is about th=
+e
+>>>> 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 =
+time
+>>>> it takes to make a 1mb block, then you still see the same propagation =
+times
+>>>> 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 =
+VISA
+>>>> on a single well specced server with today's technology. Only people l=
+iving
+>>>> in a dreamworld think that Bitcoin might actually have to match that l=
+evel
+>>>> 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 ex=
+pand
+>>>> capacity. Period. You don't do silly things like adjusting the busines=
+s
+>>>> model to disincentivize use. Unless there's some flaw in the system an=
+d
+>>>> it's leaking resources, if usage has increased to the point where you =
+are
+>>>> 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 sys=
+tems.
+>>>>
+>>>> In Bitcoin, we're not leaking resources. There's no flaw. The system
+>>>> is performing as intended. Usage is increasing because it works so wel=
+l,
+>>>> 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 h=
+ow
+>>>> 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 tha=
+t
+>>>> that will increase capacity 20-fold, 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, w=
+hen
+>>>> 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 affectin=
+g 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 en=
+ough
+>>>> to pay for their costs. We don't need to cripple the network just for =
+them.
+>>>>
+>>>> --
+>>>> *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
+>>
+>>
+
+--e89a8f235739c721580516f7ee72
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">I think all the suggestions recommending cutting the block=
+ time down also suggest reducing the rewards to compensate.</div><div class=
+=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail_signature"><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"_bl=
+ank"><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. 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/1156/fugue/16/leaf.png"=
+>=C2=A0<em style=3D"background-color:rgb(255,255,255);font-family:verdana,g=
+eneva,sans-serif;line-height:16px;color:green">This message was created wit=
+h 100% recycled electrons. Please think twice before printing.</em></font><=
+/div></div></div>
+<br><div class=3D"gmail_quote">On Tue, May 26, 2015 at 12:43 AM, gabe apple=
+ton <span dir=3D"ltr">&lt;<a href=3D"mailto:gappleto97@gmail.com" target=3D=
+"_blank">gappleto97@gmail.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"><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"><div><div class=3D"h5">On May 25, 2015 11:52 PM,=
+ &quot;Jim Phillips&quot; &lt;<a href=3D"mailto:jim@ergophobia.org" target=
+=3D"_blank">jim@ergophobia.org</a>&gt; wrote:<br type=3D"attribution"></div=
+></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
+left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"lt=
+r">Incidentally, even once we have the &quot;Internet of Things&quot; broug=
+ht on by 21, Inc. or whoever beats them to it, I would expect the average h=
+ome to have only a single full node &quot;hub&quot; receiving the blockchai=
+n and broadcasting transactions created by all the minor SPV connected devi=
+ces running within the house. The in-home full node would be peered with hi=
+gh 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 t=
+here should be no concern at all about centralization of relays. Full nodes=
+ could some day become as ubiquitous on the Internet as authoritative DNS s=
+ervers. And just like DNS servers, if you don&#39;t trust the nodes your IS=
+P creates or it&#39;s too slow or censors transactions, there&#39;s nothing=
+ preventing you from peering with nodes hosted by the Googles or OpenDNSs o=
+ut there, or running your own if you&#39;re really paranoid and have a few =
+extra 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.=
+google.com/u/0/113107039501292625391/posts" style=3D"font-size:x-small" tar=
+get=3D"_blank"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.pn=
+g"></a>=C2=A0<a href=3D"http://www.linkedin.com/in/ergophobe" target=3D"_bl=
+ank"><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 bun=
+t. Aim out of the ball park. Aim for the company of immortals.&quot; -- Dav=
+id 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/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 message was cr=
+eated 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></div></div><span class=3D"">------------------------------------------=
+------------------------------------<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" target=3D"_bla=
+nk">Bitcoin-development@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></span></blockquote></div>
+</blockquote></div><br></div>
+
+--e89a8f235739c721580516f7ee72--
+
+