From: Casey Rodarmor <casey@rodarmor•com>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
Date: Thu, 2 Feb 2023 22:39:21 -0800 [thread overview]
Message-ID: <CANLPe+Pa-D=JB8N5Qeokoyp=mRA3LLM=mtvvwPkpbHvV_bmEXQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 6274 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 7864 bytes --]
next reply other threads:[~2023-02-03 6:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 6:39 Casey Rodarmor [this message]
2023-02-04 10:38 ` Anthony Towns
2023-02-04 11:36 ` Aymeric Vitte
2023-02-04 13:02 ` alicexbt
2023-02-04 13:06 ` Peter Todd
2023-11-17 7:58 ` Anthony Towns
-- strict thread matches above, loose matches on Subject: below --
2023-11-20 19:47 vjudeu
2023-02-02 9:15 Anthony Towns
2023-02-02 12:19 ` Aymeric Vitte
2023-02-02 13:46 ` Rijndael
2023-02-02 14:22 ` alicexbt
2023-02-02 14:30 ` Peter Todd
2023-02-02 16:06 ` Aymeric Vitte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANLPe+Pa-D=JB8N5Qeokoyp=mRA3LLM=mtvvwPkpbHvV_bmEXQ@mail.gmail.com' \
--to=casey@rodarmor$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox