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 B2058F51 for ; Fri, 4 Sep 2015 20:43:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCE8017B for ; Fri, 4 Sep 2015 20:43:10 +0000 (UTC) Received: by pacfv12 with SMTP id fv12so34810911pac.2 for ; Fri, 04 Sep 2015 13:43:10 -0700 (PDT) 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=OnptDXG+QYMNaWAqWdUs+eSYxQdHWNEbCBkwLCUbjk8=; b=vN3ES8d3sPJUMYIXmGmFRlkA0jWMmpnUDnpCuT2bmB8LYZPrgHzohejVegoM3iOnMY xPYsX68m2oat/U1u+M3P9VTskhgXhrHL2yyp16R//k08VqyYSiKLFe7lhHVw6+oiB4Nc grKfi3h5vm6hVbGdOSP8gLht4psFvgQLZqQoE8jt8LlTSCSZvyb63G8OkvOkJiFHj2A/ B//kEwRxvdowjoj0HRHwWuvjmzWLFCTuPUGAUpUrQ38zpcCD4pU9KZeRhJhXw8s3rEOP 9NuN1mxNUQPOe3hcjkwl1yBMWl85nJ/c7Wm2z/R7VmEZqLAV758dwz+EC7urXoFHi3RK IcXQ== X-Received: by 10.68.99.69 with SMTP id eo5mr12252152pbb.167.1441399390539; Fri, 04 Sep 2015 13:43:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.157.231 with HTTP; Fri, 4 Sep 2015 13:42:51 -0700 (PDT) In-Reply-To: <20150904203144.GB463@muck> References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com> <20150904203144.GB463@muck> From: Martin Becze Date: Fri, 4 Sep 2015 20:42:51 +0000 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=047d7b6d7c70a714da051ef1f24d 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 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:43:11 -0000 --047d7b6d7c70a714da051ef1f24d Content-Type: text/plain; charset=UTF-8 >> Let the market decide How about Futarchy? On Fri, Sep 4, 2015 at 8:31 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, Sep 04, 2015 at 01:13:18PM -0700, Andy Chase via bitcoin-dev wrote: > > Thanks for your thoughts. > > > > 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: > > > > 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. > > -- > 'peter'[:-1]@petertodd.org > 000000000000000010f9e95aff6454fedb9d0a4b92a4108e9449c507936f9f18 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --047d7b6d7c70a714da051ef1f24d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>=C2=A0Let the market decide
How about Futarchy?
On Fri, Sep 4, 2015 at 8:31 PM, Peter Todd via= bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On F= ri, Sep 04, 2015 at 01:13:18PM -0700, Andy Chase via bitcoin-dev wrote:
> Thanks for your thoughts.
>
> 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: >
> 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 ac= ceptance
> 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&qu= ot; 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 si= lly,
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, d= o 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 o= f
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 stakeh= olders
disagreed with, you'd find out pretty quickly that "clear acceptan= ce" 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.

--
'peter'[:-1]@petertodd.org
000000000000000010f9e95aff6454fedb9d0a4b92a4108e9449c507936f9f18

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


--047d7b6d7c70a714da051ef1f24d--