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:01:50 +0100 [thread overview]
Message-ID: <20150601200149.GE13473@giles.gnomon.org.uk> (raw)
In-Reply-To: <CABsx9T2aEvPs68pQA-KrtaDQFcTTtiB36eqKAcJRkiOFQr6WsA@mail.gmail.com>
> 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
next prev parent reply other threads:[~2015-06-01 20:02 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 22:02 [Bitcoin-development] " 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 [this message]
2015-06-01 20:15 ` Roy Badami
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=20150601200149.GE13473@giles.gnomon.org.uk \
--to=roy@gnomon$(echo .)org.uk \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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