summaryrefslogtreecommitdiff
path: root/0d/1ac5e4a6b8b66bae55134fd4e3fadfcdc09421
blob: def3fd02cbd802bae8cb9831bd89a622a9390d23 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 10D4FACB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 26 Jun 2015 19:25:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149075.authsmtp.net (outmail149075.authsmtp.net
	[62.13.149.75])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3C897144
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 26 Jun 2015 19:25:45 +0000 (UTC)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5QJPgpr098218;
	Fri, 26 Jun 2015 20:25:42 +0100 (BST)
Received: from muck (static-71-247-144-172.nycmny.east.verizon.net
	[71.247.144.172]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5QJPTwo096810
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 26 Jun 2015 20:25:38 +0100 (BST)
Date: Fri, 26 Jun 2015 15:25:28 -0400
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20150626192528.GC10387@muck>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<20150623192838.GG30235@muck>
	<CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
	<20150623204646.GA18677@muck>
	<CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="WChQLJJJfbwij+9x"
Content-Disposition: inline
In-Reply-To: <CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com>
X-Server-Quench: 22b28e09-1c39-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdAQUEkAaAgsB AmMbWVReUlh7XWE7 bAtPbwFafEtKWxtr
	V0pWR1pVCwQmRRlg fH56FUZyfgNOeX4+ Z0ZnXHAVXkYod04o
	QkdJFD4FbHphaTUa TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
	FQ4vNDcwO3BTJTpg Ci0XJFwOCWwqJnZu Dx4DDTgjWFYORyg/
	MhgrYlQYG00Sel4z I1ZpWFQTKRIbEQA2 
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 71.247.144.172/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2015 19:25:46 -0000


--WChQLJJJfbwij+9x
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
> >
>=20
> Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ?
>=20
> I have written quite a lot about the kind of resources needed to run a fu=
ll
> 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.

--=20
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24

--WChQLJJJfbwij+9x
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVjaclXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMDdmYzEzY2UwMjA3MmQ5Y2IyYTZkNTFmYWU0MWZlZmNk
ZTdiM2IyODM4MDNkMjQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udw8WggAgWrt1w7Bxfh3sIDU1gTKS/1u
RXPZtZiSdU7fzwPOtkDc05Tl9fmTtD1j1fbC551nDDLEVa53ecIW8GKHHWdaEWU0
/C8mdQ82kaOKlZW0U+EcJ32gzRJ5kWR4G1PtYHw/gMVRqHYbrg0uQbHxD2we2H9Z
cAwHC8XG2cBh2b3U1e5k909eHJwlX7Xo1GDSZiDTpmKMplUcjLFg2ubrlWU4cVYV
t1qT65qdLlekx01OuKAa03fteHC4PdoigVw2zWx6hFnOsLkS4482p9tUJiy+WjZY
b6cRtUCTsvFHDjysnRea8gX/sOoV8d7CebBpKtlT2gyk2XLiGETKcq7btBf4Kw==
=KZIF
-----END PGP SIGNATURE-----

--WChQLJJJfbwij+9x--