From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id ACE64C0032 for ; Tue, 24 Oct 2023 22:57:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 762F540AB6 for ; Tue, 24 Oct 2023 22:57:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 762F540AB6 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=UttvYNvX X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v902zNeZruF7 for ; Tue, 24 Oct 2023 22:57:09 +0000 (UTC) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by smtp2.osuosl.org (Postfix) with ESMTPS id 779664056E for ; Tue, 24 Oct 2023 22:57:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 779664056E Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-40839652b97so39190505e9.3 for ; Tue, 24 Oct 2023 15:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698188227; x=1698793027; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=0vwXCywutlxPcGYaafKygyhw+reC7IBgB/d+1lu0C60=; b=UttvYNvXrGe0FXavc4SzVfqh6+NilTf3asBhxTciIttZX2CmH7K+pR+Ma91atvuiLT vPirTBi/bfM77dc/UYhD+TR59nlHqzsTHV+cg0MR6wvNVcvPFiw9ox5COSMVMpaJi9XJ 00fTFDNlmyetIePqwk3VIk2S2RnL7e0egQTwaQWcOW8yHb3g+NphETDvHqmoorqSMLhU JNB0dqK3dEnzXk534cMh8y5GnsU8HvbD0tBLGRzOb0DF3Jdihpr0BNa0w5gQcaQ8lSV5 Ie6JqvIMhnjNLM2h4OdcjC3iUqm5P8kk+nM2an2XuifGqNH/zIDjPOHVpNv9Zw0YuCBY +sgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698188227; x=1698793027; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0vwXCywutlxPcGYaafKygyhw+reC7IBgB/d+1lu0C60=; b=j1k6kSHNv0iqzEH8GlsKls8Yj9ddYlLmHCVRCN408OqBkg4hdKL1sFwohK0Kx02j5G cKFf2se8r/WXOTDH5XdCzrp2IQfNWTW4Dylux54uuKajG+z4b8soukCizmz9BEVV+W3I mrJqqVhMoX6VQUyIN9Gjb/ke5quYs7g7bLGHOT3s4SsGsQ/dciSQuZ18s2K6WR2gOyY2 SiJ6UJmgV9mnGVBiuNtzZ5Gg/bIFpZwxQ/BtYcKOp9nTzWSR3dZNd3aGS75dqVyZOnzY UVXmhalZpMC6g4HgNLQXdcDABblVtT2fAPWLQlK/IkqHoTMU0rBr86z0bXP9PhVrhIjG 4Lpw== X-Gm-Message-State: AOJu0YyBxAf3uv59UFCgvqHZVOpIPx7eNLVO8nBB1kyaYKgZ/O7atS8+ rHzyJzjiwdWQ0vAm63MGOHIVpXpiyln46G+c0N43iDoYp2s= X-Google-Smtp-Source: AGHT+IEq0Z06N7vRjV3Cy/+XiaaEfzQ9Vt7Ws0hM3VtnbbyIcvsb3MrrnNKRFyL/QAHKx8bLEWJu3X9C8Aw/c6qj/C0= X-Received: by 2002:a05:600c:1546:b0:3fe:4cbc:c345 with SMTP id f6-20020a05600c154600b003fe4cbcc345mr10165006wmg.41.1698188226918; Tue, 24 Oct 2023 15:57:06 -0700 (PDT) MIME-Version: 1.0 References: <5b641ddc-a30b-4dd7-2481-6d9cdb459359@dashjr.org> In-Reply-To: <5b641ddc-a30b-4dd7-2481-6d9cdb459359@dashjr.org> From: Olaoluwa Osuntokun Date: Tue, 24 Oct 2023 15:56:55 -0700 Message-ID: To: Luke Dashjr , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000006fbcf06087e4201" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2023 22:57:11 -0000 --00000000000006fbcf06087e4201 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 han= d 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 hop= e 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=E2=80=AFAM 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 avoidin= g > 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 the= ir > >> 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 maintainer= s" > > 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 > --00000000000006fbcf06087e4201 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TL;DR: let's just use an automated sy= stem to assign BIP numbers, so we can
spend time on more impactful thing= s.

IIUC, one the primary roles of the dedicated BIP maintainers is j= ust to hand
out BIP numbers for documents. Supposedly with this privileg= e, the BIP
maintainer is able to tastefully assign related BIPs to conse= cutive numbers,
and also reserve certain BIP number ranges for broad cat= egories, like 3xx
for p2p changes (just an example).

To my knowle= dge, the methodology for such BIP number selection isn't
published a= nywhere, and is mostly arbitrary. As motioned in this thread,
some perce= ive this manual process as a gatekeeping mechanism, and often
ascribe fa= voritism as the reason why PR X got a number immediately, but PR Y
has w= aited N months w/o an answer.

Every few years we go through an episo= de where someone is rightfully upset
that they haven't been assigned= a BIP number after following the requisite
process.=C2=A0 Most recently= , another BIP maintainer was appointed, with the hope
that the second ma= intainer would help to alleviate some of the subjective
load of the posi= tion.=C2=A0 Fast forward to this email thread, and it doesn't
seem l= ike 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 assi= gn 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 p= olicy is adopted, we'll sorta
sky rocket the BIP number space. At th= e time of writing of this email, the
next PR number looks to be 1508. Th= at doesn't seem like a big deal to me,
but we could offset that by s= ome value, starting at the highest currently
manually assigned BIP numbe= r. BIP numbers would no longer always be
contiguous, but that's sort= of already the case.

There's also the matter of related BIPs, l= ike 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 t= he first PR, then BIP 142 was opened
later, the OP can declare the BIP 1= 42 is BIP 141.2 or BIP 141-2. I don't
think it would be too difficul= t to find a workable scheme.

Thoughts?

-- Laolu

=
On Mon= , Oct 23, 2023 at 11:35=E2=80=AFAM Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.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 fo= r
too many things.

SLIPs exist for altcoin stuff. They shouldn't be used for things relate= d
to Bitcoin.

BOLTs also shouldn't have ever been a separate process and should reall= y
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= 9;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 w= rote:
>> 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 fa= ct that much
>> of the commonly used software, including Bitcoin Core, is timestam= ped with OTS.
>> I have not, because there is no need to document every single litt= le 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 pro= tocol. Thus
>> we should limit BIP assignment to the minimum possible: _extremely= _ widespread
>> standards used by the _entire_ Bitcoin community, for the core mis= sion of
>> Bitcoin.
>>
> This would eliminate most wallet-related protocols e.g. BIP69 (sorted<= br> > keys), ypubs, zpubs, etc. I don't particularly like any of those b= ut if
> they can't be BIPs then they'd need to find another spec repos= itory
> 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 us= e to warrent BIPs,
>> Lightning doesn't need the approval of Core maintainers, and u= sing 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/mail= man/listinfo/bitcoin-dev
--00000000000006fbcf06087e4201--