diff options
| author | Andy Chase <theandychase@gmail.com> | 2015-09-03 17:30:50 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-04 00:30:54 +0000 |
| commit | da150401132b41a63967e5bd5f6b5e51dcdd3f78 (patch) | |
| tree | 224e07f1e7c4153385645997a1715319346c94b4 | |
| parent | 5df9a57ea9c5b7cf19d3bb38c7336750ae5fe2cd (diff) | |
| download | pi-bitcoindev-da150401132b41a63967e5bd5f6b5e51dcdd3f78.tar.gz pi-bitcoindev-da150401132b41a63967e5bd5f6b5e51dcdd3f78.zip | |
[bitcoin-dev] [BIP/Draft] BIP Acceptance Process
| -rw-r--r-- | bd/f3466e55c9b4573359a8653f56b28296e42735 | 539 |
1 files changed, 539 insertions, 0 deletions
diff --git a/bd/f3466e55c9b4573359a8653f56b28296e42735 b/bd/f3466e55c9b4573359a8653f56b28296e42735 new file mode 100644 index 000000000..264e8baa1 --- /dev/null +++ b/bd/f3466e55c9b4573359a8653f56b28296e42735 @@ -0,0 +1,539 @@ +Return-Path: <theandychase@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id A54E01073 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 4 Sep 2015 00:30:54 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com + [209.85.220.53]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 36C68EB + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 4 Sep 2015 00:30:53 +0000 (UTC) +Received: by pacwi10 with SMTP id wi10so5920911pac.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 03 Sep 2015 17:30:53 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=sender:from:content-type:subject:message-id:date:to:mime-version; + bh=3OFrhqsDiMf/XDt5RSJRmMPtlTrfz2Spkmhx2kcFfmk=; + b=kDPDDpb/Ajw3pdyV+j2gaY8rnNUPgOL3ORKH+jgZM2ol9KSUh+Fhy6LMFPvx7HBzHS + 5F9SLHVoMinzvmK49AF+cuACwnU/1x6SK9FXfNMs4bVcnnNjgpcrLgr9ByXguFRaIJAX + dOUZvxooa8yJwXypaelxOGOm336I7I4PgSq8t6d/j27yZse3WLgGESNpmHi+F/qzEp+X + 3Qu7emvlu8jFiKJ26Is5FltiPs02zFC2AwNJTRfrzsBMnWU3q/C8Wrsa6dyZA6VWcCqZ + UjgO5BHxNBvAPxace3o+fF2PjA/TbzP1YHRja+ZmKAFjqqLOUbKRJm8UYDlXGGiQ9uPP + U9gw== +X-Received: by 10.68.223.4 with SMTP id qq4mr1697307pbc.36.1441326652953; + Thu, 03 Sep 2015 17:30:52 -0700 (PDT) +Received: from [192.168.1.5] (static-50-53-75-109.bvtn.or.frontiernet.net. + [50.53.75.109]) + by smtp.gmail.com with ESMTPSA id qe3sm319912pbc.73.2015.09.03.17.30.52 + (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); + Thu, 03 Sep 2015 17:30:52 -0700 (PDT) +Sender: Andy Chase <asperous2@gmail.com> +From: Andy Chase <theandychase@gmail.com> +Content-Type: multipart/alternative; + boundary="Apple-Mail=_07A87ABA-33A1-4E02-AA82-9CF619092650" +Message-Id: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com> +Date: Thu, 3 Sep 2015 17:30:50 -0700 +To: "gmaxwell@gmail.com" <gmaxwell@gmail.com>, + bitcoin-dev@lists.linuxfoundation.org +Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) +X-Mailer: Apple Mail (2.2104) +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + MIME_QP_LONG_LINE, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 04 Sep 2015 00:30:54 -0000 + + +--Apple-Mail=_07A87ABA-33A1-4E02-AA82-9CF619092650 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=utf-8 + +Here=E2=80=99s a BIP. I wrote the BIP mostly to stir the pot on ideas of = +governance, but I=E2=80=99m moderately serious about it. This is set in = +Markdown for readability, but here=E2=80=99s the BIP-0001 Medawiki = +version: https://gist.github.com/andychase/dddb83c294295879308b = +<https://gist.github.com/andychase/dddb83c294295879308b> + + + Title: BIP Acceptance Process + Author: Andy Chase + Status: Draft + Type: Process + Created: 2015-08-31 + +Abstract +=3D=3D=3D=3D=3D=3D=3D=3D + +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 (two weeks) + - 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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D + +This document is placed into the public domain. + +Motivation +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D + +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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +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 +=3D=3D=3D=3D=3D=3D=3D + +- **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](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = +<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>) + 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, a 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.** + - The acceptance test above is not met, a 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. + - A BIP is marked rejected after two failed submission attempts. A + rejected BIP can still be modified and re-submitted. + +Committees +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +**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 + - 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 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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D + +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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + + +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.= + +--Apple-Mail=_07A87ABA-33A1-4E02-AA82-9CF619092650 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; + charset=utf-8 + +<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = +charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = +-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = +class=3D"">Here=E2=80=99s a BIP. I wrote the BIP mostly to stir the pot = +on ideas of governance, but I=E2=80=99m moderately serious about it. = +This is set in Markdown for readability, but here=E2=80=99s the BIP-0001 = +Medawiki version: <a = +href=3D"https://gist.github.com/andychase/dddb83c294295879308b" = +class=3D"">https://gist.github.com/andychase/dddb83c294295879308b</a><br = +class=3D""><br class=3D""><br class=3D""> Title: BIP = +Acceptance Process<br class=3D""> Author: Andy Chase<br = +class=3D""> Status: Draft<br class=3D""> Type: = +Process<br class=3D""> Created: 2015-08-31<br class=3D""><br = +class=3D"">Abstract<br class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D<br = +class=3D""><br class=3D"">The current process for accepting a BIP is not = +clearly defined. While<br class=3D"">BIP-0001 defines the process for = +writing and submitting a Bitcoin<br class=3D"">improvement proposal to = +the community it does not specify the precise<br class=3D"">method for = +which BIPs are considered accepted or rejected.<br class=3D""><br = +class=3D"">This proposal sets up a method for determining BIP = +acceptance.<br class=3D""><br class=3D"">This BIP has two parts:<br = +class=3D""><br class=3D"">- It sets up a process which a BIP = +goes through for comments<br class=3D""> and acceptance.<br = +class=3D""> - The Process is:<br = +class=3D""> - BIP = +Draft<br class=3D""> - = + Submitted for comments (2 weeks)<br = +class=3D""> - Waiting on = +opinion (two weeks)<br class=3D""> - = + Accepted or Deferred<br class=3D"">- It sets up = +committees for reviewing comments and indicating<br = +class=3D""> acceptance under precise conditions.<br = +class=3D""> - Committees are authorized groups = +that represent client authors,<br = +class=3D""> miners, merchants, and = +users (each as a segment). Each one must<br = +class=3D""> represent at least 1% = +stake in the Bitcoin ecosystem.<br class=3D""><br class=3D"">BIP = +acceptance is defined as at least 70% of the represented percentage<br = +class=3D"">stake in 3 out of the 4 Bitcoin segments.<br class=3D""><br = +class=3D"">Copyright<br class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D<br = +class=3D""><br class=3D"">This document is placed into the public = +domain.<br class=3D""><br class=3D"">Motivation<br = +class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br class=3D""><br = +class=3D"">BIPs represent important improvements to Bitcoin = +infrastructure, and in<br class=3D"">order to foster continued = +innovation, the BIP process must have clearly<br class=3D"">defined = +stages and acceptance acknowledgement.<br class=3D""><br = +class=3D"">Rationale<br class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D<br = +class=3D""><br class=3D"">A committee system is used to organize the = +essential concerns of each<br class=3D"">segment of the Bitcoin = +ecosystem. Although each segment may have many<br class=3D"">different = +viewpoints on each BIP, in order to seek a decisive yes/no on<br = +class=3D"">a BIP, a representational authoritative structure is sought. = +This<br class=3D"">structure should be fluid, allowing people to move = +away from committees<br class=3D"">that do not reflect their views and = +should be re-validated on each BIP<br class=3D"">evaluation.<br = +class=3D""><br class=3D"">Weaknesses<br class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D<br class=3D""><br class=3D"">Each committee submits a declaration = +including their claim to represent<br class=3D"">a certain percentage of = +the Bitcoin ecosystem in some way. Though<br class=3D"">guidelines are = +given, it's up to each committee to prove their stake,<br class=3D"">and = +it's up to the reader of the opinions to decide if a BIP was truly<br = +class=3D"">accepted or rejected.<br class=3D""><br class=3D"">The author = +doesn't believe this is a problem because a BIP cannot be<br = +class=3D"">forced on client authors, miners, merchants, or users. = +Ultimately this<br class=3D"">BIP is a tool for determining whether a = +BIP is overwhelmingly accepted.<br class=3D"">If one committee's = +validity claim becomes the factor that decides<br class=3D"">whether the = +BIP will succeed or fail, this process simply didn't return<br = +class=3D"">a clear answer and the BIP should be considered deferred.<br = +class=3D""><br class=3D"">Process<br class=3D"">=3D=3D=3D=3D=3D=3D=3D<br = +class=3D""><br class=3D"">- **Submit for Comments.** The = +first BIP champion named in the<br class=3D""> proposal can = +call a "submit for comments" at any time by posting to<br = +class=3D""> the [Dev Mailing<br class=3D""> List](<a= + href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= +/a>)<br class=3D""> mailling with the BIP number and a = +statement that the champion<br class=3D""> intends to = +immediately submit the BIP for comments.<br class=3D""> - = + The BIP must have been assigned BIP-number (i.e. been = +approved<br class=3D""> by the BIP = +editor) to be submitted for comments.<br class=3D"">- = + **Comments.**<br class=3D""> - After = +a BIP has been submitted for comments, a two-week waiting<br = +class=3D""> period begins in which = +the community should transition from<br = +class=3D""> making suggestions about = +a proposal to publishing their opinions<br = +class=3D""> or concerns on the = +proposal.<br class=3D"">- **Reported Opinions.**<br = +class=3D""> - After the waiting period has past, = +committees must submit a<br = +class=3D""> summary of the comments = +which they have received from their<br = +class=3D""> represented = +communities.<br class=3D""> - The deadline for = +this opinion is four weeks after the BIP was<br = +class=3D""> submitted for = +comments.<br class=3D""> - Committees cannot = +reverse their decision after the deadline, but<br = +class=3D""> at their request may flag = +their decision as "likely to change if<br = +class=3D""> another submit for = +comments is called". Committees can change<br = +class=3D""> their decision if a = +resubmit is called.<br class=3D""> - Opinions = +must include:<br class=3D""> - = + One of the following statements: "Intend to accept", = +"Intent<br = +class=3D""> to = +implement", "Decline to accept", "Intend to accept, but<br = +class=3D""> dec= +line to implement".<br class=3D""> - = + If rejected, the opinion must cite clear and specific<br = +class=3D""> rea= +sons for rejecting including a checklist for what must<br = +class=3D""> hap= +pen or be change for their committee to accept<br = +class=3D""> the= + proposal.<br class=3D""> - = + If accepted, the committee must list why they accepted = +the<br = +class=3D""> pro= +posal and also include concerns they have or what about<br = +class=3D""> the= + BIP that, if things changed, would cause the committee<br = +class=3D""> to = +likely reverse their decision if another submit for<br = +class=3D""> com= +ments was called.<br class=3D"">- **Accepted.**<br = +class=3D""> - If at least 70% of the represented = +percentage stake in 3 out of<br = +class=3D""> 4 segments accept a = +proposal, a BIP is considered accepted.<br = +class=3D""> - If a = +committee fails to submit an opinion, consider the<br = +class=3D""> opi= +nion "Decline to accept".<br class=3D""> - The = +BIP cannot be substantially changed at this point, but can<br = +class=3D""> be replaced. Minor = +changes or clarifications are allowed but<br = +class=3D""> must be recorded in the = +document.<br class=3D"">- **Deferred.**<br = +class=3D""> - The acceptance test above is not = +met, a BIP is sent back<br = +class=3D""> into suggestions.<br = +class=3D""> - BIP can be modified and = +re-submitted for a comments no sooner<br = +class=3D""> than two months after the = +date of the previous submit for<br = +class=3D""> comments is called.<br = +class=3D""> - A BIP is marked rejected after two = +failed submission attempts. A<br = +class=3D""> rejected BIP can still be = +modified and re-submitted.<br class=3D""><br class=3D"">Committees<br = +class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br class=3D""><br = +class=3D"">**BIP Committees.**<br class=3D""><br class=3D"">- = + BIP Committees are representational structures that = +represent<br class=3D""> critical segments of the Bitcoin = +ecosystem.<br class=3D"">- Each committee must prove and = +maintain a clear claim that they<br class=3D""> represent at = +least 1% of the Bitcoin ecosystem in some form.<br = +class=3D""> - If an organization or community = +does not meet that requirement,<br = +class=3D""> it should conglomerate = +itself with other communities and<br = +class=3D""> organizations so that it = +does.<br class=3D"">- The segments that committees can be = +based around are:<br class=3D""> - Bitcoin = +software<br class=3D""> - = + Merchants/services/payment processors<br = +class=3D""> - Mining operators<br = +class=3D""> - User communities<br class=3D"">- = + A person may be represented by any number of segments, but = +a<br class=3D""> committee cannot re-use the same resource as = +another committee in<br class=3D""> the same segment.<br = +class=3D""><br class=3D"">- **Committee Declarations.** At = +any point, a Committee Declaration<br class=3D""> can be = +posted.<br class=3D"">- This Declaration contain details = +about:<br class=3D""> - The segment the Committee = +is representing<br class=3D""> - Who the = +committee claim to represent and it's compositional<br = +class=3D""> makeup (if made up of = +multiple miner orgs, user orgs, companies,<br = +class=3D""> clients, etc).<br = +class=3D""> - Proof of claim and minimum 1% stake = +via:<br class=3D""> - = + Software: proof of ownership and user base (Min 1% of<br = +class=3D""> Bit= +coin userbase)<br class=3D""> - = + Merchant: proof of economic activity (Min 1% of Bitcoin<br = +class=3D""> eco= +nomic activity)<br class=3D""> - = + Mining: proof of work (Min 1% of Hashpower)<br = +class=3D""> - For a user = +organization, auditable signatures qualifies for<br = +class=3D""> a = +valid committee (Min 1% of Bitcoin userbase)<br class=3D""> - = + Who is running the committee, their names and roles<br = +class=3D""> - How represented members can submit = +comments to the committee<br class=3D""> - A code = +of conduct and code of ethics which the committee<br = +class=3D""> promises to abide by<br = +class=3D"">- A committee declaration is accepted if:<br = +class=3D""> - The declaration includes all of the = +required elements<br class=3D""> - The stake is = +considered valid<br class=3D"">- Committee validation is = +considered when considering the results of<br = +class=3D""> opinions submitted by committee on a BIP. A = +committee must have met<br class=3D""> the required stake = +percentage before a BIP is submitted for<br = +class=3D""> comments, and have maintained that stake until a = +valid opinion<br class=3D""> is submitted.<br = +class=3D""> - Committees can dissolve at any time = +or submit a declaration at<br = +class=3D""> any time<br = +class=3D""> - Declaration must have been = +submitted no later than the third day<br = +class=3D""> following a BIP's request = +for comments to be eligible for<br = +class=3D""> inclusion in a BIP<br = +class=3D""><br class=3D"">BIP Process Management Role<br = +class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D<br class=3D""><br class=3D"">BIPs, Opinions, and = +Committee Declaration must be public at all times.<br class=3D""><br = +class=3D"">A BIP Process Manager should be chosen who is in charge = +of:<br class=3D""><br class=3D"">- Declaring where and how = +BIPs, Opinions, and Committee Declaration<br class=3D""> should= + be posted and updated officially.<br class=3D"">- = + Maintaining the security and authenticity of BIPs, Opinions, = +and<br class=3D""> Committee Declarations<br class=3D"">- = + Publishing advisory documents about what kinds of proof of = +stakes<br class=3D""> are valid and what kinds should be = +rejected.<br class=3D"">- Naming a series of successors for = +the roles of the BIP Process<br class=3D""> Manager and BIP = +Editor (BIP-001) as needed.<br class=3D""><br class=3D"">Conditions for = +activation<br class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D<br class=3D""><br class=3D"">In order for this = +process BIP to become active, it must succeed by its<br class=3D"">own = +rules. At least a 4% sample of the Bitcoin community must be<br = +class=3D"">represented, with at least one committee in each segment = +included. Once<br class=3D"">at least one committee has submitted a = +declaration, a request for<br class=3D"">comments will be called and the = +process should be completed from there.</body></html>= + +--Apple-Mail=_07A87ABA-33A1-4E02-AA82-9CF619092650-- + |