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 B41918EA for ; Fri, 21 Aug 2015 22:21:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148108.authsmtp.net (outmail148108.authsmtp.net [62.13.148.108]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E821C11D for ; Fri, 21 Aug 2015 22:21:58 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7LMLvmw013578; Fri, 21 Aug 2015 23:21:57 +0100 (BST) Received: from muck (S0106e091f5827ad2.ok.shawcable.net [24.71.232.17]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7LMLrJ6050215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Aug 2015 23:21:56 +0100 (BST) Date: Fri, 21 Aug 2015 15:21:53 -0700 From: Peter Todd To: Tom Harding Message-ID: <20150821222153.GD7450@muck> References: <55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> <55D7575B.6030505@thinlink.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H4SyuGOnfnj3aJqJ" Content-Disposition: inline In-Reply-To: <55D7575B.6030505@thinlink.com> X-Server-Quench: 08ff232f-4853-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAMUGUATAgsB AmMbWVdeUlx7XGQ7 aQ5PagRDYElMQQRt T01BRU1TWkFvfWF9 RGQYUhxydQRDNnl3 Y0AsXngNCkZ5dxBg RkZRFnAHZDJldTIc WUhFdwNWdQpKLx5A PgF4GhFYa3VsNCMk FAgyOXU9MCtqYAhE RAgILFkbRUIaVhU7 QQwYGjErEEFNbSQv JBsnLBY2GEEaMQ0J MEksEXcRI1c5AxU2 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.71.232.17/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] Dynamically Controlled Bitcoin Block Size Max Cap 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, 21 Aug 2015 22:21:59 -0000 --H4SyuGOnfnj3aJqJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2015 at 09:52:43AM -0700, Tom Harding wrote: > On 8/20/2015 5:37 PM, Peter Todd wrote: > > On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev w= rote: >> I found that small miners were not at all disadvantaged by large > blocks. >> > > You used 20% as the size of the large miner, with all the > small miners > having good connectivity with each other. > > That is > *not* the scenario we're worried about. The math behind the > issue is > that the a miner needs to get their blocks to at least 33% of > hashing > power, but more than that is unnecessary and only helps their > > competition; you simulated 20%, which is under that threshold. Equally, > > why are you assuming the small miner group is well connected to each > > other? > > You probably didn't get any replies because your experiment > is obviously > wrong and misguided, and we're all busy. > >=20 > I gave the small miners collectively the same hashrate as the large > miners in the original test. I made them well-connected because > everyone was well-connected intra-partition in the original test. >=20 > I just varied one thing: the size of the miners. This is a principle of > experiment design, in science. >=20 > Next you'll probably claim that second-order and cross-term effects > dominate. Maybe you can find the time to prove it. This is a security issue: if you can find a likely scenario where the system fails, that's a problem and we need to fix it. You've taken the scenario where the system fails, and changed the conditions to create a scenario where it works. That's not particularly interesting or noteworthy. To use a car analogy, Pieter Wuille has shown that the brake cylinders have a fatigue problem, and if used in stop-and-go traffic regularly they'll fail during heavy braking, potentially killing someone. You've countered with a study of highway driving, showing that if the car is only used on the highway the brakes have no issues, claiming that the car design is perfectly safe. --=20 'peter'[:-1]@petertodd.org 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d --H4SyuGOnfnj3aJqJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV16R+XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwlaAf9FmXKLlG5dvBtoBIbiPhnbsQ1 ruJ6opUCV4MWqBs9NNA5cW/zsUOdHIe3F6hvYBy0wkiahok+JjNqqWdGrN1vAEqc 71ks3B9gRoRmhl4SO2D7osZ//vntvyhEbPSEjMQorcMsco8wizdCJr2MmvCaFQma 0MA3xxxT9lBlomc6ullfN1ZVdoATnAyPKwm7rTBrFPKHnKs2iViOLAx840mFqN93 VdvPLfgrgyY0T35a5pE7U2sxIdJydFZnIw4QshgCvasbbXbcDbvdxV9EMJORfq3M YC/Q+8E1H4VsJ7vXZ9NP6ukLKTcvJDQyTnJe4IwQ1GlwbuEmxoUOmbE0Z32j7A== =L+a2 -----END PGP SIGNATURE----- --H4SyuGOnfnj3aJqJ--