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 10D4FACB for ; 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 ; 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 To: Gavin Andresen Message-ID: <20150626192528.GC10387@muck> References: <20150623192838.GG30235@muck> <20150623204646.GA18677@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WChQLJJJfbwij+9x" Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--