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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7C153ADF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Jan 2016 02:13:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0275614B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Jan 2016 02:13:56 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id B6E4138A96EE;
Tue, 19 Jan 2016 02:12:31 +0000 (UTC)
X-Hashcash: 1:25:160119:theandychase@gmail.com::xIy5el6G0aSY4z2o:cDkEQ
X-Hashcash: 1:25:160119:gmaxwell@gmail.com::KWrMDh6xRcVj7NJw:lLCG
X-Hashcash: 1:25:160119:bitcoin-dev@lists.linuxfoundation.org::YGarsfrvtTU/m+Ty:fNsmQ
X-Hashcash: 1:25:160119:pete@petertodd.org::RqJj4ZOX7hXIQHhT:imvD
From: Luke Dashjr <luke@dashjr.org>
To: Andy Chase <theandychase@gmail.com>
Date: Tue, 19 Jan 2016 02:12:29 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com>
<201509042145.34410.luke@dashjr.org>
<CAAxp-m8JW-WOCem6a4RmBk7HOV3cCc02r5r=BkEDyUBu84u4=A@mail.gmail.com>
In-Reply-To: <CAAxp-m8JW-WOCem6a4RmBk7HOV3cCc02r5r=BkEDyUBu84u4=A@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201601190212.30685.luke@dashjr.org>
X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_SBL,
RP_MATCHES_RCVD autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org, gmaxwell@gmail.com
Subject: Re: [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: Tue, 19 Jan 2016 02:13:57 -0000
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
|
