From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 746EC149D for ; 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 ; 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 To: Matt Corallo Message-ID: <20150919014710.GD22598@muck> References: <55F9E47D.50507@mattcorallo.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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--