MIME-Version: 1.0
In-Reply-To: <42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com>
References: <42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Fri, 29 Jan 2016 07:21:10 +0000
Message-ID: <CADJgMzv8o8fewFa7nsFf6-2N=Qo8S2bLsTpYd7F6jcsO1oYrXA@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a777e50547a052a73e23c
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Classification Process
Precedence: list

--001a113a777e50547a052a73e23c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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).


On Fri, Jan 29, 2016 at 12:52 AM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 actual=
ly
> 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 u=
p
> 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
>
> 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 n=
ot
> understanding these critical distinctions.
>
>
> - Eric
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a113a777e50547a052a73e23c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Your proposal does not solve the issue related to Mike cre=
ating his own fork. He created his own for because he had a non-consensus f=
eature set that Bitcoin Core disagreed with and he wanted. That is to be _e=
ncouraged_. I also maintain my own Bitcoin fork with a specific (non-consen=
sus) feature for the same reason and I am perfectly happy with the arrangem=
ent, as are my userbase.<div><br></div><div>Classification of BIPs is fine,=
 I have no problem with that and I support your BIP, but your proposition i=
t 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).=C2=A0</div><div><br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Fri, Jan 29, 2016 at 12:52 AM, Eri=
c Lombrozo via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfou=
ndation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div st=
yle=3D"word-wrap:break-word">Folks,<div><br></div><div>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><br></div><div>For instance, BIP64 was proposed by Mike Hearn, whi=
ch 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 ag=
ree 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=
><br></div><div>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 t=
eamed up.</div><div><br></div><div>We need to have a process that clearly d=
istinguishes these different layers and allows much more freedom in the upp=
er layers while requiring agreement at the consensus layer. Many of these f=
ork proposals are actually conflating different features, only some of whic=
h would actually be consensus layer changes. When people proposing nonconse=
nsus 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><br></div><div>A while back I had submitted a BIP - =C2=A0BIP123 -=
 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://gith=
ub.com/bitcoin/bips/pull/311" target=3D"_blank">https://github.com/bitcoin/=
bips/pull/311</a></div><div><br></div><div>I urge everyone to seriously con=
sider getting this BIP accepted as a top priority before we get more projec=
ts all trying their hand at stuff and not understanding these critical dist=
inctions.</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></di=
v><div><br></div><div>- Eric</div></font></span></div><br>_________________=
______________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a113a777e50547a052a73e23c--