summaryrefslogtreecommitdiff
path: root/fd/0636cd747d0c65ce2e48bd971f646efe20fa74
blob: 4cbc8358b7e1dd3343b0a5677fdb8a85a6811490 (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
Return-Path: <asperous2@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CFA7A71
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Jan 2016 04:23:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com
	[209.85.213.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1C42713C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Jan 2016 04:23:51 +0000 (UTC)
Received: by mail-ig0-f171.google.com with SMTP id z14so69114761igp.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Jan 2016 20:23:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=xXRK10Lby7KlOr/8xfv+/N2O13F7RpgGlOSFK1qof8Q=;
	b=lGE27Nv/Yw64mKB2OZFH4iK7dvV2tsSFXOUe8EMTLRLWTOYXFhTX/exwY1SDqixgZA
	FicCQ3pePaRHk+ne/mvDiiwGFptoSNzofugA7iC7JEkpan/zcjojYE97fKTLsGL70wu+
	x3JOPlsPFkF/b1Uicovt3AMZkm+pbv2zm4Wnf70o6VxjPqw//ZuUpb8es6JeQj97xjcP
	eU4EwsjI/z/LoCXycApy6r9UyEeqTrV7FjjHMwUWo8TU8kSZigImvfzGtmu7SAKogoPj
	ixMDvev4N1t5DP6Io9q+doyA5OxHGMTMsk67Lu5XQTf6DyJ6mm11+LGMIEBqkYlriT25
	G5sQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc:content-type;
	bh=xXRK10Lby7KlOr/8xfv+/N2O13F7RpgGlOSFK1qof8Q=;
	b=FVHMybndlBDY/NroaTJJyeDEExON8dJOepqPMdqBQsKwirKwY9VNfJkg0Ib3hr0qn6
	k2izzKBzVyBROgXB8tBHwqdox+e9Rk1+JhOR1Ig3HWmX1NrT/bY8J6OTZ4f/vHOkD1KV
	97UOTuf5XEFF6es1CLhQmBYaf8BcrU9g0OEHQM+Gruf+WaoyYHnArq9j1rOHvmOBWMkU
	YUyLjno2OjMma3rO+FKpXiZf0uO6wst6d3uUfCL27OWm4+vkKy79OusPz7F2sWEtoCcK
	UfHy/IKFEWp04qmTe6clF/J+vxswhr1K/qkEAFOhKgzgvW0PG0gHGf61H3Itn9CWuMT2
	7IsQ==
X-Gm-Message-State: AG10YOQ/3ckFNxnmza+34XBHxUMsmXq2POQrB4X/bwAqQN6fkNhgbBsNU/BuIurBoPpHiHLvs4tbs4o3qLQlPQ==
X-Received: by 10.50.41.68 with SMTP id d4mr14539264igl.31.1453177430515; Mon,
	18 Jan 2016 20:23:50 -0800 (PST)
MIME-Version: 1.0
Sender: asperous2@gmail.com
Received: by 10.50.122.103 with HTTP; Mon, 18 Jan 2016 20:23:31 -0800 (PST)
In-Reply-To: <201601190212.30685.luke@dashjr.org>
References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com>
	<201509042145.34410.luke@dashjr.org>
	<CAAxp-m8JW-WOCem6a4RmBk7HOV3cCc02r5r=BkEDyUBu84u4=A@mail.gmail.com>
	<201601190212.30685.luke@dashjr.org>
From: Andy Chase <theandychase@gmail.com>
Date: Mon, 18 Jan 2016 20:23:31 -0800
X-Google-Sender-Auth: L5jsDGG-qUNEXe2egyjhj7c1ahY
Message-ID: <CAAxp-m_AFAB7BgHpXvorMeUovxK+TmUD9j7Hwv9bVBXysYfmnw@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=089e011768e78aa7fe0529a83caf
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_LOW,URIBL_SBL autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 19 Jan 2016 15:37:01 +0000
Cc: Bitcoin Dev <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 04:23:52 -0000

--089e011768e78aa7fe0529a83caf
Content-Type: text/plain; charset=UTF-8

Thanks for your comments Luke.

> Are you saying your proposal is intentionally not intended to reflect the
reality?

That's right. I want to be able to include more voices and be able to get a
clearer idea of acceptance then the process currently has available.

This process should work alongside the current one; not replace it.

> conditions under which a proposal is *known to be* accepted by the
community

*known to be* Is what I'm working towards; yes; but I think we need
additional tools/processes to determine that then what we currently have
available.

> As mentioned, IMO a committee shouldn't be indicating acceptance, as much
as
it should be *determining* acceptance.

The committee determine acceptance when taking their opinions in aggregate.
The source of their indication might be similar to what we currently have
(esp for Core Devs, etc.)

> That sounds very time consuming

Ok

> And what happens if these committees don't represent the community?

The committee structures are fluid-- that is users are able to re-organize
at any time.

> What about when only part of the community - let's say 10% - decides to
adopt a BIP that doesn't require consensus

This might happen, but is not a flaw in my process. My process makes it
clear they are going against the acceptance of the rest of the community. I
don't intend to "force" anyone to implement or use an accepted BIP. If that
is desired that's outside the scope of this BIP.

> But the Bitcoin user base is completely unknown, and tracking software
user base is a privacy violation.

I made a suggestion for this here:
https://gist.github.com/andychase/dddb83c294295879308b

If there are other ways for honest but anonymous voting mechanisms (that
aren't proof-of-stake since that's proof-of-most-money) I'd be all ears.

> Bitcoin economic activity is also unknown
> This needs a proper specification. How do miners express their positions?

I agree these are flaws in the proposal. I'm not sure that one way of
indicating should be considered valid forever, but may have to change over
time.

> Chosen how, and by whom?

I think the process could be used to determine this.

> but I don't think we can just let the author set any conditions they like
either

I'm not sure what you mean here but would love more information.

On Mon, Jan 18, 2016 at 6:12 PM, Luke Dashjr <luke@dashjr.org> wrote:

> 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
>

--089e011768e78aa7fe0529a83caf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks for your comments Luke.</div><div><br></div>&g=
t; Are you saying your proposal is intentionally not intended to reflect th=
e<div>reality?</div><div><br></div><div>That&#39;s right. I want to be able=
 to include more voices and be able to get a clearer idea of acceptance the=
n the process currently has available.</div><div><br></div><div>This proces=
s should work alongside the current one; not replace it.</div><div><br></di=
v><div>&gt;=C2=A0conditions under which a proposal is *known to be* accepte=
d by the community</div><div><br></div><div>*known to be* Is what I&#39;m w=
orking towards; yes; but I think we need additional tools/processes to dete=
rmine that then what we currently have available.</div><div><br></div><div>=
&gt;=C2=A0<span style=3D"font-size:12.8px">As mentioned, IMO a committee sh=
ouldn&#39;t be indicating acceptance, as much as</span></div><span style=3D=
"font-size:12.8px">it should be *determining* acceptance.</span><div><span =
style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:1=
2.8px">The=C2=A0committee=C2=A0determine acceptance when taking their opini=
ons in aggregate. The source of their=C2=A0indication might be=C2=A0similar=
=C2=A0to what we currently have (esp for Core Devs, etc.)</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-=
size:12.8px">&gt;=C2=A0That sounds very time consuming</span></div><div><sp=
an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz=
e:12.8px">Ok</span></div><div><span style=3D"font-size:12.8px"><br></span><=
/div><div><span style=3D"font-size:12.8px">&gt;=C2=A0And what happens if th=
ese committees don&#39;t=C2=A0</span><span style=3D"font-size:12.8px">repre=
sent the community?</span></div><div><span style=3D"font-size:12.8px"><br><=
/span></div><div><span style=3D"font-size:12.8px">The committee structures =
are fluid-- that is users are able to re-organize at any time.</span></div>=
<div><br></div><div><span style=3D"font-size:12.8px">&gt;=C2=A0What about w=
hen only part of the community - let&#39;s=C2=A0</span><span style=3D"font-=
size:12.8px">say 10% - decides to adopt a BIP that doesn&#39;t require cons=
ensus</span></div><div><span style=3D"font-size:12.8px"><br></span></div><d=
iv><span style=3D"font-size:12.8px">This might happen, but is not a flaw in=
 my process. My process makes it clear they are going against the acceptanc=
e of the rest of the community. I don&#39;t intend to &quot;force&quot; any=
one to implement or use an accepted BIP. If that is desired that&#39;s outs=
ide the scope of this BIP.</span></div><div><span style=3D"font-size:12.8px=
"><br></span></div><div><span style=3D"font-size:12.8px">&gt;=C2=A0But the =
Bitcoin user base is completely unknown, and tracking software user=C2=A0</=
span><span style=3D"font-size:12.8px">base is a privacy violation.</span></=
div><div><span style=3D"font-size:12.8px"><br></span></div><div><span style=
=3D"font-size:12.8px">I made a suggestion for this here:=C2=A0<a href=3D"ht=
tps://gist.github.com/andychase/dddb83c294295879308b">https://gist.github.c=
om/andychase/dddb83c294295879308b</a></span></div><div><span style=3D"font-=
size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">If ther=
e are other ways for honest but=C2=A0anonymous=C2=A0voting mechanisms (that=
 aren&#39;t proof-of-stake since=C2=A0that&#39;s proof-of-most-money) I&#39=
;d be all ears.</span></div><div><br></div><div><span style=3D"font-size:12=
.8px">&gt; Bitcoin economic activity is also unknown</span><br></div><div><=
span style=3D"font-size:12.8px">&gt;=C2=A0</span><span style=3D"font-size:1=
2.8px">This needs a proper specification. How do miners express their posit=
ions?</span></div><div><span style=3D"font-size:12.8px"><br></span></div><d=
iv><span style=3D"font-size:12.8px">I agree these are flaws in the proposal=
. I&#39;m not sure that one way of indicating should be considered valid fo=
rever, but may have to change over time.</span></div><div><span style=3D"fo=
nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">&gt;=
=C2=A0</span><span style=3D"font-size:12.8px">Chosen how, and by whom?</spa=
n><br></div><div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
an style=3D"font-size:12.8px">I think the process could be used to determin=
e this.</span></div><div><br></div><div><span style=3D"font-size:12.8px">&g=
t;=C2=A0but I don&#39;t think we can just let the author set any conditions=
 t</span><span style=3D"font-size:12.8px">hey like either</span></div><div>=
<span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-=
size:12.8px">I&#39;m not sure what you mean here but would love more inform=
ation.</span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Mon, Jan 18, 2016 at 6:12 PM, Luke Dashjr <span dir=3D"ltr">&lt;=
<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, September 05=
, 2015 9:19:51 PM Andy Chase wrote:<br>
&gt; Okay for sure yeah writing another proposal that reflects the current =
state<br>
&gt; of affairs as people see it might provide some interesting perspective=
 on<br>
&gt; this proposal. I would welcome that.<br>
<br>
Are you saying your proposal is intentionally not intended to reflect the<b=
r>
reality? I wasn&#39;t talking about a &quot;current state of affairs&quot; =
for BIPs as much<br>
as that that the acceptance of BIPs is *defined by* the state of affairs.<b=
r>
<br>
Overall, I think something *similar to* this proposal is a good idea, but I=
<br>
disagree with how this proposal currently approaches the problem. Instead,<=
br>
what I would recommend is a specification based on BIP 123 that specifies t=
he<br>
conditions under which a proposal is *known to be* accepted by the communit=
y<br>
(ie, discerning, not deciding), and establishes a way for a committee to<br=
>
review the BIP and *determine* if these conditions have been met. This woul=
d<br>
avoid a &quot;disconnect&quot; between the &quot;official status&quot; and =
reality, making the BIP<br>
process more useful to everyone.<br>
<br>
Reviewing your current proposal:<br>
<br>
&gt; * It sets up &#39;&#39;&#39;committees&#39;&#39;&#39; for reviewing co=
mments and indicating<br>
&gt; acceptance under precise conditions.<br>
<br>
As mentioned, IMO a committee shouldn&#39;t be indicating acceptance, as mu=
ch as<br>
it should be *determining* acceptance.<br>
<br>
&gt; ** Committees are authorized groups that represent client authors, min=
ers,<br>
&gt; merchants, and users (each as a segment). Each one must represent at l=
east<br>
&gt; 1% stake in the Bitcoin ecosystem.<br>
<br>
1% seems like an awful lot to dedicate to BIP status changes.<br>
<br>
&gt; A committee system is used to organize the essential concerns of each<=
br>
&gt; segment of the Bitcoin ecosystem. Although each segment may have many<=
br>
&gt; different viewpoints on each BIP, in order to seek a decisive yes/no o=
n a<br>
&gt; BIP, a representational authoritative structure is sought. This struct=
ure<br>
&gt; should be fluid, allowing people to move away from committees that do =
not<br>
&gt; reflect their views and should be re-validated on each BIP evaluation.=
<br>
<br>
That sounds very time consuming. And what happens if these committees don&#=
39;t<br>
represent the community? What about when only part of the community - let&#=
39;s<br>
say 10% - decides to adopt a BIP that doesn&#39;t require consensus? Logica=
lly<br>
that BIP should still proceed...<br>
<br>
&gt; ** Proof of claim and minimum 1% stake via:<br>
&gt; *** Software: proof of ownership and user base (Min 1% of Bitcoin user=
base)<br>
<br>
But the Bitcoin user base is completely unknown, and tracking software user=
<br>
base is a privacy violation.<br>
<br>
&gt; ** Merchant: proof of economic activity (Min 1% of Bitcoin economic<br=
>
&gt; activity)<br>
<br>
Bitcoin economic activity is also unknown, and it seems likely that merchan=
ts<br>
consider their own activity confidential.<br>
<br>
&gt; Mining: proof of work (Min 1% of Hashpower)<br>
<br>
This needs a proper specification. How do miners express their positions?<b=
r>
<br>
&gt; A BIP Process Manager should be chosen who is in charge of:<br>
<br>
Chosen how, and by whom?<br>
<br>
&gt; =3D=3D Conditions for activation =3D=3D<br>
&gt;<br>
&gt; In order for this process BIP to become active, it must succeed by its=
 own<br>
&gt; rules. At least a 4% sample of the Bitcoin community must be represent=
ed,<br>
&gt; with at least one committee in each segment included. Once at least on=
e<br>
&gt; committee has submitted a declaration, a request for comments will be =
called<br>
&gt; and the process should be completed from there.<br>
<br>
Until this BIP is active, its rules do not apply, so this would be a form o=
f<br>
circular reasoning. I like the idea of putting conditions for activation in=
<br>
the BIP text, but I don&#39;t think we can just let the author set any cond=
itions<br>
they like either...<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>

--089e011768e78aa7fe0529a83caf--