On Mon, Jun 01, 2015 at 09:01:49PM +0100, Roy Badami wrote: > > What do other people think? Would starting at a max of 8 or 4 get > > consensus? Scaling up a little less than Nielsen's Law of Internet > > Bandwidth predicts for the next 20 years? (I think predictability is > > REALLY important). > > TL;DR: Personally I'm in favour of doing something relatively > uncontroversial (say, a simple increase in the block size to something > in the 4-8GB range) with no further increases without a further hard > fork.
And the other bit I should have added to my TL;DR: If we end up spending a significant proportion of the next 20 years discussing the then _next_ hard fork, that's a *good* thing, not a *bad* thing. Hard forks need to become, if not entirely routine, then certainly less scary. A sequence of (relatively) uncontroversial hard forks over time is way more likely to gain consensus than a single hard fork that attempts to set a schedule for block size increases out to 2035. IMHO. > > I'm not sure how relevent Nielsen's Law really is. The only relevent > data points Nielsen has really boil down to a law about how the speed > of his cable modem connection has changed during the period 1998-2014. > > Interesting though that is, it's not hugely relevent to > bandwidth-intensive operations like running a full node. The problem > is he's only looking at the actual speed of his connection in Mbps, > not the amount of data usage in GB/month that his provider permits - > and there's no particular reason to expect that both of those two > figures follow the same curve. In particular, we're more interested > in the cost of backhaul and IP transit (which is what drives the > GB/month figure) than we are in improvements in DOCSIS technology, > which have little relevence to node operators even on cable modem, and > none to any other kind of full node operator, be it on DSL or in a > datacentre. > > More importantly, I also think a scheduled ramp up is an unnecessary > complication. Why do we need to commit now to future block size > increases perhaps years into the future? I'd rather schedule an > uncontroversial hard fork now (if such thing is possible) even if > there's a very real expectation - even an assumption - that by the > time the fork has taken place, it's already time to start discussing > the next one. Any curve or schedule of increases that stretches years > into the future is inevitably going to be controversial - and more so > the further into the future it stretches - simply because the > uncertainties around the Bitcoin landscape are going to be greater the > further ahead we look. > > If a simple increase from 1GB to 4GB or 8GB will solve the problem for > now, why not do that? Yes, it's quite likely we'll have to do it > again, but we'll be able to make that decision in the light of the > 2016 or 2017 landscape and can again make a simple, hopefully > uncontroversial, increase in the limit at that time. > > So, with the proviso that I think this is all bike shedding, if I had > to pick my favourite colour for the bike shed, it would be to schedule > a hard fork that increases the 1GB limit (to something in the 4-8GB > range) but with no further increases without a further hard fork. > > Personally I think trying to pick the best value of the 2035 block > size now is about as foolish as trying to understand now the economics > of Bitcoin mining many halvings hence. > > NB: this is not saying that I think we shouldn't go above 8GB in the > relatively foreseeable future; quite the contrary, I strongly expect > that we will. I just don't see the need to pick the 2020 block size > now when we can easily make a far better informed decision as to the > 2020 block size in 2018 or even 2019. > > As to knowing what the block size is going to be for the next 20 years > being "REALLY important"? 100% disagree. I also think it's > impossible, because even if you manage to get consensus on a block > size increase schedule that stretches out to 2035 (and my prediction > is you won't) the reality is that that block size schedule will have > been modified by a future hard fork long before we get to 2035. > > What I personally think is REALLY important is that the Bitcoin > community demonstrates an ability to react appropriately to changing > requirements and conditions - and we'll only be able to react to those > conditions when we know what they are! My expectation is that there > will be several (hopefully _relatively_ uncontroversial) scheduled > hard forks between now and 2035, and each of those will be discussed > in suitable detail before being agreed. And that's as it should be. > > roy ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
