public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Roy Badami <roy@gnomon.org.uk>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
Date: Mon, 1 Jun 2015 21:15:03 +0100	[thread overview]
Message-ID: <20150601201503.GF13473@giles.gnomon.org.uk> (raw)
In-Reply-To: <20150601200149.GE13473@giles.gnomon.org.uk>

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



  reply	other threads:[~2015-06-01 20:15 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-07 22:02 [Bitcoin-development] Block Size Increase Requirements Matt Corallo
2015-05-07 23:24 ` Joseph Poon
2015-05-08  0:05 ` Peter Todd
2015-05-08  6:33   ` Arkady
2015-05-08 10:03 ` Mike Hearn
2015-05-08 16:37   ` Peter Todd
2015-05-08 19:47     ` Tier Nolan
2015-05-09  3:08       ` Peter Todd
2015-05-16  4:39         ` Stephen
2015-05-16 11:29           ` Tier Nolan
2015-05-16 11:25         ` Tier Nolan
2015-05-29 22:36 ` Gavin Andresen
2015-05-29 23:25   ` Matt Corallo
     [not found]     ` <CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
2015-05-30 19:32       ` Matt Corallo
2015-05-30 20:37         ` Gavin Andresen
2015-05-31 14:46           ` Jorge Timón
2015-05-31 14:49             ` Gavin Andresen
2015-05-31 14:59               ` Jorge Timón
2015-05-31 15:08                 ` Gavin Andresen
2015-05-31 15:45                   ` Jorge Timón
2015-05-29 23:42 ` Chun Wang
2015-05-30 13:57   ` Gavin Andresen
2015-05-30 14:08     ` Pindar Wong
2015-05-30 22:05     ` Alex Mizrahi
2015-05-30 23:16       ` Brian Hoffman
2015-05-31  0:13         ` Alex Mizrahi
2015-05-31  5:05       ` gb
     [not found]     ` <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
2015-05-31  1:31       ` [Bitcoin-development] Fwd: " Chun Wang
2015-05-31  2:20         ` Pindar Wong
2015-05-31 12:40         ` Gavin Andresen
2015-05-31 13:45           ` Alex Mizrahi
2015-05-31 14:54             ` Gavin Andresen
2015-05-31 22:55               ` Alex Mizrahi
2015-05-31 23:23                 ` Ricardo Filipe
2015-05-31 23:40                   ` Pindar Wong
2015-05-31 23:58                     ` Ricardo Filipe
2015-06-01  0:03                       ` Pindar Wong
2015-06-01  7:57                   ` Alex Mizrahi
2015-06-01 10:13                     ` Mike Hearn
2015-06-01 10:42                       ` Pindar Wong
2015-06-01 11:26                         ` Peter Todd
2015-06-01 12:19                           ` Pindar Wong
2015-06-01 11:02                       ` Chun Wang
2015-06-01 11:09                         ` Pindar Wong
2015-06-01 11:20                         ` Chun Wang
2015-06-01 13:59                           ` Gavin Andresen
2015-06-01 14:08                             ` Chun Wang
2015-06-01 15:33                               ` Mike Hearn
2015-06-01 16:06                                 ` Ángel José Riesgo
2015-06-01 14:46                             ` Oliver Egginger
2015-06-01 14:48                               ` Chun Wang
2015-06-01 16:43                             ` Yifu Guo
2015-06-01 20:01                             ` Roy Badami
2015-06-01 20:15                               ` Roy Badami [this message]
2015-06-01 13:21                         ` Mike Hearn
2015-06-01 12:29                       ` Warren Togami Jr.
2015-06-01 13:15                 ` Gavin Andresen
2015-05-31 12:52         ` Gavin Andresen
2015-05-31 13:31           ` [Bitcoin-development] [Bulk] " gb
2015-05-31 19:49             ` Gavin Andresen
2015-05-31 14:17           ` [Bitcoin-development] " Dave Hudson
2015-05-31 14:34         ` Yifu Guo
2015-05-31 14:47           ` Gavin Andresen
2015-05-31  7:05   ` [Bitcoin-development] " Peter Todd
2015-05-31 12:51     ` Gavin Andresen
2015-06-01 11:12 [Bitcoin-development] Fwd: " Thy Shizzle
2015-06-01 13:06 Thy Shizzle
2015-06-01 18:19 ` Warren Togami Jr.
2015-06-01 18:30   ` Mike Hearn
2015-06-01 18:44     ` Adam Back
2015-06-01 19:23   ` Btc Drak
2015-06-01 21:32 Thy Shizzle
2015-06-01 22:13 ` Pindar Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150601201503.GF13473@giles.gnomon.org.uk \
    --to=roy@gnomon.org.uk \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox