Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_4A2301DB-3FF9-4E20-A56E-18063FB916F0";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CADJgMzv8o8fewFa7nsFf6-2N=Qo8S2bLsTpYd7F6jcsO1oYrXA@mail.gmail.com>
Date: Thu, 28 Jan 2016 23:57:00 -0800
Message-Id: <7DA5E08C-DABB-48F8-A47F-0852F059EB74@gmail.com>
References: <42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com>
	<CADJgMzv8o8fewFa7nsFf6-2N=Qo8S2bLsTpYd7F6jcsO1oYrXA@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Classification Process
Precedence: list


--Apple-Mail=_4A2301DB-3FF9-4E20-A56E-18063FB916F0
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4A43D1AD-A345-4FD1-B653-BB8277BF773C"


--Apple-Mail=_4A43D1AD-A345-4FD1-B653-BB8277BF773C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Codebase forks with nonconsensus features are totally fine! It=E2=80=99s =
the bitterness and resentment that arose out of the need to get everyone =
to agree on something that not everyone really needs to agree on =
that=E2=80=99s the problem.

> On Jan 28, 2016, at 11:21 PM, Btc Drak <btcdrak@gmail.com> wrote:
>=20
> Your proposal does not solve the issue related to Mike creating his =
own fork. He created his own for because he had a non-consensus feature =
set that Bitcoin Core disagreed with and he wanted. That is to be =
_encouraged_. I also maintain my own Bitcoin fork with a specific =
(non-consensus) feature for the same reason and I am perfectly happy =
with the arrangement, as are my userbase.
>=20
> Classification of BIPs is fine, I have no problem with that and I =
support your BIP, but your proposition it would have stopped Mike from =
creating his own distribution is false (nor desirable): it was down to a =
strong differing of technical opinions between Mike and a dozen other =
developers as well as node security concerns (which were proved =
correct).
>=20
>=20
> On Fri, Jan 29, 2016 at 12:52 AM, Eric Lombrozo via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Folks,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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>
>=20
> 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.
>=20
>=20
> - Eric
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20


--Apple-Mail=_4A43D1AD-A345-4FD1-B653-BB8277BF773C
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"">Codebase forks with nonconsensus features are totally fine! =
It=E2=80=99s the bitterness and resentment that arose out of the need to =
get everyone to agree on something that not everyone really needs to =
agree on that=E2=80=99s the problem.<div class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Jan 28, 2016, at 11:21 PM, Btc Drak &lt;<a =
href=3D"mailto:btcdrak@gmail.com" class=3D"">btcdrak@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">Your proposal does not solve the issue related to =
Mike creating his own fork. He created his own for because he had a =
non-consensus feature set that Bitcoin Core disagreed with and he =
wanted. That is to be _encouraged_. I also maintain my own Bitcoin fork =
with a specific (non-consensus) feature for the same reason and I am =
perfectly happy with the arrangement, as are my userbase.<div =
class=3D""><br class=3D""></div><div class=3D"">Classification of BIPs =
is fine, I have no problem with that and I support your BIP, but your =
proposition it would have stopped Mike from creating his own =
distribution is false (nor desirable): it was down to a strong differing =
of technical opinions between Mike and a dozen other developers as well =
as node security concerns (which were proved correct).&nbsp;</div><div =
class=3D""><br class=3D""></div></div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Fri, Jan 29, 2016 at 12:52 AM, =
Eric Lombrozo via bitcoin-dev <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" 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" target=3D"_blank" =
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><span class=3D"HOEnZb"><font =
color=3D"#888888" class=3D""><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">- =
Eric</div></font></span></div><br =
class=3D"">_______________________________________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
<br class=3D""></blockquote></div><br class=3D""></div>
</div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_4A43D1AD-A345-4FD1-B653-BB8277BF773C--

--Apple-Mail=_4A2301DB-3FF9-4E20-A56E-18063FB916F0
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

iQIcBAEBCgAGBQJWqxtMAAoJEJNAI64YFENUBnAQAItOQxxtgrPM0wq6aRpRi59Q
6AOhMXSUA65R++gi1nkqgcv593pRrmwllAXFA9aSYXnP2eg2B3ttU/LP0kDpzv1M
tt75S3meKaX6HR5FBecShFW3i7rAg5IiD+G/6oIE/YHw0i8TFJDhK+FbmUtf9xto
sPuRP4PubR2ilI5Au27ugx1+vSyo0O93cRoquat+po1DX+TwW/uDWKkyQHl0AdN+
ydbLfb9KRmLNvP0fvegxXtPLae9Cj+bhDsPnkM+/eEuR9w39MuqqI5nR8CbRHTQs
9pLOUXvp/lDGj+lpR8vr0FSrD5avcOLv/wG6Rj2byGJiQ5yGENGgECI0Mv11R72n
iyLz+AJ4MhO8y5MyNotdRcdlFkEdW9mvTlMBjf0U5OjyYfDiUPH8l0quF0VieFdg
nuK39/UGALbdD1EDvnJNMqhUQYPR4zbA18bcJSdAfCMWudHotMsF3UqFKh0nMsJc
y8uH2j15VCO7ete9/2Yc4WFVw19xmMK8HawV14OziDyIkwfRYN5bOmEqa3+C69qf
Ws4aL49JBC2BwxZ52cL+LC8fEw/T0SREgOScVej9HWQQ8blhKPIjHUSg0o5uJvcI
5zSj461E8n6KgRAByOUmoFeV9DGvTR6n9htKnPjSrR5MsDAWewYsInXtRIW/geJA
P3rVOFtmSdfAw0zkCJL+
=iBZk
-----END PGP SIGNATURE-----

--Apple-Mail=_4A2301DB-3FF9-4E20-A56E-18063FB916F0--