diff options
author | Jim Phillips <jim@ergophobia.org> | 2015-05-26 03:29:31 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-26 08:30:11 +0000 |
commit | 5cf533208c816ec1a1907c078f3d16e85c2878d0 (patch) | |
tree | 0520df2a6eb1be064e055bb5ec0c7df13440a003 | |
parent | aa814fd01877fab57482461d09fcee37a19747bd (diff) | |
download | pi-bitcoindev-5cf533208c816ec1a1907c078f3d16e85c2878d0.tar.gz pi-bitcoindev-5cf533208c816ec1a1907c078f3d16e85c2878d0.zip |
Re: [Bitcoin-development] No Bitcoin For You
-rw-r--r-- | 3d/b2beea067009b049f180d732bba458626be220 | 748 |
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>"Don't bunt. Aim out= + of the ball park. Aim for the company of immortals." -- 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"><<a href=3D"mailto:gappleto97@gmail.com" target=3D= +"_blank">gappleto97@gmail.com</a>></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'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'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'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,= + "Jim Phillips" <<a href=3D"mailto:jim@ergophobia.org" target= +=3D"_blank">jim@ergophobia.org</a>> 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 "Internet of Things" 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 "hub" 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't trust the nodes your IS= +P creates or it's too slow or censors transactions, there's nothing= + preventing you from peering with nodes hosted by the Googles or OpenDNSs o= +ut there, or running your own if you'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>"Don't bun= +t. Aim out of the ball park. Aim for the company of immortals." -- 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"><<a href=3D"mailto:jim@ergophobia.org" target=3D"_b= +lank">jim@ergophobia.org</a>></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'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't really harm the network. It&#= +39;s only if MOST relays are as slow as mine that it creates an issue. I= +9;m one node in thousands (potentially tens or hundreds of thousands if/whe= +n Bitcoin goes mainstream). And I'm an individual. There'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't need to act as a relay for that and as long as I can download b= +locks 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 altruis= +tic. It'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'm involved in several projects where we have full nodes = +running on leased servers with multiple 1Gbps connections. It's an almo= +st zero cost. Those nodes could handle 20MB blocks today without thinking a= +bout it, and I'm sure our nodes are just a few amongst thousands just l= +ike them. I'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>"= +Don't bunt. Aim out of the ball park. Aim for the company of immortals.= +" -- 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"><<a href=3D"mailto:thyshizzle@outlo= +ok.com" target=3D"_blank">thyshizzle@outlook.com</a>></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'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've seen me= +ntioned here "kicking 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 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'm good with either way. I'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'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're doing 1MB blo= +cks every minute, that's still only 10MB every 10 minutes. Eventually w= +e'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>"Don't bunt. Aim out of the ball park. Ai= +m for the company of immortals." -- 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"> +<<a href=3D"mailto:thyshizzle@outlook.com" target=3D"_blank">thyshizzle@= +outlook.com</a>></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'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"><<a h= +ref=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></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'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, "too many users" 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'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'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's time to expand capa= +city. 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 incr= +eased to the point where you are at or near the limits of capacity, you exp= +and capacity. It's as simple as that, and + I've found that same rule fits quite well in a number of systems.=C2= +=A0</div> +<div><br> +</div> +<div>In Bitcoin, we're not leaking resources. There'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'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't think of a single reason why we can'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'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>"Don't bunt. Aim out of the ball park. Ai= +m for the company of immortals." -- 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-- + + |