With Ordinals, a user who does not own an Ordinal cannot create a valid Bitcoin transaction to move an Ordinal that is not in their wallet. This is because the user must possess the UTXO that holds the "sat". Unlike Ordinals, Counterparty as a metaprotcol is entirely detached from Layer-1 consensus rules—this allows Counterparty to be much more versatile and extendable. However, Ordinals, given its large community, offers Counterparty asset owners the opportunity to benefit from greater liquidity and a larger ecosystem generally. For this it is necessary to be able to attach and detach Counterparty assets to/from UTXOs. This will allow Counterparty assets to be compliant with the Ordinals trading transactional structure, allowing the large players in the Ordinals ecosystem to seamlessly integrate with Counterparty assets.
Currently, Counterparty asset balances are stored in the database by address. A protocol change enable_balances_in_utxo will be added to the protocol_changes.json file. From this block, balances can also be stored by UTXO, that is to say in the form <tx_hash>:<n>.
The three types of sending, send, enhanced_send and mpma_send will be updated to accept this format for the source and destination parameters.
A send from an address to a UTXO is an attach and a send from a UTXO to an address is a detach and there will be fees associated with attach operations (see Gas System.)
In case a user does not have a UTXO or simply wants to use a new UTXO, it will be possible to use the destination=utxo parameter to attach the assets to the new UTXO created by the transaction itself.
Assets attached to UTXOs can therefore be sent to other UTXOs either with a vanilla BTC transaction, the destination being the first output of the transaction, or with a Counterparty transaction (send, enhanced_send or mpma_send).
The get_tx_info function will be updated to check if assets are attached to each input of all transactions. If so, the function will return the same as for a send transaction. The assets will be moved to the first non-OP_RETURN output of the transaction and the balances table will be updated, in a manner compatible with Runes.[1]
The documentation will be updated to indicate that source and destination parameters accept <tx_hash>:<n> format and that destination parameter also accepts the string utxo for send functions.
Balances will now contain an additional utxo field.
A utxo field will be added to the balances table. The address field will always be populated and the utxo field only if the balance is attached to a utxo. The format of the utxo field is <tx_hash>:<n>
I think this is great from a tooling perspective and will be very beneficial for counterparty.
Just a couple thoughts:
With regards to the gas system (i know its not talked about in specifics here, but has been discussed a bit in the chats) i think it may be necessary to have an additional field, wherein if the maximum XCP fee the user is willing to pay is set. With an exponentially increasing function that starts a 0, there is a reasonable likelyhood that from one difficulty period to another there will be large jumps. If a user is trying to attach a handful of assets to UTXOs and the BTC fee spikes, such that the txs are stuck in the mempool long enough for the utxo attach difficulty to adjust, its possible that a user could have thought they were going to spend 0.05 xcp per utxo attachment and instead pay 1xcp each.
What are your thoughts on the ability to also attach the issuance ownership to a UTXO? Or to issue an asset directly to a UTXO? I think in these case, it would require create_issuance to be updated as well. Its not overly important, but there are certainly use cases wherein direct issuance to a UTXO or sending the issuance ownership to a UTXO would be beneficial.