summaryrefslogtreecommitdiff
path: root/bd/f3466e55c9b4573359a8653f56b28296e42735
blob: 264e8baa1c9a746cbd3b86e93bf8f4c5327ea45a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
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:&nbsp;<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"">&nbsp;&nbsp;Title: BIP =
Acceptance Process<br class=3D"">&nbsp;&nbsp;Author: Andy Chase<br =
class=3D"">&nbsp;&nbsp;Status: Draft<br class=3D"">&nbsp;&nbsp;Type: =
Process<br class=3D"">&nbsp;&nbsp;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"">- &nbsp;&nbsp;It sets up a process which a BIP =
goes through for comments<br class=3D"">&nbsp;&nbsp;and acceptance.<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;The Process is:<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- &nbsp;&nbsp;BIP =
Draft<br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- =
&nbsp;&nbsp;Submitted for comments (2 weeks)<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- &nbsp;&nbsp;Waiting on =
opinion (two weeks)<br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- =
&nbsp;&nbsp;Accepted or Deferred<br class=3D"">- &nbsp;&nbsp;It sets up =
committees for reviewing comments and indicating<br =
class=3D"">&nbsp;&nbsp;acceptance under precise conditions.<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;Committees are authorized groups =
that represent client authors,<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;miners, merchants, and =
users (each as a segment). Each one must<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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"">- &nbsp;&nbsp;**Submit for Comments.** The =
first BIP champion named in the<br class=3D"">&nbsp;&nbsp;proposal can =
call a "submit for comments" at any time by posting to<br =
class=3D"">&nbsp;&nbsp;the [Dev Mailing<br class=3D"">&nbsp;&nbsp;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"">&nbsp;&nbsp;mailling with the BIP number and a =
statement that the champion<br class=3D"">&nbsp;&nbsp;intends to =
immediately submit the BIP for comments.<br class=3D"">&nbsp;&nbsp;- =
&nbsp;&nbsp;The BIP must have been assigned BIP-number (i.e. been =
approved<br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;by the BIP =
editor) to be submitted for comments.<br class=3D"">- =
&nbsp;&nbsp;**Comments.**<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;After =
a BIP has been submitted for comments, a two-week waiting<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;period begins in which =
the community should transition from<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;making suggestions about =
a proposal to publishing their opinions<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or concerns on the =
proposal.<br class=3D"">- &nbsp;&nbsp;**Reported Opinions.**<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;After the waiting period has past, =
committees must submit a<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;summary of the comments =
which they have received from their<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;represented =
communities.<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;The deadline for =
this opinion is four weeks after the BIP was<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;submitted for =
comments.<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;Committees cannot =
reverse their decision after the deadline, but<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at their request may flag =
their decision as "likely to change if<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;another submit for =
comments is called". Committees can change<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;their decision if a =
resubmit is called.<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;Opinions =
must include:<br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- =
&nbsp;&nbsp;One of the following statements: "Intend to accept", =
"Intent<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to =
implement", "Decline to accept", "Intend to accept, but<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dec=
line to implement".<br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- =
&nbsp;&nbsp;If rejected, the opinion must cite clear and specific<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rea=
sons for rejecting including a checklist for what must<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;hap=
pen or be change for their committee to accept<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the=
 proposal.<br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- =
&nbsp;&nbsp;If accepted, the committee must list why they accepted =
the<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pro=
posal and also include concerns they have or what about<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the=
 BIP that, if things changed, would cause the committee<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to =
likely reverse their decision if another submit for<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;com=
ments was called.<br class=3D"">- &nbsp;&nbsp;**Accepted.**<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;If at least 70% of the represented =
percentage stake in 3 out of<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4 segments accept a =
proposal, a BIP is considered accepted.<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- &nbsp;&nbsp;If a =
committee fails to submit an opinion, consider the<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;opi=
nion "Decline to accept".<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;The =
BIP cannot be substantially changed at this point, but can<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;be replaced. Minor =
changes or clarifications are allowed but<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;must be recorded in the =
document.<br class=3D"">- &nbsp;&nbsp;**Deferred.**<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;The acceptance test above is not =
met, a BIP is sent back<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;into suggestions.<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;BIP can be modified and =
re-submitted for a comments no sooner<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;than two months after the =
date of the previous submit for<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;comments is called.<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;A BIP is marked rejected after two =
failed submission attempts. A<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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"">- =
&nbsp;&nbsp;BIP Committees are representational structures that =
represent<br class=3D"">&nbsp;&nbsp;critical segments of the Bitcoin =
ecosystem.<br class=3D"">- &nbsp;&nbsp;Each committee must prove and =
maintain a clear claim that they<br class=3D"">&nbsp;&nbsp;represent at =
least 1% of the Bitcoin ecosystem in some form.<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;If an organization or community =
does not meet that requirement,<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;it should conglomerate =
itself with other communities and<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;organizations so that it =
does.<br class=3D"">- &nbsp;&nbsp;The segments that committees can be =
based around are:<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;Bitcoin =
software<br class=3D"">&nbsp;&nbsp;- =
&nbsp;&nbsp;Merchants/services/payment processors<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;Mining operators<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;User communities<br class=3D"">- =
&nbsp;&nbsp;A person may be represented by any number of segments, but =
a<br class=3D"">&nbsp;&nbsp;committee cannot re-use the same resource as =
another committee in<br class=3D"">&nbsp;&nbsp;the same segment.<br =
class=3D""><br class=3D"">- &nbsp;&nbsp;**Committee Declarations.** At =
any point, a Committee Declaration<br class=3D"">&nbsp;&nbsp;can be =
posted.<br class=3D"">- &nbsp;&nbsp;This Declaration contain details =
about:<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;The segment the Committee =
is representing<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;Who the =
committee claim to represent and it's compositional<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;makeup (if made up of =
multiple miner orgs, user orgs, companies,<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;clients, etc).<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;Proof of claim and minimum 1% stake =
via:<br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- =
&nbsp;&nbsp;Software: proof of ownership and user base (Min 1% of<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bit=
coin userbase)<br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- =
&nbsp;&nbsp;Merchant: proof of economic activity (Min 1% of Bitcoin<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;eco=
nomic activity)<br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- =
&nbsp;&nbsp;Mining: proof of work (Min 1% of Hashpower)<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- &nbsp;&nbsp;For a user =
organization, auditable signatures qualifies for<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a =
valid committee (Min 1% of Bitcoin userbase)<br class=3D"">&nbsp;&nbsp;- =
&nbsp;&nbsp;Who is running the committee, their names and roles<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;How represented members can submit =
comments to the committee<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;A code =
of conduct and code of ethics which the committee<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;promises to abide by<br =
class=3D"">- &nbsp;&nbsp;A committee declaration is accepted if:<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;The declaration includes all of the =
required elements<br class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;The stake is =
considered valid<br class=3D"">- &nbsp;&nbsp;Committee validation is =
considered when considering the results of<br =
class=3D"">&nbsp;&nbsp;opinions submitted by committee on a BIP. A =
committee must have met<br class=3D"">&nbsp;&nbsp;the required stake =
percentage before a BIP is submitted for<br =
class=3D"">&nbsp;&nbsp;comments, and have maintained that stake until a =
valid opinion<br class=3D"">&nbsp;&nbsp;is submitted.<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;Committees can dissolve at any time =
or submit a declaration at<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;any time<br =
class=3D"">&nbsp;&nbsp;- &nbsp;&nbsp;Declaration must have been =
submitted no later than the third day<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;following a BIP's request =
for comments to be eligible for<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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"">- &nbsp;&nbsp;Declaring where and how =
BIPs, Opinions, and Committee Declaration<br class=3D"">&nbsp;&nbsp;should=
 be posted and updated officially.<br class=3D"">- =
&nbsp;&nbsp;Maintaining the security and authenticity of BIPs, Opinions, =
and<br class=3D"">&nbsp;&nbsp;Committee Declarations<br class=3D"">- =
&nbsp;&nbsp;Publishing advisory documents about what kinds of proof of =
stakes<br class=3D"">&nbsp;&nbsp;are valid and what kinds should be =
rejected.<br class=3D"">- &nbsp;&nbsp;Naming a series of successors for =
the roles of the BIP Process<br class=3D"">&nbsp;&nbsp;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--