From: Peter Todd <pete@petertodd•org>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Date: Fri, 26 Jun 2015 15:25:28 -0400 [thread overview]
Message-ID: <20150626192528.GC10387@muck> (raw)
In-Reply-To: <CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3401 bytes --]
On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote:
> > In any case, this ponts to the need for your proposal to explictly talk
> > about what kind of resources are needed by miners for what kind of
> > profitability, including the case where other miners are sabotaging
> > their profitability.
> >
>
> Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ?
>
> I have written quite a lot about the kind of resources needed to run a full
> node, and have asked you, specifically, several times "how much do you
> think is too much" and received no answer.
You're the one proposing a change here; we're evaluating the safety of
that change.
An analogous situation is imagine we have two islands, with a suspension
bridge between them. The bridge has just two lanes in either direction,
so obviously there's a limited amount of traffic that can flow across
it. It used to be used to little that people would joyride back and
forth as the toll booths at either end just charged a hundreth of a
penny per trip, or even not at all, but as demand has been increasing
tolls are going up as well.
You've come along with a bold new plan to add fifteen more lanes to that
bridge by expanding the bridge deck, then hire contractors in advance to
double the number of lanes every two years after that with no clear way
of terminating their contract if anything goes wrong. (in just over a
decade our two lane bridge will be a mile wide!)
Of course, obviously if we add enough lanes the cables holding it up
will snap, so we've better carefully analyse the carrying capacity of
the brdige and the threats it faces. For instance, earthquakes happen
every so often - the last one even snapped a few strands in the main
cables, which people claim were fixed... but we don't really know for
sure as a thick layer of paint was quickly slapped over the fix and
no-one's been able to inspect it.
It's perfectly reasonable to ask what kind of earthquakes you expect the
bridge to withstand, as well as peer-reviewed and peer-reproducable
figures about the strength of the cables and the weight of the traffic.
Similarly, we've got the funds to make a test bridge of the same
dimensions and see if it collapses. Any bridge widening proposal that
doesn't have this data is simply incomplete, end of story.
As for the other side, the worst that happens if nothing changes is
usage of this bridge gets proportioned to the most valuable users by the
supply and demand toll system. Some people might decide to take the bus
across rather than an inefficient individual car, some of the
advertising companies running trucks back and forth with billboards on
the side are going to stop doing that. But traffic is still going to get
across. It's not a politically easy position to be in - there's enormous
pressure to quickly "do something" however dangerous - but the actual
effects of doing nothing are ultimately not a big deal.
In civil engineering we have enough experience with disasters to know
that you can't give into political pressure to do potentially dangerous
things until the consequences are well understood; hopefully we'll learn
that in the consensus cryptography space before a big disaster rather
than after.
--
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-06-26 19:25 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 18:18 Gavin Andresen
2015-06-22 18:33 ` Tier Nolan
2015-06-22 18:46 ` Gavin Andresen
2015-06-22 19:10 ` Martin Schwarz
2015-06-22 19:28 ` Tier Nolan
2015-06-22 19:54 ` Gavin Andresen
2015-06-22 20:12 ` Peter Todd
2015-06-22 19:23 ` Peter Todd
2015-06-23 7:35 ` Ross Nicoll
2015-08-17 15:58 ` Jorge Timón
2015-06-23 19:16 ` Peter Todd
2015-06-22 20:27 ` Kalle Rosenbaum
2015-06-22 20:46 ` Gavin Andresen
2015-06-22 20:51 ` Gavin Andresen
2015-06-22 21:52 ` Mark Friedenbach
2015-06-23 19:28 ` Peter Todd
2015-06-23 20:12 ` Gavin Andresen
2015-06-23 20:26 ` Pieter Wuille
2015-06-23 20:50 ` Peter Todd
2015-06-24 6:14 ` grarpamp
2015-06-23 20:46 ` Peter Todd
2015-06-23 21:24 ` Gavin Andresen
2015-06-26 19:08 ` Peter Todd
2015-06-26 22:01 ` Ivan Brightly
2015-06-26 19:25 ` Peter Todd [this message]
2015-06-26 22:16 ` Simon Liu
2015-06-27 2:14 ` Milly Bitcoin
2015-06-23 20:55 ` Roy Badami
2015-06-24 1:43 ` odinn
2015-06-24 3:05 ` William Madden
2015-06-24 3:49 ` Jeff Garzik
2015-06-24 13:06 ` Will
2015-06-24 13:44 ` Gavin Andresen
2015-06-25 0:32 ` Pindar Wong
2015-06-25 13:50 ` Gareth Williams
2015-06-25 14:07 ` Adam Back
2015-06-26 13:47 ` Tier Nolan
2015-06-26 15:13 ` Will
2015-06-26 17:39 ` Gavin Andresen
2015-06-26 19:07 ` Will
2015-07-01 22:49 ` odinn
2015-08-17 13:15 ` Tier Nolan
2015-08-17 13:18 ` Clément Elbaz
2015-08-19 3:45 ` odinn
2015-08-17 16:11 ` Jorge Timón
2015-06-26 21:07 ` Carsten Otto
2015-06-22 19:32 Jean-Paul Kogelman
2015-06-22 20:43 ` Tier Nolan
2015-06-22 20:54 ` Peter Todd
2015-06-22 21:04 ` Stephen Morse
2015-06-22 21:32 ` Ross Nicoll
2015-08-17 15:54 ` Jorge Timón
2015-06-22 21:21 ` Gavin Andresen
2015-06-22 21:39 ` Patrick Strateman
2015-06-22 21:48 ` Tier Nolan
2015-06-23 7:59 Ross Nicoll
2015-06-24 4:31 Raystonn
2015-06-24 17:05 ` Mark Friedenbach
2015-06-24 17:24 ` Roy Badami
2015-06-24 17:23 Raystonn
2015-06-24 17:24 ` Allen Piscitello
2015-06-24 17:28 ` Roy Badami
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=20150626192528.GC10387@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--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