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 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 ; 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: References: From: Jim Phillips Date: Tue, 26 May 2015 03:29:31 -0500 Message-ID: To: gabe appleton 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 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 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* *"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 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" 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* >> >> >> >> *"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 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* >>> >>> >>> >>> *"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 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 >>>> 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 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* >>>> >>>> >>>> >>>> *"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 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: 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 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* >>>> >>>> >>>> *"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
I think all the suggestions recommending cutting the block= time down also suggest reducing the rewards to compensate.

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

=C2=A0This message was created wit= h 100% recycled electrons. Please think twice before printing.<= /div>

On Tue, May 26, 2015 at 12:43 AM, gabe apple= ton <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 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.

Again, it's a trivial concern, but probably one that sho= uld be addressed.

On May 25, 2015 11:52 PM,= "Jim Phillips" <jim@ergophobia.org> wrote:
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.

--
James G. Phillips IV=C2=A0=C2=A0
"Don't bun= t. Aim out of the ball park. Aim for the company of immortals." -- Dav= id Ogilvy

<= font size=3D"1">=C2=A0This message was cr= eated 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 immortals.= " -- David Ogilvy

=C2=A0This m= essage 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:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
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.





------------------------------------------= ------------------------------------
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-de= velopment
--e89a8f235739c721580516f7ee72--