[bitcoin-dev] Purely off-chain coin colouring

[bitcoin-dev] Purely off-chain coin colouring

[Anthony Towns]

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

Re: [bitcoin-dev] Purely off-chain coin colouring

[Aymeric Vitte]

In your system what is the off-chain mechanism? And what prevent a thief
to steal your NFT?

I have submitted several time "A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7

It's more simple, the NFT (whether real or electronic) is referenced by
a initial hash (which is not the hash for example of your jpeg file
because easy to fake) and then get a final reference which is the hash
of the initial hash

The idea is that the real owner must prove that he has the knowledge of
the initial hash (for example luxury bag, you print the double hash on
it, and give the initial hash to the buyer, if the owner/seller can't
prove that he knows the inital hash, the bag is stolen or counterfeit
(with the double hash))

The NFT owner references the NFT signed by him in some trusted third
party allowing a timestanp (wayback machine for example), it proves that
he is the first one to have the knowledge of the double hash, so a thief
cannot intercept the "minting" transaction (if any because not really
necessary since the public key of the owner is known from the third
party) and steal the NFT for himself or do/replay a transaction with
this NFT, minting it or selling it several time

A third party is involved but it remains decentralized

Then the NFT owner and buyer exchange some information like for
lightning and do one transaction on Bitcoin storing the deal, see the
details in the proposals depending on what kind of deal occur between
the buyer and the seller, like lightning, if someone cheats, then he
loses his bitcoin

It's minimal, understandable, secured, decentralized and not expensive,
that's why I don't see very well why to complicate with ordinals

The proposal envisions the concept of "secret" NFTs also


The continuation of this proposal is "A Universal Coin Swap system based
on Bitcoin" https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7

It's simple also, you go from Decentraland to the Sandbox but don't have
SAND and want to pay with MANA, you agree on a MANA/SAND deal with the
seller which is stored in Bitcoin signed by both, then you pay with
MANA, other use cases are described in the proposal

Note: both proposals need to be modified since I thought OP_RETURN max
size was 512B and it is in fact 80B, which does not work for all cases


Le 02/02/2023 à 10:15, Anthony Towns via bitcoin-dev a écrit :
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

Re: [bitcoin-dev] Purely off-chain coin colouring

[Rijndael]

Hi AJ and List,

This reminds me of a series of blog posts Peter Todd wrote a few years
ago about using "single use seals" for tracking (fungible) assets
anchored to Bitcoin[0]. I believe that the RBG Protocol Project and Taro
are both using the same underlying principle.

Having the actual application data offchain, but with a commitment to a
UTXO and then using Bitcoin only as a proof-of-publication system to
prevent double-spends seems like a really good idea. As you point out,
in addition to being cheaper and more scalable, it means that not
everyone on the network has to know that there's an asset involved. It
just looks like plain old bitcoin transfers.

A lot of people have written about or are (I think) working on
implementations of this idea. I really like your suggestion of using
nostr. Clients can keep the asset metadata chains locally in their
client and (re)broadcast them to application-specific nostr relays, or
to general public relays depending on application needs. Maybe there's a
marketplace application that has its own relays and also broadcasts
asset metadata to relays used by popular gallery systems. Or maybe your
client just sends to any relay it sees that doesnt have the event. Big
design space there.

- rijndael

0: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer


On 2/2/23 4:15 AM, Anthony Towns via bitcoin-dev wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Purely off-chain coin colouring

[alicexbt]

Hi Anthony,

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

Whole point of inscriptions is to keep something on-chain associated with your sats so this approach goes against the concept and what makes them interesting in the first place.

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

All events may not be permanently stored by Nostr relays. In addition to rendering inscriptions meaningless, this creates a dependency.

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

If bitcoin transactions can be censored then we have bigger problems to care about as bitcoin will have no value without censorship resistance.

Lastly, I would add that inscriptions involve "financial" transactions, associating sats with image is freedom and got historical reasons for it. Writing something on paper or drawing an image on copper is not same as doing it on gold.

Disclaimer: My opinion on inscriptions can be biased because I am working on a startup that will use inscriptions and satscard(coinkite)


/dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, February 2nd, 2023 at 2:45 PM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Purely off-chain coin colouring

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 5072 bytes --]

On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
> Hi *,
> 
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:

<snip>

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

On the FAQ of the Ordinals website they discuss off-chain data storage and
reject the idea:

    "Some Ethereum NFT content is on-chain, but much is off-chain, and is stored on
    platforms like IPFS or Arweave, or on traditional, fully centralized web
    servers. Content on IPFS is not guaranteed to continue to be available, and
    some NFT content stored on IPFS has already been lost. Platforms like Arweave
    rely on weak economic assumptions, and will likely fail catastrophically when
    these economic assumptions are no longer met. Centralized web servers may
    disappear at any time."
    https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html

That same FAQ also mention RGB and Taro, which already implements an off-chain
data model based on my Proofmarshal work. The Ordinals community is well aware
of the trade-offs and have chosen to publish their data on chain. This is a
collectables market based on artificial scarcity after all, so some conspicuous
consumption isn't going to be a deterrent.

Frankly, I think further discussion of this on the bitcoin-dev mailing list,
with the aim of getting Ordinals and others to do something else, is a waste of
everyones' time. The fact that publishing data on chain lets you take
advantage of the very large network of archival Bitcoin nodes to publish and
store your data indefinitely is a clear benefit that people will always be
willing to pay for. The only realistic thing Bitcoin can do to discourage this
is tweaks to the blocksize and segwit discount, which of course has well-known
downsides.

There's a clear social/economic benefit to the Ordinals community that the
complete set of Ordinalds - and their inscriptions - is easy to extract and
will be available as long as Bitcoin block data itself will be available.
That's not going away and we should acknowledge that benefit honestly.

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

nostr doesn't even have a clear data persistence model. As you know, nostr
messages are passed around by relays that make no enforceable promise of
actually keeping those messages or making them available. nostr doesn't have
any kind of blockchain, making it diffcult for others to archive messages
completely.  Advocating for its use in a protocol designed to support valuable
collectables expected to be owned for a significant amount of time is reckless.

You know, we've been through all this before, years ago when colored coins were
first being discussed. Bitcoin Core devs who knew better would try to
discourage use of the Bitcoin chain for purposes they didn't approve of, by
suggesting solutions that they knew full well didn't really work. Solutions
like using OpenTimestamps inappropriately, alternative publication methods that
failed to provide the same level of security as Bitcoin, etc. It was dishonest
then, and it's disappointing to see a new generation of Bitcoin devs continue
this pattern of dishonesty.

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

The RGB protocol already does off-chain custody proofs, and implements NFTs.
You can already use this for real with Iris Wallet - the ownership chain of a
RGB asset is _not_ visible on the blockchain, as ownership does not follow
satoshis. With more work, digital assets can even be transferred with
O(log_2(n)) scaling allowing billions of transfers per second:

    https://petertodd.org/2017/scalable-single-use-seal-asset-transfer

This of course is irrelevant to Ordinals, which will never have such a large
market.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Purely off-chain coin colouring

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 7844 bytes --]

I am not an expert with RGB, but it looks limited (only bitcoin chains
from the github repo, apparently on hold), distributed over the
"lightning network" or LN nodes (what is it?), or Bifrost extension,
with a dubious token floating around, like ethereum mess as RGB docs
describe Ethereum (and myself also), layer2 or layer3, certainly not
decentralized (like still Bitcoin and Ethereum)

It's of course useless to trust IPFS or Bittorrent to store things
because you cannot control the seeders who have zero incentive to seed
such things

That's why in my much more simple proposals a well known third party is
there, wayback machine, github, twitter, etc, if they disappear then
probably internet has disappeared too, if they get censored you can
still get a snapshot of what you did

The intent is certainly not to store NFTs in Bitcoin, only hashes,
signatures and addresses, same for the third party proof, the NFT
content if not real is stored elsewhere (up to people to decide where)

Additionally you can store in the third party the proof that something
exists (the secret NFT), for example a small copy of the NFT electronic
art, the buyer will get the full version once the deal is done and once
he gets the decryption key, having the NFT for himself only

My proposals are not addressing wider D-stuff topics, supposedly
decentralized, but no

So I don't think that it's a waste of time to change the OP_RETURN max
size, currently it cannot even store <short message and/or hash> +
<signature>, probably it's logical to align it to the script size limit
(520B)

Or as I said previously deviant practices can happen, not expensive and
just burning satoshis, which is not a super idea

I don't get why on bitcoin all proposals must always be super
complicate, mine are simple, then take 5mn to read them


Le 02/02/2023 à 15:30, Peter Todd via bitcoin-dev a écrit :
> On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
>> Hi *,
>>
>> Casey Rodarmor's ordinals use the technique of tracking the identity of
>> individual satoshis throughout their lifetime:
> <snip>
>
>> 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.
> On the FAQ of the Ordinals website they discuss off-chain data storage and
> reject the idea:
>
>     "Some Ethereum NFT content is on-chain, but much is off-chain, and is stored on
>     platforms like IPFS or Arweave, or on traditional, fully centralized web
>     servers. Content on IPFS is not guaranteed to continue to be available, and
>     some NFT content stored on IPFS has already been lost. Platforms like Arweave
>     rely on weak economic assumptions, and will likely fail catastrophically when
>     these economic assumptions are no longer met. Centralized web servers may
>     disappear at any time."
>     https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html
>
> That same FAQ also mention RGB and Taro, which already implements an off-chain
> data model based on my Proofmarshal work. The Ordinals community is well aware
> of the trade-offs and have chosen to publish their data on chain. This is a
> collectables market based on artificial scarcity after all, so some conspicuous
> consumption isn't going to be a deterrent.
>
> Frankly, I think further discussion of this on the bitcoin-dev mailing list,
> with the aim of getting Ordinals and others to do something else, is a waste of
> everyones' time. The fact that publishing data on chain lets you take
> advantage of the very large network of archival Bitcoin nodes to publish and
> store your data indefinitely is a clear benefit that people will always be
> willing to pay for. The only realistic thing Bitcoin can do to discourage this
> is tweaks to the blocksize and segwit discount, which of course has well-known
> downsides.
>
> There's a clear social/economic benefit to the Ordinals community that the
> complete set of Ordinalds - and their inscriptions - is easy to extract and
> will be available as long as Bitcoin block data itself will be available.
> That's not going away and we should acknowledge that benefit honestly.
>
>> 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>
>>   }
> nostr doesn't even have a clear data persistence model. As you know, nostr
> messages are passed around by relays that make no enforceable promise of
> actually keeping those messages or making them available. nostr doesn't have
> any kind of blockchain, making it diffcult for others to archive messages
> completely.  Advocating for its use in a protocol designed to support valuable
> collectables expected to be owned for a significant amount of time is reckless.
>
> You know, we've been through all this before, years ago when colored coins were
> first being discussed. Bitcoin Core devs who knew better would try to
> discourage use of the Bitcoin chain for purposes they didn't approve of, by
> suggesting solutions that they knew full well didn't really work. Solutions
> like using OpenTimestamps inappropriately, alternative publication methods that
> failed to provide the same level of security as Bitcoin, etc. It was dishonest
> then, and it's disappointing to see a new generation of Bitcoin devs continue
> this pattern of dishonesty.
>
>> 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.
> The RGB protocol already does off-chain custody proofs, and implements NFTs.
> You can already use this for real with Iris Wallet - the ownership chain of a
> RGB asset is _not_ visible on the blockchain, as ownership does not follow
> satoshis. With more work, digital assets can even be transferred with
> O(log_2(n)) scaling allowing billions of transfers per second:
>
>     https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
> This of course is irrelevant to Ordinals, which will never have such a large
> market.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com


[-- Attachment #2: Type: text/html, Size: 10270 bytes --]

Re: [bitcoin-dev] Purely off-chain coin colouring

[vjudeu]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

> Sign-to-contract looks like:
 
Nice! I think it should be standardized as some informational BIP. This is a similar case as with Silent Payments: it is possible to let users make their own commitments as they please, but if it will be officially standardized, then it will be possible to build more protocols on top of that, in a way which will be understood properly by other nodes.
 
Before, I thought about interpreting signature R-value just as a Taproot-based public key, and forming a commitment as a valid input, that would allow moving coins on such address, but maybe we could standardize it in a simpler way than that. In general, if a commitment would allow pushing any data, it could be always extended when needed, because future commitments could be always nested in the old ones, 32 bytes is enough to do that.
 
Also, I thought about including OP_RETURN at the beginning of each commitment, to make sure it will be never pushed on-chain, but only stored and processed off-chain. Another thing is that r-value is always expressed as some 256-bit number, even in DER encoding, which means we can always assume 02 public key prefix in all commitments, and simply convert it directly into a proper Taproot address.

[-- Attachment #2: Type: text/html, Size: 1346 bytes --]

Re: [bitcoin-dev] Purely off-chain coin colouring

[Anthony Towns]

On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote:
> > 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.

Oh, you could also do inscriptions minimally on-chain. Rather than
posting the inscription on-chain per se, take a hash of the data you
want to inscribe, and then do a sign-to-contract commitment of that
hash.

That reduces your on-chain overhead for creating an inscription to
approximately zero (you're just signing a transaction), so can be much
cheaper, and also can't be blocked or front run by mempool observers. But
obviously means the inscription must be announced off-chain for anyone to
know about it. Of course, that could be seen as a benefit: you can now
have a private inscription, that's still transferable via the regular
ordinals protocol.

OTOH, there's no way to definitvely say "this tx is the Nth inscription
that matches pattern X", as there may be many earlier sign-to-contract
inscriptions that match that pattern that simply haven't been publicly
revealed yet. So that wouldn't be compatible with "inscription numbers"
or "first X inscripts count as minting token Y".

If you go one step further and allow the sign-to-contract to be the
merkle root of many inscriptions, then you've effectively reinvented
timestamping. (You can't outsource inscriptions to a timestamp server,
because you'd fail to own the ordinal that indicates "ownership" of
the inscription, however you could provide timestamping services as a
value-add while creating inscriptions)

Sign-to-contract looks like:

 * generate a secret random nonce r0
 * calculate the public version R0 = r0*G
 * calculate a derived nonce r = r0 + SHA256(R0, data), where "data"
   is what you want to commit to
 * generate your signature using public nonce R=r*G as usual

To be able to verify sign-to-contract, you reveal R0 and data, and the
verification is just checking that R=R0+SHA256(R0, data)*G. That works
with both ecdsa and schnorr signatures, so doesn't require any advance
preparation.

While it's not widely supported, sign-to-contract is a useful feature
in general for anti-exfil (eg, preventing a malicious hardware wallet
from leaking your secret key when signing txs).

Some references:

 https://www.reddit.com/r/Bitcoin/comments/d3lffo/technical_paytocontract_and_signtocontract/
 https://github.com/BlockstreamResearch/secp256k1-zkp/blob/d22774e248c703a191049b78f8d04f37d6fcfa05/include/secp256k1_ecdsa_s2c.h
 https://github.com/bitcoin-core/secp256k1/pull/1140
 https://wally.readthedocs.io/en/release_0.8.9/anti_exfil_protocol/
 https://github.com/opentimestamps/python-opentimestamps/pull/14

Cheers,
aj

Re: [bitcoin-dev] Purely off-chain coin colouring

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote:
> 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.

We certainly do want blockspace to be valuable, as transaction fees have to
both be in constant demand, and rise enough to replace the inflation subsidy if
Bitcoin is to remain secure in the future. In fact at the moment, the inflation
subsidy pays miners about 50x more than fees do. Ordinals and other publication
mechanisms are of course ways that we can drive consistent demand for block
space, keeping Bitcoin secure.

Are you arguing that we should change the inflation subsidy phase-out, eg by
introducing tail emission(1) or demurrage?

1) https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Purely off-chain coin colouring

[alicexbt]

Hi Anthony,

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

Moving transactions off-chain because of emotions or personal opinions does not make sense. 
Everyone running a bitcoin node is aware of block limits and they could be filled with different type of transactions including [non-inscription txs][0] that use witness for complex scripts.

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

[Ord explorer][1] is open source and gets inscriptions from blockchain.

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

Using pow doesn't make nostr relays "scarce". Its mainly used to avoid spam but some spammers on nostr have proved it isn't enough. 

> then in the off-chain world, they would look like two events:

Nostr relays do not guarantee that these events will be stored [forever][2].

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

Cost for running bitcoin node do not change with inscriptions and do not depend on the content or intent of any bitcoin transaction. It is a permissionless network and users can decide how to use money and blockspace.

Campaigns to censor such transactions or other efforts to move them off-chain are creating a slippery slope that could affect bitcoin more than some inscriptions. If Casey is harassed enough on social media and ord project moves inscriptions off-chain, there would be forks of it doing it on-chain.


[0]: https://twitter.com/mononautical/status/1621663167582437376
[1]: https://github.com/casey/ord
[2]: https://twitter.com/damusapp/status/1621431556048035841


dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, February 4th, 2023 at 4:08 PM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Purely off-chain coin colouring

[Aymeric Vitte]

I still don't see in both proposals how you avoid that someone steals
your NFT, double mint it or sell it several time, because the thief can
do the very same that what your are describing, a hash of the content is
not enough, you can slightly modify an image or a document and it gives
another hash, as far as I know in all existing systems today there are
zero protection against this, I am quoting also Moxie's experience in my
proposals

That's why I am proposing the third party with a timestamp and a double
hash not related to the content itself, and the secret NFT, I don't see
the point to buy millions some electronic art that everyone can get for free

Anyway, I mostly consider that a NFT is a real good that you buy in the
metaverse, not only an electronic thing


Le 04/02/2023 à 11:38, Anthony Towns via bitcoin-dev a écrit :
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com

Re: [bitcoin-dev] Purely off-chain coin colouring

[Anthony Towns]

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

Re: [bitcoin-dev] Purely off-chain coin colouring

[Casey Rodarmor]

[-- 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 --]