Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7C631AAC for ; Tue, 23 Jun 2015 20:46:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148106.authsmtp.co.uk (outmail148106.authsmtp.co.uk [62.13.148.106]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id A55DA137 for ; Tue, 23 Jun 2015 20:46:57 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5NKkpxq031717; Tue, 23 Jun 2015 21:46:51 +0100 (BST) Received: from muck ([209.141.138.18]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5NKklao043884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 23 Jun 2015 21:46:49 +0100 (BST) Date: Tue, 23 Jun 2015 16:46:47 -0400 From: Peter Todd To: Gavin Andresen Message-ID: <20150623204646.GA18677@muck> References: <20150623192838.GG30235@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: X-Server-Quench: f8f7825f-19e8-11e5-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAEUEkAaAgsB AmMbWVVeVFt7XGM7 aQpYcwRZY1RPXA10 UUBWR1pVCwQmRRl/ fUVCA0ZycwZOcHo+ ZEBjWXYVCkwsck5/ RxhJFGRTbXphaTUa TUkOcAdJcANIexZF O1F8UScOLwdSbGoL FQ4vNDcwO3BTJTpg Ci0XJFwOCWwqJnZu Dx4DDTgjWFYORyg/ MhgrYlQYG00Sel4z I1ZpWFQTKRIbEQA2 X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 209.141.138.18/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: Tue, 23 Jun 2015 20:46:58 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 23, 2015 at 04:12:17PM -0400, Gavin Andresen wrote: > > In particular, if bandwidth scaling doesn't go according to your plan, > > e.g. the exponential exponent is too large, perhaps due to technological > > growth not keeping pace, or the political realities of actual bandwidth > > deployment making theoretical technological growth irrelevant, what > > mechanism will prevent centralization? (if any) >=20 >=20 > Simulations show that: >=20 > Latency/bandwidth matter for miners. Low latency, high bandwidth is > better. However, miners with bad connectivity can simply create smaller > blocks... Pieter Wuille showed with simulations that miners with bad connectivity are negatively affected by other miners creating larger blocks. Similarly I showed that with equation-based analysis. I've seen no response to either argument, and it's a centralization pressure. Note how propagation times are important enough to miners that they already mine on top of unverified headers from other miners to increase profitability, a grave threat to the security of the Bitcoin network. > ... until transaction fees become significant. But by the time that > happens, protocol optimizations of block propagation will make the block > size an insignificant term in the "how profitable is it to mine in THIS > particular place on the Internet / part of the world" equation. These block propagation improvements are both already implemented (Matt Corallo's relay network, p2pool) and require co-operation. For instance, notice the recent full-RBF debate where Coinbase said they'd consider getting contracts directly with miners to get transactions they desired mined even when they otherwise would not be due to double-spends. This is one of many scenarios where block propagation improvements fail. Thus for a safety engineering analysis we need to talk about worst-case scenarios. Equally, I don't see any analysis from anyone of that % of non-optimized transactions need to fail for what kind of centralizing pressure. 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 'peter'[:-1]@petertodd.org 000000000000000008c0be16e152f86ab3a271a13c3f41c56228d72990abf7bd --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVicW0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwOGMwYmUxNmUxNTJmODZhYjNhMjcxYTEzYzNmNDFjNTYy MjhkNzI5OTBhYmY3YmQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udypSgf/Xlj8fPuGUDZWDAUtxQCvpN9r tP6rjejtLUBrXytx+px1Q7+0LoJ/aywz1FNcIRyfusaRTiZuZ0aL9SoG0BGwJujw rR03uP7mLmSxCjQzI4/g8Q+1JHYx1w9L7gcN3KDkEGBBrd8JJYs5klSW8TZewfpp xw6jS8LErvcqsj5LSx+LA4t6bXqI2gnOxr5aaJQw/V7zJ5HJh9cFspdE9pM0zdZB kfMbmsOWzsJwEVZGvQgHTOnPgyNv/wjHJj7gTh/SQPEXUVZahwUEh6utkK15E/l9 qJKtcG5t3slq9IGx3E4qCJKQSoBIix1bPYWMfN9PyVAReX5cWuRZZKr7zaRFHg== =ZuF8 -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv--