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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
