Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5DE21CA2 for ; Fri, 29 Jan 2016 00:52:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C0EB4138 for ; Fri, 29 Jan 2016 00:52:56 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id cy9so31716138pac.0 for ; Thu, 28 Jan 2016 16:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version; bh=ODrWL5Wo2DjDOVom04YouW6JHSmeWXZpTBFIzBFrI1s=; b=0M9mpRBHKCoVYrBeRlgarZgWQCJwH/WlqJO8wVMbubfkuhWwQD4s1tRgiRZb1XipgY 8wBbu0ScHz0V5XSTvxvShRFsu1W8eLVdmpUSdakdxjOoco4l+uHt5FJ9/yP8OEjHGjtd EB0D5UYar525uFC72bSkJR8+hNwwkVkFs063URsYYkkpOMJxcmh3SQuuiUnjzMQ/B75v c2twNrMYHhM4xsESh1OZveIWyfYcIhvoQfxN1d4Q5o9HDI8LTw5S7GE6e0MWGt0rVB4m xK9a/kgHTvkoLTRM6G1BJjl9j7wZqH6RslEWAy3cvz2TxdDzFiRvNXMsw41FMzkGaei0 zb9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:to :mime-version; bh=ODrWL5Wo2DjDOVom04YouW6JHSmeWXZpTBFIzBFrI1s=; b=GpsfIu6GYaNdD57aJDk3XMOzE6TfrVoUG0BA4TLzj7/DJErortopLCwlFr2/d6wBd4 tlSliGWntXhWMCGYsdS60XA/w5FoZAavhwQHRzlfKG9pTYqUMHmsy7HNx7f7/Tx0F4vi RGS0TurIuEuRYjqvsfxxVICiMx6BVUu547zS/EhfLnyB2EqJ7RIRrYRvdOhDx5Fk/Trw XmxfhQtVZiRfM3+EGENhMV82stW6kq5PRp2rJuxDWgDEtRMQ2O7vYEntvUSQxd4bzQtV 3yZ+KUKodS+OWX9nj1jgrXyowYfCoYDydiE51E4q7MgxeokbrHrIkzVsIV8t6aa/IyRA gs5g== X-Gm-Message-State: AG10YOQ022G1sr1mp20RI0yqkSsYurj/11rG9AyPpYVi22n5sMHsE+uqLHmdczul+9NCkw== X-Received: by 10.66.101.74 with SMTP id fe10mr9290131pab.66.1454028776470; Thu, 28 Jan 2016 16:52:56 -0800 (PST) Received: from [192.168.1.109] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id xz6sm18975332pab.42.2016.01.28.16.52.54 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jan 2016 16:52:55 -0800 (PST) From: Eric Lombrozo X-Pgp-Agent: GPGMail 2.5.1 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 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 Subject: [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 00:52:57 -0000 --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 = 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 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

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