path: root/65/6af3595fd6cb58648894b7fe4750060cc79e87

Return-Path: <christophera@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EBFB2C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Oct 2023 23:08:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id BA9054F0BA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Oct 2023 23:08:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org BA9054F0BA
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail-com.20230601.gappssmtp.com
 header.i=@gmail-com.20230601.gappssmtp.com header.a=rsa-sha256
 header.s=20230601 header.b=XFQ363nz
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 Nq8_CqUCk0Ck
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Oct 2023 23:08:52 +0000 (UTC)
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com
 [IPv6:2607:f8b0:4864:20::1130])
 by smtp4.osuosl.org (Postfix) with ESMTPS id B1FED4F08B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Oct 2023 23:08:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B1FED4F08B
Received: by mail-yw1-x1130.google.com with SMTP id
 00721157ae682-5a7fb84f6ceso48807067b3.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Oct 2023 16:08:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail-com.20230601.gappssmtp.com; s=20230601; t=1698188930; x=1698793730;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=BdWb04ytl8N22RLo0WeC93Dp/a6iB0qnWKeCRPCxpI4=;
 b=XFQ363nzNLIb7nkQ+0hUjHMC6HjQYrL76gq+pskWOE2uKKUpfaIR4Pt5SZOIdkX+je
 n1E/QtccmFCXmwCyZLNo/jjDQPRTdCd7ILaApsN5lRrSjqowb0ymWs2OjW5zDuOA6zIb
 4OohpNU5demq+bn1fz8rc+psgZTykOH7qLHh+tV6xmcSXalsiNx7XgWXs1XwDXkFEXxv
 WFOtD4omglNRqk9Dk4vlBYOMHavyerJCoWdkhgL0/GsDVrsJAZhHU+WkAt52FL4M9f5D
 zS4IRjhCnN0I9QkHuEO7AJSoILdd2S+WmW4kHg69VWu7sdM9VbQi4KKlAZe0IxjwlZ9c
 1oeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1698188930; x=1698793730;
 h=cc: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=BdWb04ytl8N22RLo0WeC93Dp/a6iB0qnWKeCRPCxpI4=;
 b=lSkl13n0TDR4M6pqRuc4YExvYoxHj1a4LxVk2ofEkC1aVL5W6/GibXvToNmoXiMIqq
 vwF7/i8YWIHIIMHiJg7K8VsFsHQTQt2VNSZ+NXiU+Fz+zGTWGDt0MhOWx9GA3F1pum02
 LcUsDfXxC4hThJdX54VTzomYCRj6IXM17n9VHTF2lPdBz5eocAJEqBA22XsGINnGlorJ
 0OUa2wRTTt9rracP+VdDU+TLTWJsKM5TM11Fh+us8glnYjsrqCDcmt2quegw6O1OcHpi
 zYHuo5Kn5GomzIDHZ7g0oo5n4CiWBj0vFTUlpYy1+FKN+S6ofgQbtiQmaM1H6WsdB8n3
 WWGA==
X-Gm-Message-State: AOJu0YyQqnbKJbWNA71G8d2/C3OuOsGNzOg0YNBOh5Pl3MDVK4sElKUK
 uTA+aV0Rezc70BgvZ20ZzUa/ci/eurs1BS8GsDZpG04T
X-Google-Smtp-Source: AGHT+IFkZ+e8qGERYM7J10EBoh7vnD5RZTxhlTQU9bG6icwQBCUMjTAjQaXRrby+1I70LSgsIaY1PgCMXKu9yEIKRh0=
X-Received: by 2002:a05:6902:4e8:b0:da0:62d1:bd34 with SMTP id
 w8-20020a05690204e800b00da062d1bd34mr1567220ybs.47.1698188929823; Tue, 24 Oct
 2023 16:08:49 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAO3Pvs_uUtCfhayU=3LCtpNGtkcDr=H0AM65bhNJcTMuBzWn_w@mail.gmail.com>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Tue, 24 Oct 2023 16:08:37 -0700
Message-ID: <CACrqygDMmEunc2_Js12ON3_uH2AN7xopFzC2fF9nUsEGNCkRhg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 Olaoluwa Osuntokun <laolu32@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ec7baf06087e6b5b"
X-Mailman-Approved-At: Wed, 25 Oct 2023 00:41:44 +0000
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: Tue, 24 Oct 2023 23:08:54 -0000

--000000000000ec7baf06087e6b5b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think this is a good idea, but suggest that the numbers include year and
number in the year. We do that for all the research and =E2=80=9Cwallet imp=
rovement
proposals=E2=80=9D at Blockchain Commons. This way numbers don=E2=80=99t gr=
ow huge like
EIPs currently do.

I might also suggest that the numbers are only automatically offered when a
maintainer does not reject it for three days. That way they can focus on
just responding to obvious spam, and if rejected the moderator name is on
it, rather than the current anonymous pocket veto.

=E2=80=94 Christopher Allen [via iPhone]

On Tue, Oct 24, 2023 at 3:57=E2=80=AFPM Olaoluwa Osuntokun via bitcoin-dev =
<
bitcoin-dev@lists.linuxfoundation.org> wrote:

> TL;DR: let's just use an automated system to assign BIP numbers, so we ca=
n
> 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 P=
R
> Y
> has waited N months w/o an answer.
>
> Every few years we go through an episode where someone is rightfully upse=
t
> that they haven't been assigned a BIP number after following the requisit=
e
> 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 o=
f
> 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, th=
e
> 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 indicat=
e
> 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
>> 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 missio=
n
>> 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 i=
f
>> > 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 warren=
t
>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000ec7baf06087e6b5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I think this is a good idea, but suggest that the numbers=
 include year and number in the year. We do that for all the research and =
=E2=80=9Cwallet improvement proposals=E2=80=9D at Blockchain Commons. This =
way numbers don=E2=80=99t grow huge like EIPs currently do.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">I might also suggest that the numbers=
 are only automatically offered when a maintainer does not reject it for th=
ree days. That way they can focus on just responding to obvious spam, and i=
f rejected the moderator name is on it, rather than the current anonymous p=
ocket veto.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=E2=80=94 Ch=
ristopher Allen [via iPhone]=C2=A0</div><div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 24, 2023 at 3:57=E2=80=
=AFPM Olaoluwa Osuntokun via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;borde=
r-left-color:rgb(204,204,204)"><div dir=3D"ltr"><div dir=3D"ltr">TL;DR: let=
&#39;s just use an automated system to assign BIP numbers, so we can<br>spe=
nd 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 tasteful=
ly assign related BIPs to consecutive numbers,<br>and also reserve certain =
BIP number ranges for broad categories, like 3xx<br>for p2p changes (just a=
n example).<br><br>To my knowledge, the methodology for such BIP number sel=
ection isn&#39;t<br>published anywhere, and is mostly arbitrary. As motione=
d in this thread,<br>some perceive this manual process as a gatekeeping mec=
hanism, 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 f=
ew years we go through an episode where someone is rightfully upset<br>that=
 they haven&#39;t been assigned a BIP number after following the requisite<=
br>process.=C2=A0 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.=C2=A0 Fast forward to this email threa=
d, and it doesn&#39;t<br>seem like adding more BIP maintainers will actuall=
y 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 switc=
hed to using PR numbers to assign BIPs? Now instead of<br>attempting to tra=
ck down a BIP maintainer at the end of a potentially<br>involved review+ite=
ration period, PRs are assigned BIP numbers as soon as<br>they&#39;re opene=
d 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&#39;ll sorta<br>sky roc=
ket the BIP number space. At the time of writing of this email, the<br>next=
 PR number looks to be 1508. That doesn&#39;t seem like a big deal to me,<b=
r>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&#39;s sort of already the case.<br><br>There&#39;s als=
o 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 B=
IP lineage. So if BIP 141 was the first PR, then BIP 142 was opened<br>late=
r, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don&#39;t<br=
>think it would be too difficult to find a workable scheme.<br><br>Thoughts=
?<br><br>-- Laolu<br><br></div></div><div dir=3D"ltr"><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 23, 2023 at 11:=
35=E2=80=AFAM Luke Dashjr via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;pad=
ding-left:1ex;border-left-color:rgb(204,204,204)">Everything standardized b=
etween Bitcoin software is eligible to be and <br>
should be a BIP. I completely disagree with the claim that it&#39;s used fo=
r <br>
too many things.<br>
<br>
SLIPs exist for altcoin stuff. They shouldn&#39;t be used for things relate=
d <br>
to Bitcoin.<br>
<br>
BOLTs also shouldn&#39;t have ever been a separate process and should reall=
y <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&#39;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&#39;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>
&quot;technically unsound, ..., or not in keeping with the Bitcoin <br>
philosophy.&quot; or &quot;must represent a net improvement.&quot; 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&#39;t exist won&#3=
9;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>
&gt; On Mon, Oct 23, 2023 at 03:35:30PM +0000, Peter Todd via bitcoin-dev w=
rote:<br>
&gt;&gt; I have _not_ requested a BIP for OpenTimestamps, even though it is=
 of much<br>
&gt;&gt; wider relevance to Bitcoin users than Ordinals by virtue of the fa=
ct that much<br>
&gt;&gt; of the commonly used software, including Bitcoin Core, is timestam=
ped with OTS.<br>
&gt;&gt; I have not, because there is no need to document every single litt=
le protocol<br>
&gt;&gt; that happens to use Bitcoin with a BIP.<br>
&gt;&gt;<br>
&gt;&gt; Frankly we&#39;ve been using BIPs for too many things. There is no=
 avoiding the act<br>
&gt;&gt; that BIP assignment and acceptance is a mark of approval for a pro=
tocol. Thus<br>
&gt;&gt; we should limit BIP assignment to the minimum possible: _extremely=
_ widespread<br>
&gt;&gt; standards used by the _entire_ Bitcoin community, for the core mis=
sion of<br>
&gt;&gt; Bitcoin.<br>
&gt;&gt;<br>
&gt; This would eliminate most wallet-related protocols e.g. BIP69 (sorted<=
br>
&gt; keys), ypubs, zpubs, etc. I don&#39;t particularly like any of those b=
ut if<br>
&gt; they can&#39;t be BIPs then they&#39;d need to find another spec repos=
itory<br>
&gt; where they wouldn&#39;t be lost and where updates could be tracked.<br=
>
&gt;<br>
&gt; The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not=
 a BIP<br>
&gt; in part because of perceived friction and exclusivity of the BIPs repo=
.<br>
&gt; But I&#39;m not thrilled with this situation.<br>
&gt;<br>
&gt; In fact, I would prefer that OpenTimestamps were a BIP :).<br>
&gt;<br>
&gt;&gt; It&#39;s notable that Lightning is _not_ standardized via the BIP =
process. I think<br>
&gt;&gt; that&#39;s a good thing. While it&#39;s arguably of wide enough us=
e to warrent BIPs,<br>
&gt;&gt; Lightning doesn&#39;t need the approval of Core maintainers, and u=
sing their<br>
&gt;&gt; separate BOLT process makes that clear.<br>
&gt;&gt;<br>
&gt; Well, LN is a bit special because it&#39;s so big that it can have its=
 own<br>
&gt; spec repo which is actively maintained and used.<br>
&gt;<br>
&gt; While it&#39;s technically true that BIPs need &quot;approval of Core =
maintainers&quot;<br>
&gt; to be merged, the text of BIP2 suggests that this approval should be a=
<br>
&gt; functionary role and be pretty-much automatic. And not require the BIP=
<br>
&gt; be relevant or interesting or desireable to Core developers.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000ec7baf06087e6b5b--