To: bitcoin-dev@lists.linuxfoundation.org
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<CAMBsKS8oSKS5g8UEyCu18bjzGJWpA+sJEaxBUV9FXAmXhX1ApA@mail.gmail.com>
	<CAFzgq-xnXw6efaEurLcgMQQwwr7YitrJ3vZ8i+Ha0MbnVzUKhg@mail.gmail.com>
From: Douglas Roark <joroark@vt.edu>
Message-ID: <8be6a2dc-a397-6cc5-e5d4-4c514f8f5b94@vt.edu>
Date: Tue, 28 Mar 2017 10:50:42 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
	Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAFzgq-xnXw6efaEurLcgMQQwwr7YitrJ3vZ8i+Ha0MbnVzUKhg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="cb5S5efUAoUpFSMia2sFt7PVBcW7gMoT1"
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--cb5S5efUAoUpFSMia2sFt7PVBcW7gMoT1
Content-Type: multipart/mixed; boundary="PSGnJe3T1f79f5CdHmkel4Ulgoihg6hFr";
 protected-headers="v1"
From: Douglas Roark <joroark@vt.edu>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <8be6a2dc-a397-6cc5-e5d4-4c514f8f5b94@vt.edu>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
 <CAMBsKS8oSKS5g8UEyCu18bjzGJWpA+sJEaxBUV9FXAmXhX1ApA@mail.gmail.com>
 <CAFzgq-xnXw6efaEurLcgMQQwwr7YitrJ3vZ8i+Ha0MbnVzUKhg@mail.gmail.com>
In-Reply-To: <CAFzgq-xnXw6efaEurLcgMQQwwr7YitrJ3vZ8i+Ha0MbnVzUKhg@mail.gmail.com>

--PSGnJe3T1f79f5CdHmkel4Ulgoihg6hFr
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2017/3/28 10:31, Wang Chun via bitcoin-dev wrote:
> The basic idea is, let's stop the debate for whether we should upgrade
> to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit,
> so any final decision would be a soft fork to this already deployed
> release. If by 2020, we still agree 1MB is enough, it can be changed
> back to 1MB limit and it would also a soft fork on top of that.

While I think this idea isn't bad in and of itself, there is an
assumption being made that the community would come to consensus
regarding a future soft fork. This, IMO, is a dangerous assumption.
Failure would potentially leave the network at a hard fork well past any
current proposal. It would also potentially lead to miners becoming
hostile players and making political demands. ("Soft fork down to X MB
or I'll shut down 15% of the network hashrate and work to shut down more
elsewhere.") I'd hope we can all agree that such a scenario would be
terrible.

I do agree that the idea of giving everybody plenty of time to plan is
critical. (Telecom providers need months, if not years, to plan for even
simple upgrades, which often are not as simple as they look on paper.) I
just think this proposal, while well-meaning, comes across as a bit of a
trojan horse as-is. I can't get behind it, although it could potentially
be molded into something else that's interesting, e.g., Johnson Lau's
Spoonnet. Fork-to-minimum, while introducing its own potential problems,
would put much less pressure on full nodes, and on the ecosphere as a
whole if the max needed to be soft forked down.

(I'd also like to see SegWit go live so that we can get an idea of how
much pressure there really is on the network, thereby giving us a better
idea of how high we can go. I still think we're flying a bit blind in
that regard.)

--=20
---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark@vt.edu
PGP key ID: 26623924


--PSGnJe3T1f79f5CdHmkel4Ulgoihg6hFr--

--cb5S5efUAoUpFSMia2sFt7PVBcW7gMoT1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJY2qJ6AAoJEEOBHRomYjkkXZcP/38qrnjqLf2xYpDaO/SMTnbB
wA+0pbUATddiQqJ9i9kfGfc/vU5fSsqns/H+4RemDW/lCJ92xdyiWPJ1SXsx1OQh
mlkdIiLfWzn7vg1yVxnauST8cNNh3eL4x4iv+T/+jvhI0gIpIJzWmB+wqHc0jtUf
/+tE7abA5qVkw0JPSaPf98fQvYlcts+13oW1gfjvsPvNKGwWNeVuSrBp0CCFzp4C
c46epMf/OuHhNef60ahP700qnwQGI+wUcZZql5uD6sySHUy5r21bGHd3krVz5mw+
1m5qFKM3Wz5raklgt8bR8dH6y1UxfbUfsCXDYY9uaneegSzd9vcE84yPrGcOcmQ+
5GrjKwDi1AHHJhY/KzNwI7Cf7xek4Aex6+56xTuC2oOIw005uH3tilZHxnKYcYYD
9dn1pJWPyjw5/6CRupbC9fO60/bB1FY7ltCdzh1EuetAP+tRcqAFABsxVMeFBBew
Siud+tqFzTrBEX9Wtkq+dqym9L0rPATn0+CgHQOSw3+reKGFEABgHoWV9aOve5y7
ijOVzYTYeiZr4wdh3wVtLCKbc62+EZgJ0idZrYlh1Mp8k+y30Axw2X8qDXD/SKZJ
O/h3z3SQK6Q31Fwd5uemrNd7LCHjHa4bH6ryBivHouExn0gn7/Vwr6tTI+INhtd/
kb2emzGb7DpI5clI5DIe
=vgTH
-----END PGP SIGNATURE-----

--cb5S5efUAoUpFSMia2sFt7PVBcW7gMoT1--