From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1Yx5s8-0007FB-8h for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 03:49:44 +0000 X-ACL-Warn: Received: from mail-wg0-f48.google.com ([74.125.82.48]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yx5s5-0003wm-O0 for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 03:49:44 +0000 Received: by wgbgq6 with SMTP id gq6so85363829wgb.3 for ; Mon, 25 May 2015 20:49:35 -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=ZZ7luF4JKmjtXSL6TTPpq+b32+eF678oixkxBBg5xPQ=; b=G57AlIrCQs9s/zThCsdZFp1o/o1NLBOrs6j2NVXgAJuCB9I2LsH4lKZLD5Nni0CVme 1p9r4rlod6q4VVnDwGqxhNm+KGXtGTiQQndCus3CxSJApXnnCjQ8va/Rax6iWm6gbzQX H8FFZgfWoyKbzZSxHfUc/zAReSo380xBwsDyejU6bnAzuZyB9jhgSMInBT4aQ72Xo45V 6hGOjuSkMjTFT3+WXTYQqdBu98Lprfl++VzVFqAXnn9loA339QmMVnHC1oqVT2xaAWgP KRKDWCTpsxVaJ+vlZA4wR5qI0vji7SXkHMhFWYovsip/9WMjQ3gGS3jXYO74u4SAcXi3 1hQA== X-Gm-Message-State: ALoCoQmBT2pz2UkNU+62vm8dWTPHH/SvZXi1R21cNVJ1yhNh/czlh//0QIEE/2M0TS/+W+fyf2NT X-Received: by 10.180.187.203 with SMTP id fu11mr34291966wic.26.1432612175530; Mon, 25 May 2015 20:49:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.246.69 with HTTP; Mon, 25 May 2015 20:49:04 -0700 (PDT) In-Reply-To: References: From: Jim Phillips Date: Mon, 25 May 2015 22:49:04 -0500 Message-ID: To: Thy Shizzle Content-Type: multipart/alternative; boundary=001a11c267d8d2e0c10516f4032d X-Spam-Score: 1.0 (+) 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 X-Headers-End: 1Yx5s5-0003wm-O0 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] No Bitcoin For You X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 03:49:44 -0000 --001a11c267d8d2e0c10516f4032d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 should be no concern at all about centralization of relays. Full nodes could some day become as ubiquitous on the Internet as authoritative DNS servers. And 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 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* *"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 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 relay= s > 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 ru= n > a full node from my home, except to have my own trusted and validated cop= y > of the blockchain on a computer I control directly. I don't need to act a= s > a relay for that and as long as I can download blocks faster than they ar= e > created I'm fine. Also, I can easily afford a VPS server or several to ru= n > full nodes as relays if I am feeling altruistic. It's actually cheaper fo= r > me to lease a VPS than to keep my own home PC on 24/7, which is why I hav= e > 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 thousand= s > 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* > > > > *"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 > 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 "kicking >> the can down the road" I agree that this is doing this, however as you s= ay >> 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 lo= ok >> to bump up block size because hopefully 20mbps connections will be basel= ine >> by then etc. >> ------------------------------ >> From: Jim Phillips >> Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:53 PM >> To: Thy Shizzle >> Cc: Mike Hearn ; Bitcoin Dev >> >> >> 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 tha= t >> is in line with what current technology can handle. We can handle WAY mo= re >> 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 country= . >> 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps >> connections are affordable). That equates to about 17MB per minute, or 1= 70x >> 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* >> >> >> >> *"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 >> 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 an= d >> just increase the transaction throughput. >> ------------------------------ >> From: Jim Phillips >> Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM >> To: Mike Hearn >> Cc: Bitcoin Dev >> Subject: Re: [Bitcoin-development] No Bitcoin For You >> >> >> On Mon, May 25, 2015 at 1:36 PM, Mike Hearn 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 living= in >> a dreamworld think that Bitcoin might actually have to match that level = 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 expa= nd >> 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 ar= e >> at or near the limits of capacity, you expand capacity. It's as simple a= s >> that, and I've found that same rule fits quite well in a number of syste= ms. >> >> 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, an= d >> 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 how >> 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, a= nd >> 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 wh= y >> we can't go to 20MB as soon as humanly possible. And in a few years, whe= n >> the average block size is over 15MB, we bump it up again to as high as w= e >> 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 o= ur >> 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 enou= gh >> to pay for their costs. We don't need to cripple the network just for th= em. >> >> -- >> *James G. Phillips IV* >> >> >> *"Don't bunt. Aim out of the ball park. Aim for the company of >> immortals." -- David Ogilvy * >> >> *This message was created with 100% recycled electrons. Please think >> twice before printing.* >> >> >> > --001a11c267d8d2e0c10516f4032d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Incidentally, even once we have the "Internet of Thin= gs" 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 high bandwidth full-node relays running at the ISP or in the cl= oud. There are more than enough ISPs and cloud compute providers in the wor= ld such that there should be no concern at all about centralization of rela= ys. Full nodes could some day become as ubiquitous on the Internet as autho= ritative DNS servers. And 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 from peering with nodes hosted by the Googles= or OpenDNSs out there, or running your own if you're really paranoid a= nd have a few extra bucks for a VPS.

--
James G. Phill= ips IV=C2=A0=C2=A0
"Don't bunt. Aim out of the ball park. Aim fo= r the company of immortals." -- David Ogilvy

=C2=A0This message was created with 100% recycled electrons.= Please think twice before printing.

On Mon, May 25, 2015 at 10:23 PM, Jim Philli= ps <jim@ergophobia.org> wrote:
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.

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.

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.
=
--
James G. Phillips IV=C2=A0=C2=A0
= "Don't bunt. Aim out of the ball park. Aim for the company of i= mmortals." -- David Ogilvy

=C2=A0This message was created with 100% recycled electrons. Please think twic= e before printing.

On Mon, May 25= , 2015 at 10:02 PM, Thy Shizzle <thyshizzle@outlook.com> wrote:
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.
From: Jim Phillips Sent: =E2=80= =8E26/=E2=80=8E05/=E2=80=8E2015 12:53 PM
To: Thy Shizzle
Cc: Mike Hearn; Bitcoin Dev

Subject: Re: [B= itcoin-development] No Bitcoin For You

Frankly I'm good with either way. I'm definitely i= n favor of faster confirmation times.=C2=A0

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.

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.=

--
James G. Phillips IV=C2=A0=C2=A0=
"Don't bunt. Aim out of the ball park. Ai= m for the company of immortals." -- David Ogilvy

=C2=A0This 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 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.
From: Jim Phillips Sent: =E2=80= =8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM
To: Mike Hearn
Cc: Bi= tcoin Dev
Subject: Re: [B= itcoin-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 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!


... And will certainly NEVER have if we can't solve the capacity p= roblem SOON.=C2=A0

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

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.

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.

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.

--
James G. Phillips IV=C2=A0=C2=A0=
"Don't bunt. Aim out of the ball park. Ai= m for the company of immortals." -- David Ogilvy

=C2=A0This message was created with 100% recycled ele= ctrons. Please think twice before printing.




--001a11c267d8d2e0c10516f4032d--