Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-19 📝 Original message:On Saturday, September 05, ...

📅 Original date posted:2016-01-19
📝 Original message: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