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
|
Return-Path: <luke@dashjr.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id F359BC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Oct 2023 00:15:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id D5A34706CC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Oct 2023 00:15:20 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D5A34706CC
Authentication-Results: smtp3.osuosl.org;
dkim=pass (1024-bit key) header.d=dashjr.org header.i=@dashjr.org
header.a=rsa-sha256 header.s=zinan header.b=0kPMLY6r
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 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,
NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 2u7Wz8sDvdbL
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Oct 2023 00:15:19 +0000 (UTC)
Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1])
by smtp3.osuosl.org (Postfix) with ESMTP id 13AE4706C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Oct 2023 00:15:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 13AE4706C9
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 56D8C38AFC74;
Wed, 25 Oct 2023 00:15:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1698192915; bh=Jl/Us9O0tQWQ0UBvRFJe3apPr+2fBSO6+diGly/8Z+U=;
h=Date:Subject:To:References:From:In-Reply-To;
b=0kPMLY6rkzseHcBm61uQI1OTfNrnrZGJNuYrVIKfQ0nCeC70oGPTaLEDhWzXGX1x/
YNb6Z7R3vkivVS0m2S0FMTrgKxdlgu3FaN0Mb5AwdvZ5b0sXbrOP1m8YedxnLgRfbi
76yC4e1AbA3HkYhDdthSQ20nsieOtt8u8lTu3AEo=
X-Hashcash: 1:23:231025:laolu32@gmail.com::73apE3o1pX81+bAx:elCU
X-Hashcash: 1:23:231025:bitcoin-dev@lists.linuxfoundation.org::AfRFl4Mqka52hGUU:dLjv
Content-Type: multipart/alternative;
boundary="------------T00Yln10XGuXA609q8UvgJ80"
Message-ID: <f6c909b3-6851-f26d-3b30-a65232c1cc61@dashjr.org>
Date: Tue, 24 Oct 2023 20:15:04 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
Content-Language: en-US, en-GB
To: Olaoluwa Osuntokun <laolu32@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CANLPe+OQBsPiTrLEfz=SMxU8TkM_1XNfJQeq8gt2V6vDu=+Zxw@mail.gmail.com>
<ZTaSwtvctmIiF74k@petertodd.org> <ZTawwRqGN4XUUu8C@camus>
<5b641ddc-a30b-4dd7-2481-6d9cdb459359@dashjr.org>
<CAO3Pvs_uUtCfhayU=3LCtpNGtkcDr=H0AM65bhNJcTMuBzWn_w@mail.gmail.com>
From: Luke Dashjr <luke@dashjr.org>
In-Reply-To: <CAO3Pvs_uUtCfhayU=3LCtpNGtkcDr=H0AM65bhNJcTMuBzWn_w@mail.gmail.com>
Subject: Re: [bitcoin-dev] Ordinals BIP PR
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, 25 Oct 2023 00:15:21 -0000
This is a multi-part message in MIME format.
--------------T00Yln10XGuXA609q8UvgJ80
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Seems like a "solution" looking for a problem which doesn't actually
exist. And not even a good "solution" for that - might as well not have
BIP number at all, if they're not going to be usefully assigned. What we
have now is working fine aside from a few trolls once in a while.
On 10/24/23 18:56, Olaoluwa Osuntokun wrote:
> TL;DR: let's just use an automated system to assign BIP numbers, so we can
> spend time on more impactful things.
>
> IIUC, one the primary roles of the dedicated BIP maintainers is just
> to hand
> out BIP numbers for documents. Supposedly with this privilege, the BIP
> maintainer is able to tastefully assign related BIPs to consecutive
> numbers,
> and also reserve certain BIP number ranges for broad categories, like 3xx
> for p2p changes (just an example).
>
> To my knowledge, the methodology for such BIP number selection isn't
> published anywhere, and is mostly arbitrary. As motioned in this thread,
> some perceive this manual process as a gatekeeping mechanism, and often
> ascribe favoritism as the reason why PR X got a number immediately,
> but PR Y
> has waited N months w/o an answer.
>
> Every few years we go through an episode where someone is rightfully upset
> that they haven't been assigned a BIP number after following the requisite
> process. Most recently, another BIP maintainer was appointed, with
> the hope
> that the second maintainer would help to alleviate some of the subjective
> load of the position. Fast forward to this email thread, and it doesn't
> seem like adding more BIP maintainers will actually help with the issue of
> BIP number assignment.
>
> Instead, what if we just removed the subjective human element from the
> process, and switched to using PR numbers to assign BIPs? Now instead of
> attempting to track down a BIP maintainer at the end of a potentially
> involved review+iteration period, PRs are assigned BIP numbers as soon as
> they're opened and we have one less thing to bikeshed and gatekeep.
>
> One down side of this is that assuming the policy is adopted, we'll sorta
> sky rocket the BIP number space. At the time of writing of this email, the
> next PR number looks to be 1508. That doesn't seem like a big deal to me,
> but we could offset that by some value, starting at the highest currently
> manually assigned BIP number. BIP numbers would no longer always be
> contiguous, but that's sort of already the case.
>
> There's also the matter of related BIPs, like the segwit series (BIPs 141,
> 142, 143, 144, and 145). For these, we can use a suffix scheme to indicate
> the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened
> later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't
> think it would be too difficult to find a workable scheme.
>
> Thoughts?
>
> -- Laolu
>
>
> On Mon, Oct 23, 2023 at 11:35 AM Luke Dashjr via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Everything standardized between Bitcoin software is eligible to be
> and
> should be a BIP. I completely disagree with the claim that it's
> used for
> too many things.
>
> SLIPs exist for altcoin stuff. They shouldn't be used for things
> related
> to Bitcoin.
>
> BOLTs also shouldn't have ever been a separate process and should
> really
> just get merged into BIPs. But at this point, that will probably take
> quite a bit of effort, and obviously cooperation and active
> involvement
> from the Lightning development community.
>
> Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had
> time
> to keep up. There are several PRs far more important than Ordinals
> nonsense that need to be triaged and probably merged.
>
> The issue with Ordinals is that it is actually unclear if it's
> eligible
> to be a BIP at all, since it is an attack on Bitcoin rather than a
> proposed improvement. There is a debate on the PR whether the
> "technically unsound, ..., or not in keeping with the Bitcoin
> philosophy." or "must represent a net improvement." clauses (BIP
> 2) are
> relevant. Those issues need to be resolved somehow before it could be
> merged. I have already commented to this effect and given my own
> opinions on the PR, and simply pretending the issues don't exist
> won't
> make them go away. (Nor is it worth the time of honest people to help
> Casey resolve this just so he can further try to harm/destroy
> Bitcoin.)
>
> Luke
>
>
> On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote:
> > On Mon, Oct 23, 2023 at 03:35:30PM +0000, Peter Todd via
> bitcoin-dev wrote:
> >> I have _not_ requested a BIP for OpenTimestamps, even though it
> is of much
> >> wider relevance to Bitcoin users than Ordinals by virtue of the
> fact that much
> >> of the commonly used software, including Bitcoin Core, is
> timestamped with OTS.
> >> I have not, because there is no need to document every single
> little protocol
> >> that happens to use Bitcoin with a BIP.
> >>
> >> Frankly we've been using BIPs for too many things. There is no
> avoiding the act
> >> that BIP assignment and acceptance is a mark of approval for a
> protocol. Thus
> >> we should limit BIP assignment to the minimum possible:
> _extremely_ widespread
> >> standards used by the _entire_ Bitcoin community, for the core
> mission of
> >> Bitcoin.
> >>
> > This would eliminate most wallet-related protocols e.g. BIP69
> (sorted
> > keys), ypubs, zpubs, etc. I don't particularly like any of those
> but if
> > they can't be BIPs then they'd need to find another spec repository
> > where they wouldn't be lost and where updates could be tracked.
> >
> > The SLIP repo could serve this purpose, and I think e.g. SLIP39
> is not a BIP
> > in part because of perceived friction and exclusivity of the
> BIPs repo.
> > But I'm not thrilled with this situation.
> >
> > In fact, I would prefer that OpenTimestamps were a BIP :).
> >
> >> It's notable that Lightning is _not_ standardized via the BIP
> process. I think
> >> that's a good thing. While it's arguably of wide enough use to
> warrent BIPs,
> >> Lightning doesn't need the approval of Core maintainers, and
> using their
> >> separate BOLT process makes that clear.
> >>
> > Well, LN is a bit special because it's so big that it can have
> its own
> > spec repo which is actively maintained and used.
> >
> > While it's technically true that BIPs need "approval of Core
> maintainers"
> > to be merged, the text of BIP2 suggests that this approval
> should be a
> > functionary role and be pretty-much automatic. And not require
> the BIP
> > be relevant or interesting or desireable to Core developers.
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--------------T00Yln10XGuXA609q8UvgJ80
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Seems like a "solution" looking for a problem which doesn't
actually exist. And not even a good "solution" for that - might as
well not have BIP number at all, if they're not going to be
usefully assigned. What we have now is working fine aside from a
few trolls once in a while.<br>
</p>
<div class="moz-cite-prefix">On 10/24/23 18:56, Olaoluwa Osuntokun
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAO3Pvs_uUtCfhayU=3LCtpNGtkcDr=H0AM65bhNJcTMuBzWn_w@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">TL;DR: let's just use an automated system to
assign BIP numbers, so we can<br>
spend time on more impactful things.<br>
<br>
IIUC, one the primary roles of the dedicated BIP maintainers
is just to hand<br>
out BIP numbers for documents. Supposedly with this privilege,
the BIP<br>
maintainer is able to tastefully assign related BIPs to
consecutive numbers,<br>
and also reserve certain BIP number ranges for broad
categories, like 3xx<br>
for p2p changes (just an example).<br>
<br>
To my knowledge, the methodology for such BIP number selection
isn't<br>
published anywhere, and is mostly arbitrary. As motioned in
this thread,<br>
some perceive this manual process as a gatekeeping mechanism,
and often<br>
ascribe favoritism as the reason why PR X got a number
immediately, but PR Y<br>
has waited N months w/o an answer.<br>
<br>
Every few years we go through an episode where someone is
rightfully upset<br>
that they haven't been assigned a BIP number after following
the requisite<br>
process. Most recently, another BIP maintainer was appointed,
with the hope<br>
that the second maintainer would help to alleviate some of the
subjective<br>
load of the position. Fast forward to this email thread, and
it doesn't<br>
seem like adding more BIP maintainers will actually help with
the issue of<br>
BIP number assignment.<br>
<br>
Instead, what if we just removed the subjective human element
from the<br>
process, and switched to using PR numbers to assign BIPs? Now
instead of<br>
attempting to track down a BIP maintainer at the end of a
potentially<br>
involved review+iteration period, PRs are assigned BIP numbers
as soon as<br>
they're opened and we have one less thing to bikeshed and
gatekeep.<br>
<br>
One down side of this is that assuming the policy is adopted,
we'll sorta<br>
sky rocket the BIP number space. At the time of writing of
this email, the<br>
next PR number looks to be 1508. That doesn't seem like a big
deal to me,<br>
but we could offset that by some value, starting at the
highest currently<br>
manually assigned BIP number. BIP numbers would no longer
always be<br>
contiguous, but that's sort of already the case.<br>
<br>
There's also the matter of related BIPs, like the segwit
series (BIPs 141,<br>
142, 143, 144, and 145). For these, we can use a suffix scheme
to indicate<br>
the BIP lineage. So if BIP 141 was the first PR, then BIP 142
was opened<br>
later, the OP can declare the BIP 142 is BIP 141.2 or BIP
141-2. I don't<br>
think it would be too difficult to find a workable scheme.<br>
<br>
Thoughts?<br>
<br>
-- Laolu<br>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Oct 23, 2023 at
11:35 AM Luke Dashjr 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:<br>
</div>
<blockquote class="gmail_quote">Everything standardized
between Bitcoin software is eligible to be and <br>
should be a BIP. I completely disagree with the claim that
it's used for <br>
too many things.<br>
<br>
SLIPs exist for altcoin stuff. They shouldn't be used for
things related <br>
to Bitcoin.<br>
<br>
BOLTs also shouldn't have ever been a separate process and
should really <br>
just get merged into BIPs. But at this point, that will
probably take <br>
quite a bit of effort, and obviously cooperation and active
involvement <br>
from the Lightning development community.<br>
<br>
Maybe we need a 3rd BIP editor. Both Kalle and myself
haven't had time <br>
to keep up. There are several PRs far more important than
Ordinals <br>
nonsense that need to be triaged and probably merged.<br>
<br>
The issue with Ordinals is that it is actually unclear if
it's eligible <br>
to be a BIP at all, since it is an attack on Bitcoin rather
than a <br>
proposed improvement. There is a debate on the PR whether
the <br>
"technically unsound, ..., or not in keeping with the
Bitcoin <br>
philosophy." or "must represent a net improvement." clauses
(BIP 2) are <br>
relevant. Those issues need to be resolved somehow before it
could be <br>
merged. I have already commented to this effect and given my
own <br>
opinions on the PR, and simply pretending the issues don't
exist won't <br>
make them go away. (Nor is it worth the time of honest
people to help <br>
Casey resolve this just so he can further try to
harm/destroy Bitcoin.)<br>
<br>
Luke<br>
<br>
<br>
On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote:<br>
> On Mon, Oct 23, 2023 at 03:35:30PM +0000, Peter Todd
via bitcoin-dev wrote:<br>
>> I have _not_ requested a BIP for OpenTimestamps,
even though it is of much<br>
>> wider relevance to Bitcoin users than Ordinals by
virtue of the fact that much<br>
>> of the commonly used software, including Bitcoin
Core, is timestamped with OTS.<br>
>> I have not, because there is no need to document
every single little protocol<br>
>> that happens to use Bitcoin with a BIP.<br>
>><br>
>> Frankly we've been using BIPs for too many things.
There is no avoiding the act<br>
>> that BIP assignment and acceptance is a mark of
approval for a protocol. Thus<br>
>> we should limit BIP assignment to the minimum
possible: _extremely_ widespread<br>
>> standards used by the _entire_ Bitcoin community,
for the core mission of<br>
>> Bitcoin.<br>
>><br>
> This would eliminate most wallet-related protocols e.g.
BIP69 (sorted<br>
> keys), ypubs, zpubs, etc. I don't particularly like any
of those but if<br>
> they can't be BIPs then they'd need to find another
spec repository<br>
> where they wouldn't be lost and where updates could be
tracked.<br>
><br>
> The SLIP repo could serve this purpose, and I think
e.g. SLIP39 is not a BIP<br>
> in part because of perceived friction and exclusivity
of the BIPs repo.<br>
> But I'm not thrilled with this situation.<br>
><br>
> In fact, I would prefer that OpenTimestamps were a BIP
:).<br>
><br>
>> It's notable that Lightning is _not_ standardized
via the BIP process. I think<br>
>> that's a good thing. While it's arguably of wide
enough use to warrent BIPs,<br>
>> Lightning doesn't need the approval of Core
maintainers, and using their<br>
>> separate BOLT process makes that clear.<br>
>><br>
> Well, LN is a bit special because it's so big that it
can have its own<br>
> spec repo which is actively maintained and used.<br>
><br>
> While it's technically true that BIPs need "approval of
Core maintainers"<br>
> to be merged, the text of BIP2 suggests that this
approval should be a<br>
> functionary role and be pretty-much automatic. And not
require the BIP<br>
> be relevant or interesting or desireable to Core
developers.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>
--------------T00Yln10XGuXA609q8UvgJ80--
|