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 BC97FA73; Sun, 7 Feb 2016 16:55:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 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 EAF9890; Sun, 7 Feb 2016 16:55:58 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u17GtvSc032958; Sun, 7 Feb 2016 16:55:57 GMT Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u17GtsOU044838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 16:55:54 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 9CEF740012; Sun, 7 Feb 2016 16:52:39 +0000 (UTC) Received: by savin (Postfix, from userid 1000) id A7A5B13FCB2; Sun, 7 Feb 2016 11:55:52 -0500 (EST) Received: by savin (hashcash-sendmail, from uid 1000); Sun, 7 Feb 2016 11:54:23 -0500 Date: Sun, 7 Feb 2016 11:54:23 -0500 From: Peter Todd To: Alex Morcos Message-ID: <20160207165423.GA26975@savin.petertodd.org> References: <1804222.7gVHPiWqto@kiwi> <201602062046.40193.luke@dashjr.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: X-Hashcash: 1:28:160207:morcos@gmail.com::Ys/I+et0zPUKz/H7:8im4x X-Hashcash: 1:28:160207:gavinandresen@gmail.com::7ex4zD76ZJT7xJnE:00000000000000 00000000000000000000000EM+pQ X-Hashcash: 1:28:160207:bitcoin-discuss@lists.linuxfoundation.org::DQCHK5wSzU5eH oN0:0000000000000000000DUMvZ X-Hashcash: 1:28:160207:bitcoin-dev@lists.linuxfoundation.org::FpLiIUsqCKAKdTH0: 000000000000000000000009RXNR X-Server-Quench: a7508d34-cdbb-11e5-bcde-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdgUUHlAWAgsB AmAbWlJeVVh7XGY7 bghPaBtcak9QXgdq T0pMXVMcUQRvdlhC eXseVh16dA0IeXl2 bU4sD3deXEwudkJg ERoGR3AHZDJldTJM BBVFdwNVdQJNeEwU a1l3GhFYa3VsNCMk FAgyOXU9MCtqYA50 ekkVN1UKRl0CGmx0 ZhYJBzgmBkBNTSE0 JB9uMV8OEQ4VM0Az LRM9XhpCUVcXBwJX FVBRDTQx X-Authentic-SMTP: 61633532353630.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 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-discuss@lists.linuxfoundation.org, Bitcoin Dev Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes 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: Sun, 07 Feb 2016 16:55:59 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote: > And the back and forth discussion over your BIP has been in large part a > charade. People asking why you aren't picking 95% know very well why you > aren't, but lets have an honest discussion of what the risks and in your Eh, lets not put words into people's mouths. I personally don't understand why Gavin is using 75% in the manner that he is, given there are many better alternatives, even if you don't think you can get ~100% hashing power support. > mind potential benefits of 75% are. Important debate about parameters of > your BIP get lost because we're sniping at each other about known > disagreements. For instance, I strongly believe 28 days is far too short. Note that the grace period adds a significant amount of complexity to the implementation; a much simpler alternative is to just use a hashing power activated change with a very high threshold - 99% or so - with a minimum activation date some point reasonably far into the future. Also the way the grace period is implemented means that if support *drops* after 75% is reached, the hardfork still activates (I haven't actually tested this, so I may be misunderstanding the code). Obviously, this is a dangerous situation, and an easy way for miners to "poison the well" and disruptively force the fork to be rescheduled without actually attacking the coin (nothing wrong with changing your mind! and pool distribution may change anyway). Again, a simple high % miner consensus fork with a reasonable minimum activation time avoids all these problems, with far less code complexity. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org 00000000000000000711a9829e87ba8ea548f1793950893043a5dc56893dc1dc --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWt3a6XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNzExYTk4MjllODdiYThlYTU0OGYxNzkzOTUwODkzMDQz YTVkYzU2ODkzZGMxZGMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftypwf+MSi7oWkEqP+ZR9TcN4TtfCNV tgSAbEZ0MnqcSS/1KcGGqKwDIuIMAFL4ORnOv2/CAPNx+aUU+lOQcd/xefhk0RpS /kNoYI60/LvVpi08D46MBLo42iF0ExvXKLyfLxtWH7z71mld8zPWN7BmG9de+dsn s1t0oYcjuNZVtQAC/oVUt3h+L5y7/qC8OqW7gFh9bGYzaPhIcqOXxS0IRKklImiC amAEy4H5a1N12Ztm0x4qbEXRlcXj/gDsYyWdNI1yrCZBqqwh6ZNoGrfasWOs+lML VLy4gS/Iiw0RhfRW3WVZ2amWBpe2fU67FTLaI4Y7hm+kdHbvEsVzO6+sy4oiHw== =YphC -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+--