path: root/78/16c09c5f293b3882ac4de04d4e5040026b75da

Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9101BC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 09:15:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 6525140C00
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 09:15:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6525140C00
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 UNPARSEABLE_RELAY=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 JAJlrTev_Gga
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 09:15:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C45A1405B8
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C45A1405B8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 09:15:44 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1pNVgy-0004Dn-I8
 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 02 Feb 2023 19:15:41 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Thu, 02 Feb 2023 19:15:33 +1000
Date: Thu, 2 Feb 2023 19:15:33 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y9t/NcgRzv1w//Fx@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [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: Thu, 02 Feb 2023 09:15:46 -0000

Hi *,

Casey Rodarmor's ordinals use the technique of tracking the identity of
individual satoshis throughout their lifetime:

On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev wrote:
> Briefly, newly mined satoshis are sequentially numbered in the order in
> which they are mined. These numbers are called "ordinal numbers" or
> "ordinals". When satoshis are spent in a transaction, the input satoshi
> ordinal numbers are assigned to output satoshis using a simple
> first-in-first-out algorithm.

This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408

When accompanied by a standard for associating some data or right with
such an identity, this allows the creation of non-fungible tokens (or
semi-fungible tokens) whose ownership can be transferred by a bitcoin
transaction.

The proposed BIP doesn't document any method for associating data or a
right with an ordinal, but the "ord" tool defines "inscriptions" to fill
this gap [0], providing a way of including mime-encoded data in a taproot
witness. To make such an inscription, two transactions are required:
one paying some sats to a special scriptPubKey that commits to the
inscribed data, and a second that spends those sats to the owner of the
newly inscribed ordinal, and in so doing revealing the full inscription.

[0] https://docs.ordinals.com/inscriptions.html

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.

[1] https://twitter.com/ajtowns/status/1619554871166013441

In particular, rather than looking at it as being the owner of the sats
that inscribes some content on those sats (analogously to signing a $100
bill [2]), you could look at it as saying "the owner of this thing is
whoever owns this particular sat" (eg instead of "whoever owns this
share certificate is a shareholder", it's "whoever owns the $1 bill with
serial number X is a shareholder").

[2] https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers

Implementing that is fairly straightforward: you just need a protocol
for creating an asset offchain and associating it with an ordinal --
nothing needs to happen on-chain at all. That is, you can do something
as simple as posting a single nostr message:

  {
    "pubkey": <creator's pubkey>
    "kind": 0,
    "tags": [
      ["ord", "txid:vout:sat"]
    ],
    "content": [jpeg goes here],
    "id": <hash of the above>
    "sig": <signature of id by creator's pubkey>
  }

You can prove current ownership of the message by showing a custody
chain, that is the transaction specified by "txid" in the "ord" tag,
then every transaction that spent the given sat, until you get to one
that's still in the utxo set [3]. You don't need to provide witness
data or validate any of these tx's signatures, as that is already
implicit in that you end up at a tx in the utxo set. Just calculating
the txids and comparing against the output containing the sat you're
interested in is sufficient.

[3] If the satoshi was lost to fees at some point, you could continue to
    follow ownership by including an entire block in the custody chain.
    But seems better to just consider it as "abandoned" or "lost to the
    public domain" at that point.

This approach allows all the "inscription" data to be entirely off-chain,
the only thing that requires a transaction on-chain is transferring
ownership to someone else. That allows the NFT's existance can be kept
entirely private if desired; it also makes it cheap to create a new NFT
(you don't need to pay any on-chain fees at all); and it doesn't impose
an outsized overhead on people who aren't interested in your inscriptions,
but may be interested either in bitcoin per se, or in other inscriptions.

For things that have real intrinsic value -- equity rights in a company,
bragging rights for supporting an artist, etc -- this seems like it's
probably a viable approach: owners can "self-custody" all the information
about the things they own without having to rely on third parties,
transfers are no more censorable than any other bitcoin transaction
(especially if the association of the NFT with some particular sat is
not widely known), etc.

The "inscription" approach might still be desirable for broadcasting
information that might otherwise be subject to heavy censorship; presuming
that the censoring entity isn't also willing and able to censor bitcoin
itself. It's not clear that there's any "rights" to be owned for such a
case -- you can't buy the right to be the person that first published
it, and the point of widely broadcasting the information is so it's
not a secret only known to a few anymore. Also, claiming ownership of
such information would presumably make you a target for the censor,
even if just as an example for others. So I'm dubious of the value of
associating an inscription with an ordinal for that use case.

It's also possible that the perceived value of the NFT isn't due to
the inscription, but rather due to the scarcity of the blockspace it
was inscribed in (eg [4]). This is different from Bitcoin's scarcity
-- by 2100 or so there'll be a total of 2100T satoshis available,
but in that same time there will only have been about 4T vbytes of
blockspace available, and perhaps it could make sense to value spent
vbytes proportionally, so 4 spent vbytes is worth 2100 sats. In that
case if you spent 50kvb inscribing a jpeg, perhaps the "rights" to that
jpeg should be worth the same as 50k/4*2100 sats or 0.26 BTC. Doesn't
seem like a sound argument to me -- there's always more blockspace being
created, by fewer and fewer sats being created, and ordinals are far more
awkward to deal with, but I suppose it's still conceivable, and people
at least claim to believe it. If it were true, this argument suggests
the price for blockspace today should be around 2488sat/vB (19.28MBTC /
774700 MvB), rather than 1sat/vB.

[4] https://twitter.com/vnprc/status/1619876888687820801

Anyway, comparisons to ordinal inscriptions aside, I think there's
another interesting point from all this.

Presume you have a tool that implements the nostr ordinal assignment
suggested above: that is, a small modification of the "ord" tool that
can track a chain of custody for an ordinal specified in a nostr event
like the above. That allows you to do NFTs completely unobservably --
you don't have to publish anything to the blockchain apart from ordinary
looking transactions to transfer ownership of your NFT. To your benefit,
that makes it hard for anyone to censor you; but to bitcoin more broadly,
I think it means that the possibility of coloured bitcoins is largely
unavoidable and simply something that must be dealt with, rather than
something we should spend time trying to prevent/avoid. Compare with:

> My personal, and possibly controversial, opinion is that colored coin
> protocols have no business being on the Bitcoin chain, possibly beyond
> committing to an occasional batched state update or so. Both because
> there is little benefit for tokens with a trusted issuer already, and
> because it competes with using Bitcoin for BTC - the token that pays
> for its security (at least as long as the subsidy doesn't run out).
>
> Of course, personal opinions are no reason to dictate what people should
> or can use the chain for, but I do think it's reason to voice hesitancy
> to worsening the system's scalability properties only to benefit what
> I consider misguided use.

 -- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019500.html

I don't think this actually results in majorly misaligned incentives
though: in the nostr-nfts-on-btc world, everyone is still optimising
bitcoin transactions for the same thing -- transfer of value. It's just
that in some cases some sats are valued differently than others --
perhaps my uninscribed sats are worth 0.025 cents each, but you have
a particular inscribed sat that's worth $100k. But we're both dealing
just spending utxos and creating new utxos, doing signatures and maybe
some timelocks or hash reveals. And it's always been possible that
your transaction transferring $100k won't get charged higher fees than
my transfer of $50 -- we care about transaction size, not value after
all. How much does it matter if your tx matters more to your because
someone wants your particular sat, rather than what could happen today
where you have a utxo with 4 BTC while my utxo only has 0.002 BTC?

I think the only way to prevent that sort of NFT structure would be
to have every transaction use fancy zero-knowledge proofs that make it
impossible to associate who received bitcoin with who spent it -- *even
if* both the sender and recipient were willing to cooperate to reveal
that information. I think it would be hard to achieve that while still
making it easy to audit bitcoin's total supply, but I might be wrong.

Note that off-chain colouring here means that someone can create an NFT
that you don't want it, and just assign it to a sat that's already in your
wallet. However, they can do this anyway, by first creating the NFT, then
sending it to your wallet address. A difference though is that they could
create an NFT and assign it to the same ordinal/sat as some existing NFT
that you do value, at which point it's (presumably) impossible to discard
one without discarding both. But again, this is simply something they
can do, just be writing a patch to ord and composing a nostr message;
it's not something you can actually prevent even if you dislike it.

Particularly for semi-fungible tokens, this is perhaps inferior to
Liquid's multi-asset model -- here if you have a utxo with 1M sats, 500
of which are inscribed to each represent rights to $1 worth of USDT,
then rather than acting like a stable coin and being worth $500; it's
actually worth $500+0.01BTC, which is more like $750, and changes as
the value of bitcoin changes.

Cheers,
aj