Date: Sun, 7 Feb 2016 11:54:23 -0500
From: Peter Todd <pete@petertodd.org>
To: Alex Morcos <morcos@gmail.com>
Message-ID: <20160207165423.GA26975@savin.petertodd.org>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<CABm2gDoungCbB22_SKHcedBKegWEPpjeM2woxLGchC4=om8BrA@mail.gmail.com>
	<1804222.7gVHPiWqto@kiwi> <201602062046.40193.luke@dashjr.org>
	<CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
	<CAPWm=eVG1MFygACo6Mb6iLSe=GwjygTjjKhmN1Btu9Uyw+Vc-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+"
Content-Disposition: inline
In-Reply-To: <CAPWm=eVG1MFygACo6Mb6iLSe=GwjygTjjKhmN1Btu9Uyw+Vc-w@mail.gmail.com>
Cc: bitcoin-discuss@lists.linuxfoundation.org,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
 megabytes
Precedence: list


--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+--