From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 694291034 for ; Fri, 29 Jan 2016 07:21:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB62E101 for ; Fri, 29 Jan 2016 07:21:30 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id o11so59032651qge.2 for ; Thu, 28 Jan 2016 23:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=msakhUkyVYwIaX8sOPxjZiO0feN6uwMAw6U8rdQ2y4g=; b=pgJBOU3A6Xh5YmOLr7w4n+Ky8kCZPFJqN0AolX4J/7CzSKy57NRGIDP+yawXT7wPXn j0s2fB/VzwZ91FIbpfI0Q78eiIYyZzTsXsWVxYdw+Iw2kAlxN/gVcdmoRpr+TIwlz8xx pziIr+PUiaN9vGpgb51zMJdVf7Z3egEqNcO1Qf1TiFStpC+EqC7GZXIz4rCQs1nF5dXq iUiBBoGa3oeZXSWYAL1al39UQQXwNNsL7h6n0kfck+H2jXruHsI1NwDLvV5RRuUHi3JT qw8Sgai2/aMhu5QBclYM/XCuPo0jm8iD8ti/WjT1UBw11d512B9WXw1crZbECn8wPYUF rQZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=msakhUkyVYwIaX8sOPxjZiO0feN6uwMAw6U8rdQ2y4g=; b=cTcIJMYdjBzRYAemRuS0KS3ErrBOifgpP5MxAMdix/kgK04LHyqH+Va20wcueVAIZe kf/p5jTKrflQWUCpPYny+BG9FwCJHWgMTW1M4qMfXra/niMnzhQ+wgGe5vEUWN7GCcP+ BUycgGqW8PlU+z7Xj5rL6JjU2zwnVotZVIf3YlMuqIRWDvHILRf1O6ofHovXVVYLrw/4 3N1p7mvR1kK12zEYbD+AmQ8SZzAlrHC4XcyM62HKxmJ/BxfNYd7+m+jbHi0iJydBLcQd nJkmR8gxMRR91wkVDkwvAgJHPZEygM1+KWGzBlJBG8FL5KthINRd/txC6iRZnytbYjvC r64g== X-Gm-Message-State: AG10YOTjrq8PgB1Szq3RHVrf1cDQruOf+KSgW5qidQmuUInUG3NhZ8oZASNcRBoq8L0EbgwfXCG7MSY46X8h8w== X-Received: by 10.140.30.229 with SMTP id d92mr8682319qgd.69.1454052090071; Thu, 28 Jan 2016 23:21:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.65.210 with HTTP; Thu, 28 Jan 2016 23:21:10 -0800 (PST) In-Reply-To: <42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com> References: <42F57F58-7C67-43DD-81DE-2C77E03733F2@gmail.com> From: Btc Drak Date: Fri, 29 Jan 2016 07:21:10 +0000 Message-ID: To: Eric Lombrozo Content-Type: multipart/alternative; boundary=001a113a777e50547a052a73e23c X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 29 Jan 2016 07:36:26 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] BIP Classification Process X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 07:21:31 -0000 --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
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.

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


On Fri, Jan 29, 2016 at 12:52 AM, Eri= c Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfou= ndation.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, 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.

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.

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.

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: https://github.com/bitcoin/= bips/pull/311

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.


- Eric

_________________= ______________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a113a777e50547a052a73e23c--