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
|
Return-Path: <luke@dashjr.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id F421CC0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Jan 2024 16:46:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id C17A441FDE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Jan 2024 16:46:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C17A441FDE
Authentication-Results: smtp4.osuosl.org;
dkim=pass (1024-bit key) header.d=dashjr.org header.i=@dashjr.org
header.a=rsa-sha256 header.s=zinan header.b=ADUXWzBX
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3r401dkTRUew
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Jan 2024 16:46:11 +0000 (UTC)
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp4.osuosl.org (Postfix) with ESMTP id 4AB6641F43
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Jan 2024 16:46:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4AB6641F43
Received: from [192.168.86.103] (99-39-46-195.lightspeed.dybhfl.sbcglobal.net
[99.39.46.195]) (Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 17435143730
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Jan 2024 16:46:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1705509969; bh=IfHiVGB/O6Rzv0HDwkkhDxUQ7eVnpf7NKJ9/oT4xBfY=;
h=Date:Subject:To:References:From:In-Reply-To;
b=ADUXWzBXv/2r6ZFdlF8BJqeq9qgSr6zu2kUv8VkqsP0Kw7vvTIe6V7N1+olbXecuE
YRn9X9ltBIzw5zYCvpVsLGxPtjYFxXNN/Lwfw93y7ng3oHl8Alhh78j0W+IWRTY5V/
rLrrCKvc1rQOWLX2dzT9h5GcHxBehGzFj9k8tOR4=
X-Hashcash: 1:23:240117:bitcoin-dev@lists.linuxfoundation.org::4gH7m+Ox/hYYGTpU:1Jwu
Content-Type: multipart/alternative;
boundary="------------RI3ea25P7f0SROxwRJOJsFU0"
Message-ID: <030e09b8-3831-45ff-92ad-9531ae277f80@dashjr.org>
Date: Wed, 17 Jan 2024 11:45:59 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US, en-GB
To: bitcoin-dev@lists.linuxfoundation.org
References: <Zac+rMC/c+qTmSxY@erisian.com.au>
<CACrqygDJRtZN4Oo30=DaFO2KYkn1H+Daxh5cinHKz66Uvn9BVg@mail.gmail.com>
From: Luke Dashjr <luke@dashjr.org>
In-Reply-To: <CACrqygDJRtZN4Oo30=DaFO2KYkn1H+Daxh5cinHKz66Uvn9BVg@mail.gmail.com>
Subject: Re: [bitcoin-dev] BIP process friction
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 17 Jan 2024 16:46:13 -0000
This is a multi-part message in MIME format.
--------------RI3ea25P7f0SROxwRJOJsFU0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Perhaps a BIP 3 is in order, but most of the real issue is simply a
matter of volunteer time.
AJ's attempt to conflate that with his own personal disagreements with
how BIPs have always worked, is unrelated.
Luke
On 1/17/24 01:55, Christopher Allen via bitcoin-dev wrote:
>
>
> On Tue, Jan 16, 2024 at 6:43 PM Anthony Towns via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> If people want to use it for bitcoin-related proposals that don't have
> anything to do with inquisition, that's fine; I'm intending to
> apply the
> policies I think the BIPs repo should be using, so feel free to
> open a PR,
> even if you already know I think your idea is BS on its merits. If
> someone
> wants to write an automatic-merge-bot for me, that'd also be great.
>
> If someone wants to reform the BIPs repo itself so it works better,
> that'd be even better, but I'm not volunteering for that fight.
>
>
> I've no idea how to reform BIPs, but we have a similar problem with
> the Blockchain Commons Research (BCR) vs Proposals (BCP), vs.
> specifications that are emerging in various other standards groups
> (IETF, W3C, and we have desire to submit some of these as BIPs as well).
>
> We do a few things differently, one of which in particular might be
> useful for the future of BIPs: we reset the numbers every year. So the
> first new BCR (research proposal) for 2024 would be 2024-01. Also,
> when there is a major change in an old BCR, we create a new number for
> it in the new year it is update.
>
> We also have a concept called "Status", which is a progression that
> only moves forward if BCRs are actually implemented with a reference
> implementation, and advances further when they have multiple
> implementations (and thus are qualified moved over to BCP repo as it
> is somewhat stable and no longer "research".). A last form is when a
> specification has moved to be controlled by another standards group
> (such as a BIP). If only one organization implements a BCR, it will
> never advance to BCP.
>
> Some form of Status for BIPs inspired by this concept could track if a
> BIP was ever actually implemented by someone, or more ideally,
> implemented by multiple people in multiple organizations, ideally in
> multiple languages.
>
> Here is how we currently do status, and the status of our current
> specifications:
> https://github.com/BlockchainCommons/Research/blob/master/README.md#status
>
> Each BCR has a status which is indicated by a symbol.
>
> Symbol Title Description
> ❌❌ Withdrawn Of historic interest only. Withdrawn either because
> never came into use or proved sufficiently problematic that we do not
> recommend its usage in any way.
> ❌ Superseded Superseded by a newer BCR. We do not suggest
> implementing as an output format, but you may still wish to implement
> as an input format to maintain backward compatibility.
> 📙 Research Contains original research or proposes specifications
> that have not yet been implemented by us. Offered to the community for
> consideration.
> ⭐️ Reference Implementation At least one reference implementation
> has been released, usually as a library, and may include demos or
> other supporting tools. This specification still remains very open to
> change because it has not yet (to our knowledge) been implemented by
> additional parties.
> ⭐️⭐️ Multiple Implementations At least two (known) implementations
> exist, at least one not by the owner of the reference implementation.
> Has demonstrable community support. May still change due to the needs
> of the community, but community feedback will be sought.
> ⭐️⭐️⭐️ Standards Track Typically at least two implementations, and
> is considered stable and ready for standardization. Being proposed as
> a BIP, IETF Internet Draft, or some other standardization draft
> format. Will typically be moved to theBCP repo
> <https://github.com/BlockchainCommons/bcps>. Though changes may still
> be made to the specification, these changes will exclusively be to
> allow for standardization, and will be conducted with community feedback.
> ⭐️⭐️⭐️⭐️ Standardized A specification has been standardized as a an
> IETF RFC, BIP, or approved by some other standards body.
>
> ❌❌ after another status symbol is read, "...but withdrawn" and ❌ is
> read, "...but superseded".
>
> -- Christopher Allen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------RI3ea25P7f0SROxwRJOJsFU0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Perhaps a BIP 3 is in order, but most of the real issue is simply
a matter of volunteer time.</p>
<p>AJ's attempt to conflate that with his own personal disagreements
with how BIPs have always worked, is unrelated.</p>
<p>Luke</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/17/24 01:55, Christopher Allen via
bitcoin-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACrqygDJRtZN4Oo30=DaFO2KYkn1H+Daxh5cinHKz66Uvn9BVg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr"><span><br>
</span></div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr"><span>On Tue, Jan 16, 2024
at 6:43 PM Anthony Towns via bitcoin-dev <<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
moz-do-not-send="true" class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a>>
wrote:</span></div>
<blockquote class="gmail_quote"><span>
If people want to use it for bitcoin-related proposals
that don't have<br>
anything to do with inquisition, that's fine; I'm
intending to apply the<br>
policies I think the BIPs repo should be using, so feel
free to open a PR,<br>
even if you already know I think your idea is BS on its
merits. If someone<br>
wants to write an automatic-merge-bot for me, that'd also
be great.<br>
<br>
If someone wants to reform the BIPs repo itself so it
works better,<br>
that'd be even better, but I'm not volunteering for that
fight.<br>
</span></blockquote>
<div><span><br>
</span></div>
<div><span>I've no idea how to reform BIPs, but we have a
similar problem with the Blockchain Commons Research (BCR)
vs Proposals (BCP), vs. specifications that are emerging
in various other standards groups (IETF, W3C, and we have
desire to submit some of these as BIPs as well). </span></div>
<div><span><br>
</span></div>
<div><span>We do a few things differently, one of which in
particular might be useful for the future of BIPs: we
reset the numbers every year. So the first new BCR
(research proposal) for 2024 would be 2024-01. Also, when
there is a major change in an old BCR, we create a new
number for it in the new year it is update.</span></div>
<div><span><br>
</span></div>
<div><span>We also have a concept called "Status", which is a
progression that only moves forward if BCRs are actually
implemented with a reference implementation, and advances
further when they have multiple implementations (and thus
are qualified moved over to BCP repo as it is somewhat
stable and no longer "research".). A last form is when a
specification has moved to be controlled by another
standards group (such as a BIP). If only one organization
implements a BCR, it will never advance to BCP.</span></div>
<div><span><br>
</span></div>
<div><span>Some form of Status for BIPs inspired by this
concept could track if a BIP was ever actually implemented
by someone, or more ideally, implemented by multiple
people in multiple organizations, ideally in multiple
languages. </span></div>
<div><span><br>
</span></div>
<div><span>Here is how we currently do status, and the status
of our current specifications: </span><span><a
href="https://github.com/BlockchainCommons/Research/blob/master/README.md#status"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/BlockchainCommons/Research/blob/master/README.md#status</a></span></div>
<div><span><br>
</span></div>
<div>
<p dir="auto"><span>Each BCR has a status which is indicated
by a symbol.</span></p>
<table>
<thead><tr>
<th><span>Symbol</span></th>
<th><span>Title</span></th>
<th><span>Description</span></th>
</tr>
</thead><tbody>
<tr>
<td><span>❌❌</span></td>
<td><span>Withdrawn</span></td>
<td><span>Of historic interest only. Withdrawn either
because never came into use or proved sufficiently
problematic that we do not recommend its usage in
any way.</span></td>
</tr>
<tr>
<td><span>❌</span></td>
<td><span>Superseded</span></td>
<td><span>Superseded by a newer BCR. We do not suggest
implementing as an output format, but you may
still wish to implement as an input format to
maintain backward compatibility.</span></td>
</tr>
<tr>
<td><span>📙</span></td>
<td><span>Research</span></td>
<td><span>Contains original research or proposes
specifications that have not yet been implemented
by us. Offered to the community for consideration.</span></td>
</tr>
<tr>
<td><span>⭐️</span></td>
<td><span>Reference Implementation</span></td>
<td><span>At least one reference implementation has
been released, usually as a library, and may
include demos or other supporting tools. This
specification still remains very open to change
because it has not yet (to our knowledge) been
implemented by additional parties.</span></td>
</tr>
<tr>
<td><span>⭐️⭐️</span></td>
<td><span>Multiple Implementations</span></td>
<td><span>At least two (known) implementations exist,
at least one not by the owner of the reference
implementation. Has demonstrable community
support. May still change due to the needs of the
community, but community feedback will be sought.</span></td>
</tr>
<tr>
<td><span>⭐️⭐️⭐️</span></td>
<td><span>Standards Track</span></td>
<td><span>Typically at least two implementations, and
is considered stable and ready for
standardization. Being proposed as a BIP, IETF
Internet Draft, or some other standardization
draft format. Will typically be moved to the<span
class="gmail-Apple-converted-space"> </span><a
href="https://github.com/BlockchainCommons/bcps"
moz-do-not-send="true">BCP repo</a>. Though
changes may still be made to the specification,
these changes will exclusively be to allow for
standardization, and will be conducted with
community feedback.</span></td>
</tr>
<tr>
<td><span>⭐️⭐️⭐️⭐️</span></td>
<td><span>Standardized</span></td>
<td><span>A specification has been standardized as a
an IETF RFC, BIP, or approved by some other
standards body.</span></td>
</tr>
</tbody>
</table>
<p dir="auto"><span>❌❌ after another status symbol is read,
"...but withdrawn" and ❌ is read, "...but superseded".</span></p>
<p dir="auto"><span>-- Christopher Allen</span><span><br>
</span></p>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
</body>
</html>
--------------RI3ea25P7f0SROxwRJOJsFU0--
|