path: root/ef/2b671e5afd00e972a3fe30d6a5ef7d5bbcc15c

Return-Path: <casey@rodarmor.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3547CC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Feb 2023 06:39:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 05326820B9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Feb 2023 06:39:25 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 05326820B9
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=rodarmor.com header.i=@rodarmor.com
 header.a=rsa-sha256 header.s=google header.b=gUjCY7ul
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id h9C3jRBgyuL1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Feb 2023 06:39:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6A7BA820B6
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com
 [IPv6:2607:f8b0:4864:20::e33])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 6A7BA820B6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Feb 2023 06:39:23 +0000 (UTC)
Received: by mail-vs1-xe33.google.com with SMTP id s24so4361092vsi.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 02 Feb 2023 22:39:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rodarmor.com; s=google;
 h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=pAkYYD+NiOvePGz0s284x3jX5exlOX3XqJJnusiucUk=;
 b=gUjCY7ulIcRCHcjzpZ1XsAAPg/69T82CPLEj8Z9YtsU3B1pfEnKhw6dCcsslyWXkSQ
 MpoYN/Z29jkLzC//q32ccnm7FDZTMW5cWJq6XUkYaWy5JFwkMTXKgC8MWVAw6HjMBt0j
 sRVtfUGIaytinztukoLJVN1MuEK7//y/f1jlMoPqxKtiRfZJuxaRoi18PvtV+EQ8fgOs
 B3DHoVyJHnBKtkpXsf64bm8Lspd9RxFFEc6HoecqGlNlaFe6T8SsvnASkWc1qX2ATf8V
 W5hYe/E8Wb20o63Hm6BeteYxqe2BXrjln+azi/9gDyLd4BPTI0hiTh9iH70lLI/PFIi8
 R6EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=pAkYYD+NiOvePGz0s284x3jX5exlOX3XqJJnusiucUk=;
 b=PKwZqZZCUNN+S3ILWaxyslpBVa2LvmdTPGNKfXZKnWAsL32/v+4ZtO0JSXGgtfPhux
 4cx75yNhXf9OYhHsT0FjHfUrifmVQVe10yg9jgL8yBzuDYi/4XtvB0nZERz3rypHjvR1
 geelGhbqG33Q3/f2WLJOJBkZHBRBg3yAozCpE/1kx8TgR2trZsG0ZCTnuTtu8WCzNYhp
 ysnycm8KoA/luXAa4+wwyT1l/N0ukA3RZrPQpzmu6qe0AzZXj7HIRLEr+RIbljerf78Z
 QosAuRFYvlwvEEv/1hBmoBFf7Trs+sEgNziimnRuMeTj0l3OdO8S2mupjzJKUjlNy0xv
 SZ3w==
X-Gm-Message-State: AO0yUKUft0dbRS/3bWGj2QqrQRDUdTT4pYUpSgYJ6SUxNK0l37uKuGui
 yzq8pWZSv7mmH3mzjE66CmW94TA1QoJCOPhqpDTXN6UZ66wzeQ==
X-Google-Smtp-Source: AK7set8qm12WFz7HJcItqyAU3z9/6r9i0/Vx7wGTbOsY+C97CHybNRGgLTBCUXkewPu8Kg5gNb396qjlZ6ydqlhvMvE=
X-Received: by 2002:a67:e1cb:0:b0:3e9:6d7f:6f37 with SMTP id
 p11-20020a67e1cb000000b003e96d7f6f37mr1467211vsl.3.1675406361793; Thu, 02 Feb
 2023 22:39:21 -0800 (PST)
Received: from 649336022844 named unknown by gmailapi.google.com with
 HTTPREST; Thu, 2 Feb 2023 22:39:21 -0800
Mime-Version: 1.0
X-Superhuman-Thread-ID: draft00eb096193755ab9
From: Casey Rodarmor <casey@rodarmor.com>
X-Mailer: Superhuman Web (2023-02-02T23:05:55Z)
X-Superhuman-ID: ldo5odp8.64e30edb-72c6-4b22-9667-97d4952c3583
X-Superhuman-Draft-ID: draft008b73e5cbfb47c6
Date: Thu, 2 Feb 2023 22:39:21 -0800
Message-ID: <CANLPe+Pa-D=JB8N5Qeokoyp=mRA3LLM=mtvvwPkpbHvV_bmEXQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000000cac6705f3c5f1c1"
X-Mailman-Approved-At: Fri, 03 Feb 2023 10:13:25 +0000
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
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: Fri, 03 Feb 2023 06:39:25 -0000

--0000000000000cac6705f3c5f1c1
Content-Type: text/plain; charset="UTF-8"

Good evening list,

Apologies for posting! I've tried to keep discussion of ordinals and
inscriptions off-list, because I consider it to be of little relevance to
general Bitcoin development. Also, apologies for the HTML mail, but I don't
have my email client configured correctly. And finally, also apologies if
this breaks the thread, I was subscribed but not receiving mail, so I can't
respond to the original message.

AJ Towns writes:

I think, however, that you can move inscriptions entirely off-chain. I
wrote a little on this idea on twitter already [1], but after a bit more
thought, I think pushing things even further off-chain would be plausible.


Actually, my initial sketch for Ordinal NFTs worked in a similar fashion,
with off-chain messages pointing to an ordinal, which could be tracked by
following the chain of custody of that particular sat. I gave a workshop
last year where I handed out paper wallets to participants with a private
key that controlled some sats, which could both be assigned NFTs and used
to sign messages as a form of provenance:

https://www.youtube.com/watch?v=j5V33kV3iqo

Ultimately, I decided against this design, and Peter provided an excellent
explanation of some of the trade-offs of such a design in his mail, but to
at least partially recap and explain my own thinking:

NFT collectors have a strong revealed preference for on-chain content. The
content of high-value NFTs is often stored partially or completely on
chain, even if details of the NFT protocol involved actually prevents that
content from being what you see when you view the NFT on a website or
marketplace.

User protection when off-chain content is involved is fraught. Users are
not equipped, due to lack of technical knowledge, easily available,
user-friendly tools, and education, to protect themselves when they buy a
collectable whose content is stored off-chain. When a user buys an NFT with
off-chain content, they now have the primary economic incentive to preserve
that content, so that their NFT retains value and can be enjoyed or sold.
Many existing NFT marketplaces that sell off-chain content do not explain
this to users, or give users tools that the average, non-technical person
can understand or use, which enables them to protect themselves. Even if
they did give users these tools, there are tricky considerations involved.
IPFS functions much like BitTorrent, so even if users were provided with an
IPFS application that could persist their off-chain NFT content
automatically, they might reveal their IP address, which would then be
linked to ownership of their NFT, which would have privacy and safety
considerations.

Another issue is salience and scarcity, as has been mentioned. Off-chain
content is unbounded, and thus less scarce. Usually, we design for
efficiency, volume, and scale. For NFT designs, which are intended to be
collectable, this is in some ways counterproductive.

The above issues also make the specification and implementation of NFTs
with off-chain content much more difficult. Ordinals is a project largely
written by a single developer, me, with the assistance of two part time
interns. It is very intentionally the simplest thing that could possibly
work, much like Bitcoin itself. Sometimes I refer to it as "cave-man
technology". If I was designing an off-chain NFT protocol, I would likely
have had to raise money and recruit a large team, which I have not done, or
be at risk of never launching anything at all.

I would absolutely love for the ordinals protocol, that is, the numbering
and transfer of individual satoshis, be used as the basis for alternative,
off-chain NFT and colored coin schemes, with proper consideration given to
the issues above.

However, I would request that, to avoid confusion, these alternative
schemes never be called inscriptions.

I'm a dev, not a cop, but fine distinctions are hard to properly explain
and understand. Inscriptions, that is, the NFT protocol which embeds
content in transaction witnesses, has a particular set of trade-offs and
guarantees. I want users to know that if they buy or value something they
or others call an "inscription", they can rely on those trade-offs and
guarantees. Another NFT protocol named "inscriptions" would make this very
difficult.

Additionally, I think the term "inscription" which has a connotation of
permanence, and of an indelible association with a particular satoshi, is
inappropriate for an off-chain NFT protocol.

Sorry to belabor this point! Inscriptions have already proven very popular
for a nascent protocol, beyond my expectations, and the terminology and
naming is still new, so it's a critical phase in terms of understanding and
education.

If others are interested in developing ordinals further, a great first step
would be to provide review and feedback on the BIP PR:

https://github.com/bitcoin/bips/pull/1408

I have never written a BIP, so style and content feedback is especially
welcome.

Inscriptions themselves have no BIP, although at least one alternative
implementation of the inscription parser has been written:

https://ordinals.com/content/6f46a2a830a90e406245b188631cd15ffea31b8be146255ec39d4d46bbe15663i0

I hope to write a BIP for inscriptions as the implementation and protocol
mature.

In general, although I do love the ordinals protocol, it has many
downsides, which I hope people will consider when considering it for
alternative colored coin schemes. These include the fact that divisibility
is limited, both by the use of real sats and the dust limit, that cardinal
satoshis must be used to pay fees, the general insanity of ordinal-aware
transaction construction[0], and difficult in lifting ordinals onto an L2.
I consider ordinals ideal for art projects like inscriptions and
ordinal-theory-powered satoshi numismatics, where aesthetic and technical
considerations are nearly equally important.

Please feel free to contact me privately by email, or on the ordinals
project GitHub[1] if you'd like to respond! My intention with this message
is not to spark debate, since I consider it mostly off-topic for this list.

Best regards,
Casey Rodarmor

[0]
https://github.com/casey/ord/blob/master/src/subcommand/wallet/transaction_builder.rs
[1] https://github.com/casey/ord

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

<html><head></head><body><div><div><div class=3D"">Good evening list,<br></=
div><div class=3D""><br></div><div class=3D"">Apologies for posting! I&#39;=
ve tried to keep discussion of ordinals and inscriptions off-list, because =
I consider it to be of little relevance to general Bitcoin development. Als=
o, apologies for the HTML mail, but I don&#39;t have my email client config=
ured correctly. And finally, also apologies if this breaks the thread, I wa=
s subscribed but not receiving mail, so I can&#39;t respond to the original=
 message.<br></div><div class=3D""><br></div><div class=3D"">AJ Towns write=
s:<br></div><div class=3D""><br></div><blockquote class=3D""><div class=3D"=
">I think, however, that you can move inscriptions entirely off-chain. I
wrote a little on this idea on twitter already [1], but after a bit more
thought, I think pushing things even further off-chain would be plausible. =
<br></div></blockquote><div class=3D""><br></div><div class=3D"">Actually, =
my initial sketch for Ordinal NFTs worked in a similar fashion, with off-ch=
ain messages pointing to an ordinal, which could be tracked by following th=
e chain of custody of that particular <span class=3D"sh-date">sat</span>. I=
 gave a workshop last year where I handed out paper wallets to participants=
 with a private key that controlled some sats, which could both be assigned=
 NFTs and used to sign messages as a form of provenance:<br></div><div clas=
s=3D""><br></div><div class=3D""><div class=3D""><a class=3D"" rel=3D"noope=
ner noreferrer" href=3D"https://www.youtube.com/watch?v=3Dj5V33kV3iqo" targ=
et=3D"_blank">https://www.youtube.com/watch?v=3Dj5V33kV3iqo</a><br></div><d=
iv class=3D""><div class=3D""><br></div></div><div class=3D"">Ultimately, I=
 decided against this design, and Peter provided an excellent explanation o=
f some of the trade-offs of such a design in his mail, but to at least part=
ially recap and explain my own thinking:<br></div><div class=3D""><br></div=
><div class=3D"">NFT collectors have a strong revealed preference for on-ch=
ain content. The content of high-value NFTs is often stored partially or co=
mpletely on chain, even if details of the NFT protocol involved actually pr=
events that content from being what you see when you view the NFT on a webs=
ite or marketplace.<br></div><div class=3D""><br></div><div>User protection=
 when off-chain content is involved is fraught. Users are not equipped, due=
 to lack of technical knowledge, easily available, user-friendly tools, and=
 education, to protect themselves when they buy a collectable whose content=
 is stored off-chain. When a user buys an NFT with off-chain content, they =
now have the primary economic incentive to preserve that content, so that t=
heir NFT retains value and can be enjoyed or sold. Many existing NFT market=
places that sell off-chain content do not explain this to users, or give us=
ers tools that the average, non-technical person can understand or use, whi=
ch enables them to protect themselves. Even if they did give users these to=
ols, there are tricky considerations involved. IPFS functions much like Bit=
Torrent, so even if users were provided with an IPFS application that could=
 persist their off-chain NFT content automatically, they might reveal their=
 IP address, which would then be linked to ownership of their NFT, which wo=
uld have privacy and safety considerations.<br></div><div><br></div><div>An=
other issue is salience and scarcity, as has been mentioned. Off-chain cont=
ent is unbounded, and thus less scarce. Usually, we design for efficiency, =
volume, and scale. For NFT designs, which are intended to be collectable, t=
his is in some ways counterproductive.<br></div><div><br></div><div>The abo=
ve issues also make the specification and implementation=C2=A0of NFTs with =
off-chain content much more difficult. Ordinals is a project largely writte=
n by a single developer, me, with the assistance of two part time interns. =
It is very intentionally the simplest thing that could possibly work, much =
like Bitcoin itself. Sometimes I refer to it as &quot;cave-man technology&q=
uot;. If I was designing an off-chain NFT protocol, I would likely have had=
 to raise money and recruit a large team, which I have not done, or be at r=
isk of never launching anything at all.<br></div><div><br></div><div>I woul=
d absolutely love for the ordinals protocol, that is, the numbering and tra=
nsfer of individual satoshis, be used as the basis for alternative, off-cha=
in NFT and colored coin schemes, with proper consideration given to the iss=
ues above.<br></div><div><br>However, I would request that, to avoid confus=
ion, these alternative schemes never be called inscriptions.</div><div><br>=
</div><div>I&#39;m a dev, not a cop, but fine distinctions are hard to prop=
erly explain and understand. Inscriptions, that is, the NFT protocol which =
embeds content in transaction witnesses, has a particular set of trade-offs=
 and guarantees. I want users to know that if they buy or value something t=
hey or others call an &quot;inscription&quot;, they can rely on those trade=
-offs and guarantees. Another NFT protocol named &quot;inscriptions&quot; w=
ould make this very difficult.<br></div><div><br></div><div>Additionally, I=
 think the term &quot;inscription&quot; which has a connotation of permanen=
ce, and of an indelible association with a particular satoshi, is inappropr=
iate for an off-chain NFT protocol.<br></div><div><br></div><div>Sorry to b=
elabor this point! Inscriptions have already proven very popular for a nasc=
ent protocol, beyond my expectations, and the terminology and naming is sti=
ll new, so it&#39;s a critical phase in terms of understanding and educatio=
n.<br></div><div><br></div><div>If others are interested in developing ordi=
nals further, a great first step would be to provide review and feedback on=
 the BIP PR:<br></div><div><br></div></div><div><a href=3D"https://github.c=
om/bitcoin/bips/pull/1408">https://github.com/bitcoin/bips/pull/1408</a><br=
></div><div><br></div><div>I have never written a BIP, so style and content=
 feedback is especially welcome.</div><div><br></div><div>Inscriptions them=
selves have no BIP, although at least one alternative implementation of the=
 inscription parser has been written:<br></div><div><br></div><div><a href=
=3D"https://ordinals.com/content/6f46a2a830a90e406245b188631cd15ffea31b8be1=
46255ec39d4d46bbe15663i0">https://ordinals.com/content/6f46a2a830a90e406245=
b188631cd15ffea31b8be146255ec39d4d46bbe15663i0</a><br></div><div><br></div>=
<div>I hope to write a BIP for inscriptions as the implementation and proto=
col mature.<br></div><div class=3D""><div><br></div><div>In general, althou=
gh I do love the ordinals protocol, it has many downsides, which I hope peo=
ple will consider when considering it for alternative colored coin schemes.=
 These include the fact that divisibility is limited, both by the use of re=
al sats and the dust limit, that cardinal satoshis must be used to pay fees=
, the general insanity of ordinal-aware transaction construction[0], and di=
fficult in lifting ordinals onto an L2. I consider ordinals ideal for art p=
rojects like inscriptions and ordinal-theory-powered satoshi numismatics, w=
here aesthetic and technical considerations are nearly equally important.<b=
r></div><div><br></div><div>Please feel free to contact me privately by ema=
il, or on the ordinals project GitHub[1] if you&#39;d like to respond! My i=
ntention with this message is not to spark debate, since I consider it most=
ly off-topic for this list.<br></div><div><br></div><div>Best regards,<br><=
/div><div>Casey Rodarmor<br></div></div><div><br></div><div>[0]=C2=A0<a hre=
f=3D"https://github.com/casey/ord/blob/master/src/subcommand/wallet/transac=
tion_builder.rs">https://github.com/casey/ord/blob/master/src/subcommand/wa=
llet/transaction_builder.rs</a><br></div><div>[1]=C2=A0<a href=3D"https://g=
ithub.com/casey/ord">https://github.com/casey/ord</a><br></div></div><div><=
/div><br><div class=3D"gmail_signature"></div></div></body></html>

--0000000000000cac6705f3c5f1c1--