path: root/1b/b3bf637f31effa70d250fc82aa64400f949385

Return-Path: <casey@rodarmor.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 35A1DC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 02:15:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0B54F6125C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 02:15:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0B54F6125C
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=rodarmor.com header.i=@rodarmor.com
 header.a=rsa-sha256 header.s=google header.b=IOk7a/cg
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, 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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bT0iEVH-NpyX
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 02:15:19 +0000 (UTC)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [IPv6:2a00:1450:4864:20::132])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 6A1A060ECF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 02:15:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6A1A060ECF
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-507adc3381cso419801e87.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 08 Nov 2023 18:15:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=rodarmor.com; s=google; t=1699496117; x=1700100917;
 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=2hvCPgtowzYo9ssX6CDAG8J/E2ReIx7mGvoLo0nr6Hg=;
 b=IOk7a/cgh+zhGwG8M9UMyFEHmH0fT1rKRvz8isTnpoWve6La7DPQaqUUVZvh9HjIww
 67igm7QKZ2ehWhPdVf1E/K/UU8tAmxxfPXxtlkkZt0MkP3B2jInpA60KlCD1S7khAkfP
 2gsNAqDnFyZAGXIVqVWgCx6b3d8Rhz6+apfDTnT0dZhkC2TRuFxInPsFPY6V7YTyQc7t
 5QcR9tn4EuiU/qjaMxB8dWygMNtTVdqaSlAf+7jaUa7yIt1dYuEa4AR1loDMXEFvBsnP
 NqjI4UsfWbCdJHBVLGWyZFqF7xnEDPGP9bEmKcEqXYRpi5ats2vZ9D5RLsNEc3fT6sX2
 5wBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1699496117; x=1700100917;
 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=2hvCPgtowzYo9ssX6CDAG8J/E2ReIx7mGvoLo0nr6Hg=;
 b=Y+FXmsgNuD9xdzYNLuJaYn1a1Z0QwBooVP6L7LQku/8JL3IQIsOEMLmdYtsIxKLSik
 0ac2HP/zLr6Qmmym0EwNaYLvDjXnMFSc9Vgauhj3lnRF77qB5YX/xiLeR63dmHZn0xzs
 12pHMSCDjjsHG4lZMTS3NbZYX13qlj38sfNJO5bMyEPfkWVPlmoBUu4p9UpE5HaCU/px
 zseyYEkntiqJSjWJ/4HtDmGg2X+Q4+GwiIb3z0ckz8MBrqYFVEkgVc8IoTo+uCCB/U3f
 XlJ49DoJ6NfVEhpcsa9ZOlX/3QFOahsqoRj7FmaPEvlUTSB8bi9elP0vecVYPRwVF8k2
 /2/w==
X-Gm-Message-State: AOJu0Yz08XN7z8d6Loj0Q6GO6nI7s+KXJNy1bayvoWZxU3w3Qj1nNA2Q
 VuPHvnsumTb5Ifruz0+NkAh+amcdInspRPfP37tDMvGMlUqtrAY0z+6WiQ==
X-Google-Smtp-Source: AGHT+IFCeEwoIpmQM0FB64rlEfCYbQfW6mk6NJhQl9Uvc2QDJq3+KvjMKEUbyFr+tmoLGlxEZhTqeicKhtObLZEJCA8=
X-Received: by 2002:a05:6512:2384:b0:509:4424:2e0e with SMTP id
 c4-20020a056512238400b0050944242e0emr282589lfv.0.1699496116865; Wed, 08 Nov
 2023 18:15:16 -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>
In-Reply-To: <5b641ddc-a30b-4dd7-2481-6d9cdb459359@dashjr.org>
From: Casey Rodarmor <casey@rodarmor.com>
Date: Wed, 8 Nov 2023 18:15:05 -0800
Message-ID: <CANLPe+NAd4imuGji7+o+Y3bWtC4aeTMNj0RrJw0Pu4=e6TEdeQ@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000057e46d0609aec67a"
X-Mailman-Approved-At: Thu, 09 Nov 2023 12:42:08 +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 02:15:21 -0000

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

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 manner 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 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
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">Hi all,<br><br>Luke is definitely entitled to his opini=
ons about ordinals, and I certainly understand why people may not like ordi=
nals and inscriptions.<br><br>I don&#39;t think that ordinals are &quot;non=
sense&quot;, an &quot;attack on Bitcoin&quot;, or that I&#39;m dishonest, a=
s Luke implies, or that my actions are an attempt to &quot;harm/destroy Bit=
coin&quot;.<br><br>I think that whether or not ordinals are good is somethi=
ng about which reasonable people do and will disagree, and that an impartia=
l BIP editor would recognize this above their own personal feelings about t=
he matter.<br><br>Also, regarding:<br><br>&gt; There is a debate on the PR =
whether the &quot;technically unsound, ..., or not in keeping with the Bitc=
oin philosophy.&quot; or &quot;must represent a net improvement.&quot; clau=
ses (BIP 2) are relevant. <br><br>As I said in my initial email, I think th=
ese standards are being applied in a way that they have not been to previou=
s BIPs, which include all manner of things, including changes to bitcoin wh=
ich are nearly unanimously thought to be quite harmful if adopted.<br><br>B=
est,<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.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">Everything standardized between Bit=
coin 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>

--00000000000057e46d0609aec67a--