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>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
Precedence: list


--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--