From: Luke Dashjr <luke@dashjr.org>
To: Andy Chase <theandychase@gmail.com>
Date: Tue, 19 Jan 2016 02:12:29 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com>
	<201509042145.34410.luke@dashjr.org>
	<CAAxp-m8JW-WOCem6a4RmBk7HOV3cCc02r5r=BkEDyUBu84u4=A@mail.gmail.com>
In-Reply-To: <CAAxp-m8JW-WOCem6a4RmBk7HOV3cCc02r5r=BkEDyUBu84u4=A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201601190212.30685.luke@dashjr.org>
Cc: bitcoin-dev@lists.linuxfoundation.org, gmaxwell@gmail.com
Subject: Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
Precedence: list

On Saturday, September 05, 2015 9:19:51 PM Andy Chase wrote:
> Okay for sure yeah writing another proposal that reflects the current state
> of affairs as people see it might provide some interesting perspective on
> this proposal. I would welcome that.

Are you saying your proposal is intentionally not intended to reflect the 
reality? I wasn't talking about a "current state of affairs" for BIPs as much 
as that that the acceptance of BIPs is *defined by* the state of affairs.

Overall, I think something *similar to* this proposal is a good idea, but I 
disagree with how this proposal currently approaches the problem. Instead, 
what I would recommend is a specification based on BIP 123 that specifies the 
conditions under which a proposal is *known to be* accepted by the community 
(ie, discerning, not deciding), and establishes a way for a committee to 
review the BIP and *determine* if these conditions have been met. This would 
avoid a "disconnect" between the "official status" and reality, making the BIP 
process more useful to everyone.

Reviewing your current proposal:

> * It sets up '''committees''' for reviewing comments and indicating
> acceptance under precise conditions.

As mentioned, IMO a committee shouldn't be indicating acceptance, as much as 
it should be *determining* acceptance.

> ** Committees are authorized groups that represent client authors, miners,
> merchants, and users (each as a segment). Each one must represent at least
> 1% stake in the Bitcoin ecosystem.

1% seems like an awful lot to dedicate to BIP status changes.

> A committee system is used to organize the essential concerns of each
> segment of the Bitcoin ecosystem. Although each segment may have many
> different viewpoints on each BIP, in order to seek a decisive yes/no on a
> BIP, a representational authoritative structure is sought. This structure
> should be fluid, allowing people to move away from committees that do not
> reflect their views and should be re-validated on each BIP evaluation.

That sounds very time consuming. And what happens if these committees don't 
represent the community? What about when only part of the community - let's 
say 10% - decides to adopt a BIP that doesn't require consensus? Logically 
that BIP should still proceed...

> ** Proof of claim and minimum 1% stake via:
> *** Software: proof of ownership and user base (Min 1% of Bitcoin userbase)

But the Bitcoin user base is completely unknown, and tracking software user 
base is a privacy violation.

> ** Merchant: proof of economic activity (Min 1% of Bitcoin economic
> activity)

Bitcoin economic activity is also unknown, and it seems likely that merchants 
consider their own activity confidential.

> Mining: proof of work (Min 1% of Hashpower)

This needs a proper specification. How do miners express their positions?

> A BIP Process Manager should be chosen who is in charge of:

Chosen how, and by whom?

> == Conditions for activation ==
>
> In order for this process BIP to become active, it must succeed by its own
> rules. At least a 4% sample of the Bitcoin community must be represented,
> with at least one committee in each segment included. Once at least one
> committee has submitted a declaration, a request for comments will be called
> and the process should be completed from there.

Until this BIP is active, its rules do not apply, so this would be a form of 
circular reasoning. I like the idea of putting conditions for activation in 
the BIP text, but I don't think we can just let the author set any conditions 
they like either...

Luke