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