Skip to content

Instantly share code, notes, and snippets.

@andychase
Last active December 7, 2015 10:33
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save andychase/dddb83c294295879308b to your computer and use it in GitHub Desktop.
Save andychase/dddb83c294295879308b to your computer and use it in GitHub Desktop.
[BIP/Draft] Committee-based BIP Acceptance Process [Dev]

  Title: Committee-based BIP Acceptance Process
  Author: Andy Chase 
  Status: Draft 
  Type: Process 
  Created: 2015-08-31

Table of Contents

Abstract

The current process for accepting a BIP is not clearly defined. While BIP-0001 defines the process for writing and submitting a Bitcoin Improvement Proposal to the community it does not specify the precise method for which BIPs are considered accepted or rejected.

This proposal sets up a method for determining BIP acceptance.

This BIP has two parts:

  • It sets up a process which a BIP goes through for comments and acceptance. The Process is:
    • BIP Draft
    • Submitted for comments (2 weeks)
    • Waiting on opinion (2 weeks)
    • BIP becomes either Accepted or Deferred
  • It sets up committees for reviewing comments and indicating acceptance under precise conditions.
    • 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.
BIP acceptance is defined as at least 70% of the represented percentage stake in 3 out of the 4 Bitcoin segments.

Copyright

This document is placed into the public domain.

Motivation

BIPs represent important improvements to Bitcoin infrastructure, and in order to foster continued innovation, the BIP process must have clearly defined stages and acceptance acknowledgement.

Rationale

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.

Weaknesses

Each committee submits a declaration including their claim to represent a certain percentage of the Bitcoin ecosystem in some way. Though guidelines are given, it's up to each committee to prove their stake, and it's up to the reader of the opinions to decide if a BIP was truly accepted or rejected.

The author doesn't believe this is a problem because a BIP cannot be forced on client authors, miners, merchants, or users. Ultimately this BIP is a tool for determining whether a BIP is overwhelmingly accepted. If one committee's validity claim becomes the factor that decides whether the BIP will succeed or fail, this process simply didn't return a clear answer and the BIP should be considered deferred.

Process

  • Submit for Comments. The first BIP champion named in the proposal can call a "submit for comments" at any time by posting to the Dev Mailing List mailling with the BIP number and a statement that the champion intends to immediately submit the BIP for comments.
    • The BIP must have been assigned BIP-number (i.e. been approved by the BIP editor) to be submitted for comments.
  • Comments.
    • After a BIP has been submitted for comments, a two-week waiting period begins in which the community should transition from making suggestions about a proposal to publishing their opinions or concerns on the proposal.
  • Reported Opinions.
    • After the waiting period has past, committees must submit a summary of the comments which they have received from their represented communities.
    • The deadline for this opinion is four weeks after the BIP was submitted for comments.
    • Committees cannot reverse their decision after the deadline, but at their request may flag their decision as "likely to change if another submit for comments is called". Committees can change their decision if a resubmit is called.
    • Opinions must include:
      • One of the following statements: "Intend to accept", "Intent to implement", "Decline to accept", "Intend to accept, but decline to implement".
      • If rejected, the opinion must cite clear and specific reasons for rejecting including a checklist for what must happen or be change for their committee to accept the proposal.
      • If accepted, the committee must list why they accepted the proposal and also include concerns they have or what about the BIP that, if things changed, would cause the committee to likely reverse their decision if another submit for comments was called.
  • Accepted.
    • If at least 70% of the represented percentage stake in 3 out of 4 segments accept a proposal, the BIP is considered accepted.
    • If a committee fails to submit an opinion, consider the opinion "Decline to accept".
    • The BIP cannot be substantially changed at this point, but can be replaced. Minor changes or clarifications are allowed but must be recorded in the document.
  • Deferred.
    • If the acceptance test above is not met, the BIP is sent back into suggestions.
    • BIP can be modified and re-submitted for a comments no sooner than two months after the date of the previous submit for comments is called.
    • The BIP is marked rejected after two failed submission attempts. A rejected BIP can still be modified and re-submitted.

Committees

BIP Committees.

  • BIP Committees are representational structures that represent critical segments of the Bitcoin ecosystem.
  • Each committee must prove and maintain a clear claim that they represent at least 1% of the Bitcoin ecosystem in some form.
  • If an organization or community does not meet that requirement, it should conglomerate itself with other communities and organizations so that it does.
  • The segments that committees can be based around are:
    • Bitcoin software
    • Exchanges/Merchants/services/payment processors
    • Mining operators
    • User communities
  • A person may be represented by any number of segments, but a committee cannot re-use the same resource as another committee in the same segment.
Committee Declarations.
  • At any point, a Committee Declaration can be posted.
  • This Declaration must contain details about:
    • The segment the Committee is representing
    • Who the committee claim to represent and it's compositional makeup (if made up of multiple miner orgs, user orgs, companies, clients, etc).
    • Proof of claim and minimum 1% stake via:
      • Software: proof of ownership and user base (Min 1% of Bitcoin userbase)
      • Merchant: proof of economic activity (Min 1% of Bitcoin economic activity)
      • Mining: proof of work (Min 1% of Hashpower)
      • For a user organization, auditable signatures qualifies for a valid committee (Min 1% of Bitcoin userbase)
    • Who is running the committee, their names and roles
    • How represented members can submit comments to the committee
    • A code of conduct and code of ethics which the committee promises to abide by
  • A committee declaration is accepted if:
    • The declaration includes all of the required elements
    • The stake is considered valid
    • Committee validation is considered when considering the results of opinions submitted by committee on a BIP. A committee must have met the required stake percentage before a BIP is submitted for comments, and have maintained that stake until a valid opinion is submitted.
  • Committees can dissolve at any time or submit a declaration at any time
  • Declaration must have been submitted no later than the third day following a BIP's request for comments to be eligible for inclusion in a BIP

BIP Process Management Role

BIPs, Opinions, and Committee Declaration must be public at all times.

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

  • Declaring where and how BIPs, Opinions, and Committee Declaration should be posted and updated officially.
  • Maintaining the security and authenticity of BIPs, Opinions, and Committee Declarations
  • Publishing advisory documents about what kinds of proof of stakes are valid and what kinds should be rejected.
  • Naming a series of successors for the roles of the BIP Process Manager and BIP Editor (BIP-001) as needed.

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.

@kanzure
Copy link

kanzure commented Sep 4, 2015

Some quick comments:

(1) I have some objects that I am not ready to verbalize, but I think there are easily some major objections to committee design. If I vanish and never respond with my objections, perhaps there's an IETF RFC about this already......

(2) Something that may mitigate my possible objections would be some mandatory requirement about ecosystem echochambers making many attempts and efforts at steelman representations of alternative viewpoints. Understanding objections at a fundamental level, enough to make strong steelman statements, is very important to ensure that the competing opinions are not censored from consideration.

(3) This does not have to replace any particular BIP process as-is, but rather this could be a side-track process that proceeds on its own and eventually replaces another process, or proceeds as-is indefinitely without replacement. I don't think too many BIP processes are necessarily incompatible except by namespace.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010916.html

@andychase
Copy link
Author

@kanzure:

Enforcement/Organization I agree with your comments. I don't believe in setting up an organization to manage this process (would be too much power and not really needed because the internet is pretty good at information sharing). Therefore, I designed it around the assumption that participation is voluntary. This means that it's hard to enforce rules like forcing groups to see the other side. Groupthink and Echo chambers are real/bad but it's hard to change human nature.

In regards to enforcement, I believe that the best approach would be to motivate committees to produce the best opinion they can (and also proof of stake, another weak point in this proposal), as the better they can do this the more likely the community will accept their opinion as valid and important.

Indeed, I believe that without an organization managing the process, it's up to each individual reader of each BIP/Opinions set to make the decision on whether or not there is clear and true community acceptance.

@andychase
Copy link
Author

Aren't Committees bad?

Pros of using Committees:

  • Committees are used today in many fields with varying success. Lots of previous work to work off of here, history is established.
  • Many segments already have committee-like structures (Merchants produce shared signed documents, miners often represent themselves, User groups have representatives like voting on subreddit moderators, Core Devs have Core Devs)
  • Committees can filter a range of opinions down to a yes/no
  • Committees have real people that can be talked to, contacted, etc.
  • Much easier to prove stake in a range (People generally accept the Bitcoin Core has 70-90% of the market share vs someone trying to prove they make up .000001% of the Bitcoin user-base)
  • Committees have some stability, and encourage experience and expertise (Committee members can be knowledgeable in their area and adequately understand BIPs)

Cons:

  • Fear of committees working in the dark, censoring opinions (i.e. "Dark smokey room of fat cats") (Possible solution: make committee power fluid i.e. easily abandon-able: miners can change pools, users can change client forks, change merchants, users can re-group, encourage transparency)
  • More centralized, centralization of power (generally bad) (Possible solution: encourage smaller committees)
  • Centralization pressure (groups may seek to consolidate to gain power) (Possible solution: Segmentation)
  • Encourages groupthink, political maneuvers, turns good people into politicians, mud-tossing

Another possible approach: micro votes

Pros:

  • Each user can represent themselves, no censorship
  • People feel more involved and empowered

Cons:

  • How to prove and prevent manipulation?
  • Only motivated people will contribute. Motivated people may be motivated for bad reasons.

@andychase
Copy link
Author

A method for validating User-based stake

One method is to use a trusted independent third-party like change.org: How do I know if the signatures on my petition are real?

Here's a more decentralized method:

  1. Committee leader starts a petition and publishes a name to use, a date, and some large salt
  2. Users submit a hash of the salt, date published, their name, phone number, address, email address, and the published leader/committee name they wish. They also submit a full email address unhashed to the committee leader.
    1. This could be done through some web interface
    2. Users are told they might be contacted to reveal their info, and are told their email will be shared with committee leader and auditor.
  3. Committee leader submits hashes indexed by number
  4. A third-party auditor generates a list of indexes from some verifiably random source (maybe something to do with the blockchain, like the base10 encoding of the sha256 hash of the block header closest to the petition date + 2016 blocks i.e. two weeks) (This way neither the auditor nor the committee leader get to chose which list of indexes to use)
    1. How many? Enough so duplicates are statistically likely to be detected
  5. Committee leader returns email addresses corresponding to the hashes that match the randomly sampled indexes
  6. Third-party auditor contacts users and has them submit the information they used in their hash
    1. Third-party auditor verifies that the information represents a real and unique person
  7. Third-party auditor returns number of real, duplicate, and "declined to report" users.

Trust could be raised by using two different auditors or something.

@andychase
Copy link
Author

Here's three reasons why I don't think client forks are the best solution for Bitcoin change acceptance: (response to a comment on reddit)

  1. People shouldn't have to be experts to have a valid opinion
    1. See debate: Should people in the US pass a political knowledge test before voting? | Debate.org
    2. Most people aren't Bitcoin experts. It's my opinion that Bitcoin merchants for example shouldn't be forced to have a deep understanding of Bitcoin to understand and broadcast that they'd like their customers to purchase their products with low transaction fees and with low rate of fraud.
  2. Not all people who are indirectly using Bitcoin are represented by a user agent in a Bitcoin client
    1. Many merchants, for example, are shadowed behind a web service
    2. Miners may have opinions about what direction Bitcoin should take but can't risk their income by switching to a risky client implementation
  3. Hard to truly know what clients are real (see my experiments: PSA: It's super easy to manipulate the node count (I know because I did))

@andychase
Copy link
Author

Voting based on proof-of-stake

Several micro vote solutions have been put forth such as Proof of Stake/Bitcoinocracy - Vote with your Bitcoin signature, the one used in Nxt: Voting System - Nxt Wiki, or by distributing special tokens: Re: There Must Be A Way We Can All Vote and voting based on them:

Create a named Counterparty asset, distribute asset for a nominal Satoshi (proof of Bitcoin ownership/usage) then distribute voting tokens.

These all suffer from the same problem: they boil down to voting based on whomever has the most money. Since voting is completely anonymous and public, someone who wishes to force a decision a certain way can buy up the tokens (assuming they were fairly distributed in the first place) or pay people to vote a certain way.

@andychase
Copy link
Author

Another problem voting based on proof-of-stake

Some more minor difficulties of voting based on proof-of-stake:

  1. May have to get your private keys out of cold storage to vote (may be difficult or expensive)
  2. Bitcoin wallet providers make trustworthy voting tricky since addresses aren't tied to people
  3. Because money can be transferred to prevent double-voting people would either:
    1. Not be able to vote using money that someone else has voted with, or
    2. their votes would expire when they spend or transfer money

@andychase
Copy link
Author

Another idea for this proposal is to allow devs, wallet providers, miners, etc to publish opinions with reasons, but ultimately leave it up to the users to vote and decide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment