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 0021CF5A for ; Fri, 4 Sep 2015 20:31:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149058.authsmtp.co.uk (outmail149058.authsmtp.co.uk [62.13.149.58]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 37108FC for ; Fri, 4 Sep 2015 20:31:52 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t84KVoTu023562; Fri, 4 Sep 2015 21:31:50 +0100 (BST) Received: from muck (cpe-24-164-134-182.nyc.res.rr.com [24.164.134.182]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t84KVjJe032135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Sep 2015 21:31:47 +0100 (BST) Date: Fri, 4 Sep 2015 16:31:44 -0400 From: Peter Todd To: Andy Chase Message-ID: <20150904203144.GB463@muck> References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: X-Server-Quench: f74f2832-5343-11e5-9f76-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgYUC1AEAgsB AmMbWVVeU1x7XWs7 aQ5PbANZfEtNWxtr WEpWR1pVCwQmRRQF fXhEKExydAdHe3s+ ZERjXngVCkN+I0R1 QUxJEG4CZnphaTUa TUkOcAVJcANIexZF O1F8UScOLwdSbGoL FQ4vNDcwO3BTJTpg CjInDGpVbVwCECIJ DzojJX0GFkYIXzk6 KRcrYmYGG00cKV5a X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.164.134.182/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance 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, 04 Sep 2015 20:31:53 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 04, 2015 at 01:13:18PM -0700, Andy Chase via bitcoin-dev wrote: > Thanks for your thoughts. >=20 > My proposal isn't perfect for sure. There's likely much better ways to do > it. But to be clear what I'm trying to solve is basically this: >=20 > Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or > users? Let's set up a system where everyone has a say and clear acceptance > can be reached. It depends on a case-by-case basis. E.g. for soft-forks miners can do what they want with little ability for other parties to have a say. For non-consensus-related standards - e.g. address formats - it's quite possible for a BIP to be "accepted" even if only a small group of users use the standard. For hard-forks almost everyone is involved, though who can stop a fork isn't as well defined. IMO trying to "set up a system" in that kind of environment is silly, and likely to be a bureaucratic waste of time. Let the market decide, as has happened previously. If you're idea isn't getting acceptance, do a better job of convincing the people who need to adopt it that it is a good idea. No amount of words on paper will change the fact that we can't force people to run software they don't want to run. The entire formal part of the BIP process is simply a convenience so we have clear, short, numbers that we can refer to when discussing ideas and standards. The rest of the process - e.g. what Adam Back and others have been referring to when attempting to dissuade Hearn and Andresen - is by definition always going to be a fuzzy, situation-specific, and generally undefined process. Or put another way, even if you did create your proposed process, the first time those committees "approved" a BIP that relevant stakeholders disagreed with, you'd find out pretty quickly that "clear acceptance" of your 4% sample would fall apart the moment the other 96% realized what a tiny minority was intending to do. Particularly if it was one of the inhernet cases where the underlying math means a particular group - like miners - has the ability to override what another group wants out of Bitcoin. --=20 'peter'[:-1]@petertodd.org 000000000000000010f9e95aff6454fedb9d0a4b92a4108e9449c507936f9f18 --neYutvxvOLaeuPCA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV6f+uXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxMGY5ZTk1YWZmNjQ1NGZlZGI5ZDBhNGI5MmE0MTA4ZTk0 NDljNTA3OTM2ZjlmMTgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyJ2wf/QorpQlfEbJJnfOIW9G0lTQR4 xJKjhTIV3eQqKvHAGd+pQZcxJ4/4FS9SNGdUsgDq5JKSHi4kaymCGtjedOOo1XFb CekLHvR08jMEDvNzlH9gZuSN0nxIAEftyRhSMgbXCVoaTvkE7Sm5wyhF2jZBOfbX aqK82ojK8SAsiYtRLKAD5et0TaNgtT6X7ILw/v7pT7EW+a4OhbPyDbnQb/HgImcV FcOwxr8+HLsFrH375qbfxQaQpcJyXBBOiHUaM2RUh/AVE5/sBrXnyRKQd6zETvuV YNNcT/h2vrOSMyL9/XDOofG2mEGX4BQk7muEybqRRWwiEL3VxSPINGPTUdXk0g== =OCZk -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA--