WAIT STOP I HAVE AN IDEA

[moneroshill]

before you spam outputs on monero by implementing the transfer of inscriptions, why not just implement it on a sidechain instead:

When you want to "send" an inscription, you just do a normal, unrelated transaction. You attach a tx_extra which contains the hash of a signed transaction of the mordinal off-chain. The mordinals version of monerod can share the copies of these signed transactions separately from the other monerod clients.

This basically solves your problem as long as tx_extra is large enough to contain a single hash, and it doesn't piss monero users off by creating blackball transactions.

[mooonero]

@moneroshill Thank you for your comment. Could you please clarify how this solves the problem? Even if the output is spent in a sidechain, it still becomes part of the deanonymized subset and should not be used in mixins, which is a problem in itself. Additionally, signing something with a one-time transaction key does not provide a proper transfer of ownership to another wallet.

[moneroshill]

After some further thinking about it, and due to discussions with other users on IRC, I agree that my proposed solution isn't really complete.

The problem is fundamentally that ordinals require you to make your ownership public. And if the ownership is public, then other users can't use it as a decoy.

Secondly, a hash is insufficient for a sidechain because a sender can delay sending the hashed data to the rest of the sidechain, which creates problems for sidechains trying to keep track of ownership. Basically, the ownership REALLY has to be public, it can't be inside some hash or encrypted thing that is revealed at a later date because any recipient will need to know that the ordinal hasn't spent before.

One part of the solution must be to create a flag for other payments to ignore it in decoy selection (perhaps in tx_extra, I guess this is just what you suggested). That would only need to be 1 bit. Another part of the solution might simply be putting the whole transaction proof in tx_extra, so it's publicly visible to any future recipients. I suppose the sender could also attach additional metadata to the tx_extra if they wanted "e.g. Bob owned this NFT" (this part could be hashed and stored in a sidechain I guess, depending on the size of the metadata).

Monero users will not be too happy about this because it basically is implementing optional privacy through soft fork, but I don't see any other way you could go about doing this. Maybe a more general solution is just a sidechain to monerod that allows users to share any valid txproofs they find that are associated with on-chain transactions, and add that to a blackball list? That wouldn't be sufficient for ordinals. I guess there is nothing stopping you from posting your view keys and tx proofs publicly online (and this isn't fundamentally different than that), but monero users just don't want to normalize that use case.

Some IRC users mentioned a cohort solution to me, but I forget the specifics of what they said, and I can't seem to find information about it online, I suppose it has to do with cohort analysis? I am wondering if you know anything about that. But the general gist of it was that that the ordinal transactions were labeled so other users don't have them as mixins.

Anyways, my advice is to wait before on implementing transfers. It depends a lot on how monero developers/users choose to react. If they're willing to soft fork the wallet to ignore ordinals in decoy selection, then the solution is straightforwards.

On an unrelated note, do you have any ideas on the 1060 tx_extra limit that got merged? I think it's a soft fork. My intuition is to suggest using IPFS links instead (perhaps with some sort of signature?), but part of me is interested in what kinds of pixel/ascii art/poems that users will create that is less than a kilobyte.

[mooonero]

Thank you for providing such a detailed comment! With regard to excluding inscription-related outputs in mixins, there is no need to add any additional information to the transaction. All necessary information is already present: any transaction that contains the extra field tx_extra_ordinal_register, tx_extra_ordinal_update, or tx_extra_ordinal_register_multibody (identified by TX_EXTRA_TAG_ORDINALS_REGISTER, TX_EXTRA_TAG_ORDINALS_UPDATE, TX_EXTRA_TAG_ORDINALS_REGISTER_MULTIBODY) will have an output with index 0 that is associated with the inscription, and should not be utilized for mixins. This output would be spent in the future with a hard-coded decoy set like in this transaction: https://xmrchain.net/search?value=e47194e0c45f9d0da7f5b28c798873d01960902e98f0e0f6640c10d171d4b526

So basically, all that the Monero developers need to do is to exclude those specific outputs in the mixin selection algorithm. We would be willing to assist with a pull request if they require our help.