public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Andy Chase <theandychase@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
Date: Fri, 4 Sep 2015 16:31:44 -0400	[thread overview]
Message-ID: <20150904203144.GB463@muck> (raw)
In-Reply-To: <CAAxp-m_EmMbVBqQK9ijoe+n0dAs726TaBX5m1Wgzsv-m1KHdfQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

  reply	other threads:[~2015-09-04 20:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-04  0:30 [bitcoin-dev] [BIP/Draft] BIP Acceptance Process Andy Chase
2015-09-04  0:41 ` Luke Dashjr
2015-09-04  0:52   ` Andy Chase
2015-09-04  0:43 ` Bryan Bishop
2015-09-04  4:40   ` Andy Chase
2015-09-04 19:20     ` Btc Drak
2015-09-04 20:13       ` Andy Chase
2015-09-04 20:31         ` Peter Todd [this message]
2015-09-04 20:42           ` Martin Becze
2015-09-04 21:05           ` Milly Bitcoin
2015-09-04 21:01         ` Luke Dashjr
2015-09-04 21:36           ` Andy Chase
2015-09-04 21:45             ` Luke Dashjr
2015-09-05 21:19               ` Andy Chase
     [not found]                 ` <CAHv+tb5ksyZKp5jLvmzFbD2vBOUrWn6ps80ODECVRqYj8m=PZA@mail.gmail.com>
2015-09-06 20:44                   ` Andy Chase
2016-01-19  2:12                 ` Luke Dashjr
2016-01-19  4:23                   ` Andy Chase
2016-01-19  6:07                   ` Dave Scotese
2015-09-07 19:37         ` Btc Drak
2015-09-10  1:21           ` Andy Chase
2015-09-12 23:50             ` Andy Chase

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150904203144.GB463@muck \
    --to=pete@petertodd.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=theandychase@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox