path: root/88/8ca4f0b0d0fb31a4276ec328b8fbd07064f433

Return-Path: <aubergemediale@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 31776C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 22:32:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id EA93641842
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 22:32:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EA93641842
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=OQZrbKYW
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_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 C28d2KHNpwnN
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 22:32:22 +0000 (UTC)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [IPv6:2a00:1450:4864:20::633])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 2721C40360
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 22:32:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2721C40360
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-9e213f198dfso243771866b.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 09 Nov 2023 14:32:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1699569140; x=1700173940;
 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=HRz2/qwDEX2YZ/VMEDeBmvXMY1ijpbyIH9E4AwEX/o4=;
 b=OQZrbKYWixs7n0jssy9KG6REHFu9qPE7CZfkgIC1QfJJopqFRrHskPjxQtVvo73r8Z
 YM7rU5sRQZBgA2NVNexxmE0GSnDAJ9kxo/ybqpVodYHAktruo8fw8U0fEFeoqiZfIFuf
 r+X72gdT02rZ0QFC7pGY7pFxdL/Oltyg7tuyMMZVpmFNmzrgA6KyuZF5VM9vwEQmiyuU
 FcfEgagJQiwUklTLwYRPmCrGnkohzcKMcAJ/CD0S2ajCaadNVXnvEwoiBq8RKVskLZvU
 eXa9IvYIsCYW5hhC+NkAUqMF4adt/pCAuymBVUdmfaUKTXHqzpQVSB+QAp9bO2iEYTaP
 onZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1699569140; x=1700173940;
 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=HRz2/qwDEX2YZ/VMEDeBmvXMY1ijpbyIH9E4AwEX/o4=;
 b=rXf9U+Z+gRPv9cbJdgbPYn5d6Wf3h0vWN3QTI4u9tF9n4bS6449dE4DCGcpzDleDqn
 qnhKsSc8SNBW9UInF0NFrYQNxaYUtDzkA/ispQNexwpXW04ZmAzO/sTbci1wfw+vD+Z8
 sPoa8+e8GdgC+S5HiWiharzxBy/OBUCLa76dC6VOqvCvNAl2Ya/p3RvnN+YVLJrnfmAa
 CB7EU8y/crLbl17Rp+dzlxe8EBqdgQrhjt3FFwvFWk4vwAfGwRjI10wDNarrtLXgRbNn
 18SnHzZcWw0kOpZsQKT//P+LRzuAis5rPMCZCBCjIoWpXPa3os4moOd1oZ4tIlWZDOBh
 vKiA==
X-Gm-Message-State: AOJu0YzMXdHPFQ3EXcLXyIxovlXQtTXqNB4Ghc+9MgQ6VT9re5wdTn7e
 NYSJRJqwXJhSYrVfZ9t+xHaaEEylFxWUL4Mon8qGW1Z8
X-Google-Smtp-Source: AGHT+IFs6Q3bAoqaItbbG0v4NCEyPw9VcU3XEeSd/mOP0XGEycXpdQIJwccAlr2haSRakrRJ2hJkNZjbN6JbotiKoww=
X-Received: by 2002:a17:906:fe02:b0:9c7:58cd:b57 with SMTP id
 wy2-20020a170906fe0200b009c758cd0b57mr5133223ejb.37.1699569139960; Thu, 09
 Nov 2023 14:32:19 -0800 (PST)
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>
 <CANLPe+NAd4imuGji7+o+Y3bWtC4aeTMNj0RrJw0Pu4=e6TEdeQ@mail.gmail.com>
In-Reply-To: <CANLPe+NAd4imuGji7+o+Y3bWtC4aeTMNj0RrJw0Pu4=e6TEdeQ@mail.gmail.com>
From: Claus Ehrenberg <aubergemediale@gmail.com>
Date: Thu, 9 Nov 2023 23:32:10 +0100
Message-ID: <CANPykMqq-1Xh5WcHpKPeyfi6YAfjP2gJsO863K=D0yr2McT4aQ@mail.gmail.com>
To: Casey Rodarmor <casey@rodarmor.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000dbd0bd0609bfc6d9"
X-Mailman-Approved-At: Thu, 09 Nov 2023 23:03:12 +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: Thu, 09 Nov 2023 22:32:24 -0000

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

Hello,

I have developed nodes/wallets for Bitcoin and Bitcoin-derived Altcoins.
3rd-party Bitcoin developers take BIPs very seriously, basically as
must-implement/must-comply features.

Therefore, I think it would be best to restrict BIPs to the minimum
necessary to implement a complying node/wallet.

Cheers!

Claus

On Thu, Nov 9, 2023 at 1:43=E2=80=AFPM Casey Rodarmor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Luke is definitely entitled to his opinions about ordinals, and I
> certainly understand why people may not like ordinals and inscriptions.
>
> I don't think that ordinals are "nonsense", an "attack on Bitcoin", or
> that I'm dishonest, as Luke implies, or that my actions are an attempt to
> "harm/destroy Bitcoin".
>
> I think that whether or not ordinals are good is something about which
> reasonable people do and will disagree, and that an impartial BIP editor
> would recognize this above their own personal feelings about the matter.
>
> Also, regarding:
>
> > 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.
>
> As I said in my initial email, I think these standards are being applied
> in a way that they have not been to previous BIPs, which include all mann=
er
> of things, including changes to bitcoin which are nearly unanimously
> thought to be quite harmful if adopted.
>
> Best,
> Casey
>
> 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
>

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

<div dir=3D"ltr">Hello,<div><br></div><div>I have developed nodes/wallets f=
or Bitcoin and Bitcoin-derived Altcoins. 3rd-party Bitcoin developers take =
BIPs very seriously, basically as must-implement/must-comply features.</div=
><div><br></div><div>Therefore, I think it would be best to restrict BIPs t=
o the minimum necessary to implement a complying node/wallet.</div><div><br=
></div><div>Cheers!</div><div><br></div><div>Claus</div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 9, 2023=
 at 1:43=E2=80=AFPM Casey Rodarmor via bitcoin-dev &lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif">Hi all,<br><br>Luke is definitely entitled to his opinio=
ns about ordinals, and I certainly understand why people may not like ordin=
als and inscriptions.<br><br>I don&#39;t think that ordinals are &quot;nons=
ense&quot;, an &quot;attack on Bitcoin&quot;, or that I&#39;m dishonest, as=
 Luke implies, or that my actions are an attempt to &quot;harm/destroy Bitc=
oin&quot;.<br><br>I think that whether or not ordinals are good is somethin=
g about which reasonable people do and will disagree, and that an impartial=
 BIP editor would recognize this above their own personal feelings about th=
e matter.<br><br>Also, regarding:<br><br>&gt; There is a debate on the PR w=
hether the &quot;technically unsound, ..., or not in keeping with the Bitco=
in philosophy.&quot; or &quot;must represent a net improvement.&quot; claus=
es (BIP 2) are relevant. <br><br>As I said in my initial email, I think the=
se standards are being applied in a way that they have not been to previous=
 BIPs, which include all manner of things, including changes to bitcoin whi=
ch are nearly unanimously thought to be quite harmful if adopted.<br><br>Be=
st,<br>Casey<br></div></div><br><div class=3D"gmail_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.linuxfoundation.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Everything standar=
dized between 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>
_______________________________________________<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>

--000000000000dbd0bd0609bfc6d9--