Sync time wouldn't be longer compared to 20MB, it would (eventually) be longer under either setup. Also, and this is probably a silly concern, but wouldn't changing block time change the supply curve? If we cut the rate in half or a power of two, that affects nothing, but if we want to keep it in round numbers, we need to do it by 10, 5, or 2. I feel like most people would bank for 10 or 5, both of which change the supply curve due to truncation. Again, it's a trivial concern, but probably one that should be addressed. On May 25, 2015 11:52 PM, "Jim Phillips" 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 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 relays >> 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 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 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 have >> 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 thousands >> 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 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 baseline >>> by then etc. >>> ------------------------------ >>> From: Jim Phillips >>> Sent: ‎26/‎05/‎2015 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 that >>> 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 country. >>> 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps >>> connections are affordable). That equates to about 17MB per minute, or 170x >>> more capacity than what I need to receive a full copy of the blockchain if >>> I only talk to one peer. If I relay to say 10 peers, I can still handle 17x >>> larger block sizes on a slow 2Mbps connection. >>> >>> Also, even if we reduce the difficulty so that we're doing 1MB blocks >>> every minute, that's still only 10MB every 10 minutes. Eventually we're >>> going to have to increase that, and we can only reduce the confirmation >>> period so much. I think someone once said 30 seconds or so is about the >>> shortest period you can practically achieve. >>> >>> -- >>> *James G. Phillips IV* >>> >>> >>> >>> *"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: ‎26/‎05/‎2015 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 expand >>> 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 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 systems. >>> >>> In Bitcoin, we're not leaking resources. There's no flaw. The system >>> is performing as intended. Usage is increasing because it works so well, >>> and there is huge potential for future growth as we identify more uses and >>> attract more users. There might be a few technical things we can do to >>> reduce consumption, but the metric we're concerned with right now is 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, and >>> how soon can we do it. Given that most existing computer systems and >>> networks can easily handle 20MB blocks every 10 minutes, and given that >>> that will increase capacity 20-fold, I can't think of a single reason why >>> we can't go to 20MB as soon as humanly 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 >>> capacity. We can worry about ways to slow down growth without affecting the >>> usefulness of Bitcoin as we get closer to the hard technical limits on our >>> capacity. >>> >>> And you know what else? If miners need higher fees to accommodate the >>> costs of bigger blocks, they can configure their nodes to only mine >>> transactions with higher fees.. Let the miners decide how to charge enough >>> 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 > >