summaryrefslogtreecommitdiff
path: root/67/fa917eb5b9faf6dc58c945353abdd29a5ffbdc
blob: 03763f0722b7d6c621b3b0420ef91ff8a1a13618 (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
160
161
162
163
164
165
166
167
168
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 746EC149D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 19 Sep 2015 01:47:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149077.authsmtp.com (outmail149077.authsmtp.com
	[62.13.149.77])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 7855017B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 19 Sep 2015 01:47:18 +0000 (UTC)
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8J1lGhC031933;
	Sat, 19 Sep 2015 02:47:16 +0100 (BST)
Received: from muck (71-89-249-159.dhcp.aldl.mi.charter.com [71.89.249.159])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t8J1lBHS043818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Sat, 19 Sep 2015 02:47:14 +0100 (BST)
Date: Fri, 18 Sep 2015 18:47:10 -0700
From: Peter Todd <pete@petertodd.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <20150919014710.GD22598@muck>
References: <CADm_WcaLKqhR=WcJ5B52Q9SAAa+AdZY6Kz5OCQVUc_RQm6e9gg@mail.gmail.com>
	<55F9E47D.50507@mattcorallo.com>
	<CAOG=w-t2ZYQbx8+mG5FX8vzgAC_tb8A6KMABmudHQbrquEqX-Q@mail.gmail.com>
	<55FC6EBF.9090504@mattcorallo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="HWvPVVuAAfuRc6SZ"
Content-Disposition: inline
In-Reply-To: <55FC6EBF.9090504@mattcorallo.com>
X-Server-Quench: 5ab129e8-5e70-11e5-9f76-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdwsUC1AEAgsB AmMbW1ZeVFp7WGY7 bAtPZQxDYE5HQQRv
	WVdMSlVNFUssCWYA WmxmMRl2dA1HcDBx Yk5qXj5eDRZ7d08o
	SlNRQGoGeGZhPWUC WRZfcR5UcAFPdx8U a1N6AHBDAzANdhEy
	HhM4ODE3eDlSNhEd eQoEKVMUTg4hHyI3 QBEEVT4oG0MIXSg1
	JBFuL18XBkFUKEgq NkE9Mf9/
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 71.89.249.159/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 development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
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: Sat, 19 Sep 2015 01:47:19 -0000


--HWvPVVuAAfuRc6SZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 18, 2015 at 08:06:23PM +0000, Matt Corallo via bitcoin-dev wrot=
e:
> I did not intend to imply that there was agreement on a desire to
> schedule a second hardfork. My wording may have been a bit too loose.
> Instead, I believe there was much agreement that doing a short-term
> hardfork now, with many agreeing that a second would hopefully be
> entirely unnecessary/impossible, while others thought that a second
> would be necessary and would have to happen. While this may set up a
> similar controversy again in several years, I think everyone agreed that
> we cannot predict the future and I, personally, think none of us should
> be committing to a viewpoint for what should be done at that time.
>=20
> Personally, I think it is also critical that there be no messaging that
> people should rely on or assume there will be a future increase after a
> short-term bump (which I also do not believe people should be relying on
> now).

Agreed!

We still seem to be in a possition where there is fundemental
disagreements about the threat model we should design for, and
ultimately, what we want Bitcoin to be. For instance, yesterday I was on
a blocksize panel, and Valery Vavilov - CEO of the ASIC manufacturer and
miner BitFury - stated that he thought we needed to setup a system of
large, high-bandwidth, high-powered, Bitcoin nodes at institutions such
as universities and large companies to allow the Bitcoin blocksize to be
raised multiple orders of magnitude. (e.g. hundreds of megabytes, or
even multiple gigabytes) In discussion with him he seemed to expect that
we'd have just a few hundred Bitcoin nodes at most, with SPV being the
standard way of using Bitcoin.

While to many of us that sounds crazy, if you're threat model assumes
Bitcoin is a legal/regulated service provided by a highly trusted mining
community it's a reasonable design. Mike Hearn recently posted his
threat model, which specifically argues we should assume governments are
not a threat. (and Hearn has previously argued that the design of
Bitcoin assumes a majority of miners are "honest" rather than merely
economically rational) Similarly Gavin Andresen was also on that panel,
and stated that he believes the idea that Bitcoin has O(n^2) scaling is
wrong, implying he doesn't think a large % of the Bitcoin user base will
continue to run fully validating nodes. (note that there are other
possibilities he could be referring to here, although again with
different security assumptions and/or unproven tech)

The main objection I raised during the committer/contributor discussions
to the idea of a "short term bump" was messaging. I think it's fair to
say that nearly all the support for a small blocksize increase stemmed
=66rom the (perceived) need to give Bitcoin users and Bitcoin
infrastructure some more time to adapt to a world where the blocksize
does not grow sufficiently to meet demand, resulting in higher
transaction fees and the practical requirement to use the Bitcoin
blockchain more efficiently. (or of course the development of genuinely
scalable blockchain technology) With that in mind, it's important that
we properly communicate that fact, or as Hearn replied, we'll run into
the same problem all over again in a few years, but with even less
safety margin in the system.

My second objection was one of science. Any bump should be accompanied
by some kind of model describing scientifically what we were trying to
achieve and where the numbers chosen came from. For instance, Pieter
Wuille's BIP103 proposes 17% per year based on a bandwidth growth model,
the assumption that bandwidth is the bottleneck we're trying to keep
constant, and the design criteria to keep centralization roughly
constant. (all else being equal) Sure there's lots of potential flaws in
that proposal, but the _message_ that we're basing it on science rather
than political "horse-trading" is very important.

As for the disagreements, it's quite likely that we can't come to
genuine consensus in the fact of those fundemental disagreements about
what Bitcoin should be. I don't have any good way to resolve that, and
I'm open to suggestions!

--=20
'peter'[:-1]@petertodd.org
000000000000000000da942d1651d405c157821a3fa55bd0c11cd9b39321e574

--HWvPVVuAAfuRc6SZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQGrBAEBCACVBQJV/L6bXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMGMyMGRhM2M5MWM2M2E1YjI5NTU4ODI2OTUwMTI4NTk2
MDgwY2NhMzg3ZGQ2OGIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzxfgf+LE1NFnJBL0UonF+M61MzRbEj
2WJDz1o1w7WiRuM1bbN78uXdaLwCCkS66TNPg82bXq0Fz5oOqGKcWUSZri9TmbwQ
t4IXGTIXgk+Kvu3qsZGcM7cJ5m1qs5EuXceQevqp8VGrnC+bhj3OHP28zTaLejup
ET7zhOkHYCro5t0Hv2ISnr11aOUq50b6zYOU4hOZlzdyf6pOKaw8XKjNZNy+s1QG
BQqtPmYoeSirXPq/2Xp/y/ya6+8ILUvK0IVg1KAP4j0TbbQ3CUJKfs1d4Ql+kvGB
VcO0qIm7jfIncUteTQZWUlzGZO3QbyheL5E6g/kGtnUFO8GuVe16GbHXWaIYCw==
=cYuL
-----END PGP SIGNATURE-----

--HWvPVVuAAfuRc6SZ--