From: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_67A54A39-3546-4C46-8152-C397BB40F45D";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Thu, 28 Jan 2016 16:52:53 -0800
Message-Id: <42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Subject: [bitcoin-dev] BIP Classification Process
Precedence: list


--Apple-Mail=_67A54A39-3546-4C46-8152-C397BB40F45D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_53742A85-78F0-4090-8847-E4A5820701E2"


--Apple-Mail=_53742A85-78F0-4090-8847-E4A5820701E2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Folks,

I think the current situation with forks could have been avoided with a =
better process that can distinguish between different layers for bitcoin =
modification proposals.

For instance, BIP64 was proposed by Mike Hearn, which does not affect =
the consensus layer at all. Many Core devs disliked the proposal and =
Mike had lots of pushback. Regardless of whether or not you agree with =
the merits of Mike=E2=80=99s ideas here, fact is having nodes that =
support BIP64 would not fundamentally break the Bitcoin network.

This issue prompted Mike to break off from Core and create XT as the =
applications he was developing required BIP64 to work. With this split, =
Gavin found a new home for his big block ideas=E2=80=A6and the two =
teamed up.

We need to have a process that clearly distinguishes these different =
layers and allows much more freedom in the upper layers while requiring =
agreement at the consensus layer. Many of these fork proposals are =
actually conflating different features, only some of which would =
actually be consensus layer changes. When people proposing nonconsensus =
features get pushback from Core developers they feel rejected and are =
likely to team up with others trying to push for hard forks and the =
like.

A while back I had submitted a BIP -  BIP123 - that addresses this =
issue. I have updated it to include all the currently proposed and =
accepted BIPs and have submitted a PR: =
https://github.com/bitcoin/bips/pull/311 =
<https://github.com/bitcoin/bips/pull/311>

I urge everyone to seriously consider getting this BIP accepted as a top =
priority before we get more projects all trying their hand at stuff and =
not understanding these critical distinctions.


- Eric

--Apple-Mail=_53742A85-78F0-4090-8847-E4A5820701E2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Folks,<div class=3D""><br class=3D""></div><div class=3D"">I =
think the current situation with forks could have been avoided with a =
better process that can distinguish between different layers for bitcoin =
modification proposals.</div><div class=3D""><br class=3D""></div><div =
class=3D"">For instance, BIP64 was proposed by Mike Hearn, which does =
not affect the consensus layer at all. Many Core devs disliked the =
proposal and Mike had lots of pushback. Regardless of whether or not you =
agree with the merits of Mike=E2=80=99s ideas here, fact is having nodes =
that support BIP64 would not fundamentally break the Bitcoin =
network.</div><div class=3D""><br class=3D""></div><div class=3D"">This =
issue prompted Mike to break off from Core and create XT as the =
applications he was developing required BIP64 to work. With this split, =
Gavin found a new home for his big block ideas=E2=80=A6and the two =
teamed up.</div><div class=3D""><br class=3D""></div><div class=3D"">We =
need to have a process that clearly distinguishes these different layers =
and allows much more freedom in the upper layers while requiring =
agreement at the consensus layer. Many of these fork proposals are =
actually conflating different features, only some of which would =
actually be consensus layer changes. When people proposing nonconsensus =
features get pushback from Core developers they feel rejected and are =
likely to team up with others trying to push for hard forks and the =
like.</div><div class=3D""><br class=3D""></div><div class=3D"">A while =
back I had submitted a BIP - &nbsp;BIP123 - that addresses this issue. I =
have updated it to include all the currently proposed and accepted BIPs =
and have submitted a PR: <a =
href=3D"https://github.com/bitcoin/bips/pull/311" =
class=3D"">https://github.com/bitcoin/bips/pull/311</a></div><div =
class=3D""><br class=3D""></div><div class=3D"">I urge everyone to =
seriously consider getting this BIP accepted as a top priority before we =
get more projects all trying their hand at stuff and not understanding =
these critical distinctions.</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">- =
Eric</div></body></html>=

--Apple-Mail=_53742A85-78F0-4090-8847-E4A5820701E2--

--Apple-Mail=_67A54A39-3546-4C46-8152-C397BB40F45D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

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

iQIcBAEBCgAGBQJWqrflAAoJEJNAI64YFENUnDwQALq2i7+SGS0QcapK3JizxecT
1WXMeu4AeW78C51tpmH5YCEKEvXsEQz+o+X/DCcIHxY3cTXxc0RMdb7toFC3f/0V
WnP16dQBsav9zXkAj1vK6FpehCB7RUBK0HDxBCGJfunSPisQHnHnxRc96hPmpu78
aNkIxM5K+vkEJMq0+6KFFQQmFU6n7yXhiRso8ZW1wVhrWhAH5SvLMOcVN9PUoxgW
EEp12eoYUBkPyHzMfoWBJ75huHcWXeoUptfmw3fsEEY1CrvBHUhVKQKnkXebsnSQ
2BOBF477a2wl5sMqdjfpOhGx5DBIeU3o32lE/iU6wqH0YKnjSKabvf2dJiASv9qF
QG4IJqroSPNGYfTdcDq3VQGKhkrMbegUjxqYJKh50BUcjPS+QhEXK9qe52CHM2Ft
9QgHWdATRDYIheTiLK9MgUOTGRYonVfaTm5986JYeYobSISpLtoRAwMSAwYDkUwh
vOeRMXe76L5PaRfrVjpCiRMIdvY6MBY+gzfOsJKijyQjHjPe2fvgz5sQzDawdvCf
iqseUKyCx6JWcZX7ED+C5TotPuSdvBEMg/4+2AvRseJz8/u4d6/EERhKKGKKNCSv
GJeGM5yLru7cqk1Rbw0fUb67NBwHCWpYmTxOTJpNuvQ5EVdCuKPbcFihG0uNxeGl
DlG54BmHG87LujTL8XtG
=06zP
-----END PGP SIGNATURE-----

--Apple-Mail=_67A54A39-3546-4C46-8152-C397BB40F45D--