From: Anthony Towns <aj@erisian•com.au>
To: Casey Rodarmor <casey@rodarmor•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
Date: Sat, 4 Feb 2023 20:38:54 +1000 [thread overview]
Message-ID: <Y941vsOOsZJHdnKT@erisian.com.au> (raw)
In-Reply-To: <CANLPe+Pa-D=JB8N5Qeokoyp=mRA3LLM=mtvvwPkpbHvV_bmEXQ@mail.gmail.com>
On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev wrote:
> 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.
Anything that potentially uses up a large percentage of blockspace seems
pretty relevant to general Bitcoin development to me...
> 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.
I guess I should have explained why I think moving things off-chain is
a worthwhile goal. Riffing off:
> 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.
"scarce" has two meanings -- one is that there's not much of it, the
other is that it's highly valued (or a third, where it's is consistently
underpriced and unavailable even for people who'd pay more, but that
hopefully doesn't apply).
I think for bitcoin's blockspace, we ideally only want the first of
these to be true. We want small blocks because that makes it cheap to
verify bitcoin, which reduces the need to trust third parties and aids in
decentralisation. But we don't want blockspace to be especially valuable,
as that makes it expensive to use bitcoin, which then limits who can
use it.
Moving things off-chain helps with both these goals: it doesn't make it
harder to validate bitcoin, and it also decreases demand for blockspace,
making it cheaper for those cases where things can't be moved off-chain.
As a result of this approach, bitcoin blockspace is currently quite
cheap -- so inscribing at 100kB jpeg at 25kvB might cost perhaps $60 in
a peak period, or $6 if you wait for 1sat/vb to confirm. Not exactly a
luxury purchase.
If you keep jpegs on-chain, as far as I can see, there's three outcomes:
* blockspace stays relatively cheap, and there's no "scarcity" benefit to
minting via on-chain inscriptions; it's cheap enough to just mint
any random meme, and there's no prestige to doing so
* blockspace becomes filled with jpegs, driving up costs for everyone,
making jpeg collectors happy, but transactors sad
* the amount of blockspace is increased, keeping prices low, and
reducing "scarcity" in both senses, so also making it harder to
validate bitcoin. no one really wins.
I'd guess the first of these is the most likely, personally.
As far as salience/notability goes, personally, I'd see ownership of
inscriptions as a negative indicator; "hey, when I was young and foolish I
wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a
permanent cost for everyone trying to use bitcoin in future". That's not
unforgivable; people do all sorts of foolish things, and bitcoin's meant
to survive attacks, not just foolish pranks. But it doesn't seem like
something to brag about or encourage, either, at least if you want bitcoin
to be a monetary network that's usable in practice by many/most people.
(Even if one day that goes the other way, and there is real (and
transferable) social value in being able to say "I donated x sats to fees
to help secure bitcoin", such a claim is more charitable/admirable/value
with a smaller on-chain footprint, both in that it again keeps
validation easier, but also in that it makes it easier for others to
also simultaneously make the same charitable contribution)
> 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,
When you identify an NFT by a url that points at someone else's server,
that's an obvious vulnerability, as Moxie demonstrated pretty well.
But solving that by saying "okay, we'll just externalise the storage
costs to the public, while privatising all the benefits" isn't a good
approach either.
> User protection when off-chain content is involved is fraught.
I mean, that seems trivially solvable? Users already have to store the
private key that controls ownership of these digital assets; storing the
asset as well, which doesn't need to be private, isn't a big ask. And if
a public site like ordinals.net is willing to store all the inscriptions
that might be on the blockchain, they could just as easily store the
same amount of off-chain digital assets.
> 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.
Yes -- the people who potentially benefit from the NFT should be the
ones paying the costs of preserving that NFT.
> 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,
Externalising the costs to some different network while privatising the
benefits isn't any better than doing it to bitcoin; except in that maybe
you're inconveniencing fewer people.
Going back to this:
> 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.
Obviously blockchains aren't the only "scarce" good out there. If scarcity
is your goal, there's two very easy ways to make your own scarcity.
One is requiring proof of work -- you could have a digital
asset marketplace that only allows works that have a hash with
at least 32 leading zero-bits [0] and use timestamping [1] (or a
certificate-transparency approach) to ensure that as proof-of-work
techonology improves, it can't be used to backdate mints.
[0] https://github.com/nostr-protocol/nips/blob/master/13.md
[1] https://github.com/nostr-protocol/nips/blob/master/03.md
Or the other approach is you just require people to pay you some sats
over lightning to host an NFT. That way you're the one collecting the
fees, not miners; and you're (perhaps) the one incurring an obligation
to preserve the NFT on behalf of its owners, rather than random bitcoin
node operators.
> The above issues also make the specification and implementation of NFTs
> with off-chain content much more difficult.
I'm not meaning to criticise you for doing what you think's interesting,
so if it's coming off that way I apologise in advance. I think it's
interesting, too. I just think that, when possible, off-chain is always
better than on-chain, and it's worth exploring that idea further.
In particular, I don't think it *is* actually much more difficult? Here's
how I'd change what you've done to turn ordinals.net into an off-chain
digital asset site:
- setup a nostr relay, with submissions gated by proof of work, and
no expiry. maybe https://github.com/Cameri/nostream ?
- for any event that includes an "ordinal" tag, treat it as a digital
asset, and add it to your digital asset database, just like you do now
for inscriptions. either have your own nostr client that subscribes
to your relay, or just query your relay's db directly.
- have a regular proof of work adjustment targeting say 200MB worth of
events per day (vs the 576MB per day of possible witness data).
- update the ord tool to be able to encode digital artifacts into a nostr
event, apply proof of work to it, and send it to (by default)
your relay.
That would let nostr clients immediately just add your relay and get a
feed of minted digital artifacts, that's already spam-free due to the
proof of work requirement. They could follow all of them, or just follow
a particular artist by pubkey, too. An artist could publish a collection
by publishing an event defining the collection, then linking each artwork
to the collection as a "reply", making it pretty easy for nostr clients
to follow a collection, while still having each artwork linked to its
own ordinal, and I think without requiring any work on your behalf.
You don't need to change the way ordinals are spent at all for any of
this, I think; all you're doing is replacing the initial two transactions
that link the digital artifact with the ordinal with an off-chain message
achieving the same thing.
Then to go beyond what you've got you could:
- add some support for the current owner of an ordinal to link that
back to their nostr profile -- eg, sign a message with the pubkey
based on the current utxo holding the ordinal, referencing the digial
asset; you could perhaps use NIP-2 "following" messages for this.
if you've already using an open social network, might as well take
advantage of it.
- add some support for the "social legitimacy" aspect -- eg linking
all the assets created by the same public key as an artist's portfolio;
make it easy to go from their nft-related pubkey to their regular
nostr profile or similar.
- let creators that have already somehow demonstrated "social legitimacy"
bypass the proof of work requirement, since "great art" is already
naturally scarce. creators who've demonstrated their quality shouldn't
need to waste time or money doing proof of work or paying blockchain
fees
Adding a lightning based patreon-type setup could be awesome there --
content creators post content to a closed relay, patrons pay a fee
over lightning to be able to receive events, and 90%+ of those fees
are passed on to creators. If creators are happy with subscriptions,
they just do that; if they want to auction off NFTs, they can do that;
if they want both, that works too...
> 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.
No objections about the "inscription" definition, but I'm not sure if the
above means you're misunderstanding what I'm saying. In the off-chain
scheme I'm talking about, the "digital asset" includes the ordinal
that controls ownership, and is identified by the hash of its contents,
including that ordinal's identity -- so there is an indelible association
with a particular satoshi, despite it being an off-chain NFT protocol.
For example if you take two identical digital assets, such as:
https://ordinals.net/inscription/8ed2594cecbd43e5673168ff160ba00a6d8953fea7ab6b15a112f3bc94adc2f8i0
https://ordinals.net/inscription/31e9577f9af1d1823bc00539291f061e4ac9ba727162a8e0d8d7b80512966561i0
then in the off-chain world, they would look like two events:
{
pubkey: <Alice>
kind: 0
tags: [
ord: "8ed2594cecbd43e5673168ff160ba00a6d8953fea7ab6b15a112f3bc94adc2f8:0:0"
]
content: <av1.jpeg>
id: <XXXX - hash of the above>
sig: <sig by alice of XXXX>
}
and
{
pubkey: <Alice>
kind: 0
tags: [
ord: "31e9577f9af1d1823bc00539291f061e4ac9ba727162a8e0d8d7b80512966561:0:0"
]
content: <av1.jpeg>
id: <YYYY = hash of the above>
sig: <sig by alice of YYYY>
}
ie two unique digital assets, with two unique identifiers (XXXX and YYYY)
that are each indelibly linked with particular satoshis.
Obviously there's nothing stopping Alice minting the exact same content
to two different ordinals -- presumably that's what happened with
the two inscriptions above -- nor is there anything stopping Bob from
right-click-save-as and doing the same; but as above, that's obviously
true for inscriptions as well. The only truly unique thing is the specific
hash and the specific content that generated the hash.
The relationship does go the other way compared to inscriptions --
here you keep the association so long as you remember the asset; with
inscriptions you keep the association so long as you have bitcoin's
historical blocks. As I've said above, the off-chain approach seems
much better aligned with incentives to me, with the people who gain the
benefit from that association paying the cost of preserving it.
Cheers,
aj
next prev parent reply other threads:[~2023-02-04 10:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 6:39 Casey Rodarmor
2023-02-04 10:38 ` Anthony Towns [this message]
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=Y941vsOOsZJHdnKT@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=casey@rodarmor$(echo .)com \
/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