PSBT Support via attaching assets to UTXOs

[DerpHerpenstein]

    CIP: XXX
    Title: PSBT Support via attaching assets to UTXOs
    Author: Derp Herpenstein
    Discussions-To: ??
    Status: Draft
    Type: ??
    Created: 2024-1-26

Definitions

• PSBT - Partially signed bitcoin transaction
• UTXO - Unspent Transaction Output
• UI/UX - User Interface / User Experience
• API - Application Programming Interface

Abstract

This CIP is intended to add new functionality to the Counterparty send function that allows assets to be bound to and unbound from UTXOs. This functionality will allow for interoperability of counterparty assets in the ordinals ecosystem.

Rationale

Counterparty is unnecessarily cumbersome for newcomers. The UI/UX challenges with BTCPay make trading difficult in a high fee environment. Additionally, dispensers rely on buyers to trust that the seller wont front run their transaction. The ordinals ecosystem has shown that simple deterministic methods are needed to lower the onboarding friction of new users. Additionally, modern Bitcoin web based wallets are largely used as part of this onboarding process. These browser based wallets rely on PSBTs with single transaction finality for the trading of ordinals, and as such, the ability to sign a PSBT and create a deterministic swap of an ordinal for BTC is simple and straight forward.

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 there is one large drawback. It is possible for a user to create a valid layer 1 bitcoin transaction to do any number of things that will not be valid on counterparty. The transaction can be created and mined, and still rejected as an invalid transaction by counterparty (think of dispensers being front run). The solution to this problem is to create a mechanism for using layer 1 consensus rules with counterparty assets.

In order to do that, the asset needs to be attached to a UTXO. A system that allows for attaching assets to UTXOs allows for single transaction finality in trades between counterparty assets and BTC. This also allows counterparty assets to be compliant with the ordinals trading transactional structure, allowing the large players in the ordinals ecosystem to seamlessly integrate counterparty assets.

Limitations

Current PSBT trading utilizes an intermediary to hold your signed PSBT and find another party to finalize the trade. Although the intermediary cannot steal any assets, signed PSBT based transactions can be executed as long as the UTXO used in the PSBT exists. If users are utilizing PSBTs to trade assets and they want to cancel an order, the UTXO must be spent to ensure that a user cannot execute the PSBT. So creating a DEX without a third party would be possible by embedding the PSBT as part of opreturn data (or in the witness), but all operations (listing, remove listing, and trading) would require an on chain transaction transaction.

Implementation

NOTE: I need some help from those familiar with the specifics of the send function and db to add more detailed information here
An update to the send function to allow assets to be attached to a UTXO will be implemented. The send/multisend function will deduct an asset or assets from the users wallet and attach it to the first output of the transaction. The transaction structure will be as follows:

Inputs	Outputs
<user_payment_utxo>	<asset_utxo> (user_address, dust)
	<send_to_utxo_opreturn>
	<user_change_utxo>

In the database, this UTXO will be treated as its own account, and txHash_utxoNumber can be used instead of a users wallet address. (This allows for an arbitrary number of assets to be attached to a single UTXO to perform more complex transactions)
Do we need a new table with the tx_hash, assets, and spent to make looking this up easier?

The counterparty node will need to check every transaction hash in every bitcoin transaction in each block against the list of UTXOs holding assets to see if the asset has been moved. When a UTXO containing assets is spent, all assets in that UTXO are transferred to the first output of that transaction

Using the structure of considering a UTXO to be an account of its own, it is possible for a user to combine multiple assets into a single UTXO. (including ones holding other cp assets and ordinals)

Inputs	Outputs
<asset_utxo> (dust)	<new_asset_utxo> (user_address, dust)
<user_payment_utxo>	<send_to_utxo_opreturn>
	<user_change_utxo>

When the asset is attached to a UTXO and it moves to the first output, it's movement from wallet to wallet is functionally identical to an ordinal and in this state will be easily integrated into all current ordinals infrastructure.

Since Counterparty assets used in this way aren't permanently tied a sat, but optionally bound and unbound, when it comes time to move an asset out of a UTXO and back into a users wallet, the updated send function will be used. It will take the asset containing UTXO and user payments as input. Outputs will include the function to move the asset from the UTXO to the users wallet and the users change output.

Inputs	Outputs
<asset_utxo>	<send_to_wallet_opreturn>
<user_payment_utxo>	<user_change_utxo>

Direct trades between Counterparty and Ordinals

It may be possible to do this in a single PSBT maintaining assets tied to UTXOs, but im not a sighash expert, if you have a good way to do this please add it in the comments.

API TX Generation

In order to easily facilitate adoption, the counterparty API will be updated such that it can generate the transactions needed to easily facilitate trading.

- Generate a Sell PSBT

When a user desires to put an asset up for sale, they will need to generate a transaction that contains an input containing the UTXO holding the asset, and a payment output to their desired address with the value in BTC required to complete the trade.

The API will generate a SELL transaction in the following format:

Inputs	Outputs
<counterparty_utxo> SINGLE (ANYONECANPAY)	<payment_utxo> (seller_address)

In most situations, the user will sign this transaction and provide it to a website that will find another user to finalize the sale.

- Generate a Buy PSBT

When a user desires to buy an asset that is up for sale, the will need to generate a transaction that contains the sale PSBT, and add to that an input with value greater than the payment_utxo amount, an output that the asset will be moved into, and an output for their change.

The API will take as an input the PSBT from Generate a Sell PSBT and using the buyers UTXOs generate a BUY transaction in the following format:

Inputs	Outputs
<asset_utxo> SINGLE (ANYONECANPAY)	<new_asset_utxo> (buyer_address)
<buyer_payment_utxo>	<payment_utxo> (seller_address)
	<buyer_change_utxo> (buyer_address)

- PSBT for all other transactions

To maximize interoperability with the ordinals infrastructure, it is necessary to allow all counterparty transactions to be generated as PSBTs. In counterparty-lib in the file lib/transactions.py an additional function called constructPsbt will be created. It will take the same parameters as the construct function. This function will call construct and with the result it will use the bitcoin backend to call the function converttopsbt to generate the hex. Then as a safety measure, the psbt will be deconstructed to verify the parameters match those expected before returning the psbt.

Copyright

This document is placed in the public domain.

[keyuno]

Counterparty is unnecessarily cumbersome for newcomers. The UI/UX challenges with BTCPay make trading difficult in a high fee environment. Additionally, dispensers rely on buyers to trust that the seller wont front run their transaction.

We can employ Atomic Swaps to conduct trades without the need for trust. In this implementation of Atomic Swaps, we utilize the Partially Signed Bitcoin Transaction. We have the potential to expand it to include Lightning Network implementation, aiming to minimize friction.

This also allows counterparty assets to be compliant with the ordinals trading transactional structure, allowing the large players in the ordinals ecosystem to seamlessly integrate counterparty assets.

What is the main purpose of this proposal? Does it seek to align Counterparty with a rival protocol, possibly granting it legitimacy? Considering Counterparty's substantial historical presence in the crypto space and its pioneering role in the NFT/cryptocurrency movement, Counterparty stands as a protocol that others should align with.

It's important to avoid engaging with proponents of false narratives and individuals who have exhibited hostility towards Counterparty and XCP.

[DerpHerpenstein]

Hey @keyuno thank you for the response.

We can employ Atomic Swaps to conduct trades without the need for trust. In this implementation of Atomic Swaps, we utilize the Partially Signed Bitcoin Transaction. We have the potential to expand it to include Lightning Network implementation, aiming to minimize friction.

It is my understanding that atomic swaps like this require 2 tx per user (4 total on chain txs) and if either user doesn't finalize the transaction in the predefined timeframe it is possible for one party to claim both assets. I am of the opinion that accomplishing deterministic trades in a single transaction is an important part of lowering friction and complexity for the users. Additionally, the PSBT based structure outlined above also allows for an on chain DEX that doesn't require knowing your counterparty to list an item and allows for the completion a deterministic trade in two transactions instead of 4.

What is the main purpose of this proposal? Does it seek to align Counterparty with a rival protocol, possibly granting it legitimacy? Considering Counterparty's substantial historical presence in the crypto space and its pioneering role in the NFT/cryptocurrency movement, Counterparty stands as a protocol that others should align with.

The purpose of this proposal is to allow Counterparty to utilize the massive amount of infrastructure that has been built by the ordinals ecosystem and increase the Counterparty user base by onboarding those users with the tools they are familiar with.

[keyuno]

It is my understanding that atomic swaps like this require 2 tx per user (4 total on chain txs) and if either user doesn't finalize the transaction in the predefined timeframe it is possible for one party to claim both assets. I am of the opinion that accomplishing deterministic trades in a single transaction is an important part of lowering friction and complexity for the users. Additionally, the PSBT based structure outlined above also allows for an on chain DEX that doesn't require knowing your counterparty to list an item and allows for the completion a deterministic trade in two transactions instead of 4.

I understand the concern about the potential complexity with the outlined atomic swaps, requiring multiple transactions and a predefined timeframe for finalization. It's essential to note that the implementation was designed as a proof-of-concept for trustless rule-based exchanges with timelocks, ensuring that both parties have the proper incentives to comply with the specified rules.

As noted, by expanding the capabilities of atomic swaps and introducing Counterparty-aware lightning nodes, there is a possibility to substantially decrease transaction complexity while upholding a trustless environment.

user base by onboarding those users with the tools they are familiar with.

The leaders and advocates of that project have openly displayed hostility towards XCP, attempting to assert themselves as pioneers of Bitcoin NFTs. It is advisable to distance ourselves from their protocol, given the consistent spread of falsehoods and hostility towards Counterparty by both their promoters and leaders.

I believe the on-chain meme is founded on a misunderstanding of the true essence of NFTs, and whether this misunderstanding is unintentional or driven by ill intentions remains to be determined.

Their project adds confusion to the space and attracts speculators and imitators, lacking a substantial narrative or historical relevance. The perceived hype depends on artificial growth and venture capital funding, which is likely to diminish over time. In summary, there is no need for us to lend legitimacy to their project.

[adamkrellenstein]

Clever and elegant. I love this. ❤️

[Jpja]

I am of the opinion that accomplishing deterministic trades in a single transaction is an important part of lowering friction and complexity for the users.

100% agree, this will truly benefit Counterparty!

We need to be careful with the implementation though.

If the UTXO is treated as an address format:

• PRO: easy to add UTXO as recipient in enhanced send. Simply define a new prefix for "UTXO address".
• CON: spending (and any other Counterparty action) from UTXO will be ambiguous. Counterparty looks at first input to determine spender's address. Is it the UTXO or the address that makes the spend? Will need a deeper change to define this.
• CON: spam concern. If every time a UTXO is moved, all balances are swept to the new UTXO, how will the DB handle this?
• CON: increased parsing time to "check every transaction hash in every bitcoin transaction in each block against the list of UTXOs holding assets" ?

Maybe better introduce a separate message type only for this? Call it "UTXO Wrapper".

• wrap token(s) to a UTXO; the underlying address must have no Counterparty history and won't be allowed to perform any Counterparty actions.
• unwrap the UTXO by spending it with a CNTRPRTY message that transfers the token(s) to a new address (for a PSBT trade).
• allow origin address to claim back token(s) from invalid UTXO (a safety feature in case UTXO was accidentally spent).

[adamkrellenstein]

Current PSBT trading utilizes an intermediary to hold your signed PSBT and find another party to finalize the trade. Although the intermediary cannot steal any assets, signed PSBT based transactions can be executed as long as the UTXO used in the PSBT exists. If users are utilizing PSBTs to trade assets and they want to cancel an order, the UTXO must be spent to ensure that a user cannot execute the PSBT. So creating a DEX without a third party would be possible by embedding the PSBT as part of opreturn data (or in the witness), but all operations (listing, remove listing, and trading) would require an on chain transaction transaction.

Am I reading that right, or does Ordinals require a third-party to hold the data in a way that Counterparty wouldn't?

Couldn't Ordinals do the same thing with an inscription?

[DerpHerpenstein]

Yes they absolutely could. I would imagine there are a couple reason why this is not happening. First i think the exchanges like to hold the PSBTs so that they have control over the sale and ensure it happens on their platform. The second is that when a custodian holds your signed transaction instead of putting it on chain, you can list and cancel with no BTC transactions. The obvious downside is that your PSBT is still floating around, so unless you move the UTXO holding the asset, if someone gets ahold of that PSBT they can buy your asset for the price you originally listed it for. A few years ago there was a hack of OpenSea where something similar happened in ethereum and a user was able to buy quite a few high value assets for a fraction of their price.

[adamkrellenstein]

wow 😳

[ouziel-slama]

I really like the idea! I think there are 3 very distinct and independent subjects here, each of which deserves particular attention.

1. Atomic Swap
2. PSBT
3. Use UTXOs for asset ownership

We can decide to implement atomic swap without 2 and 3 in the same way that we can decide to implement UTXOs for asset ownership without atomic swap and/or PSBT.

For atomic swap what is needed is a transaction signed by the buyer and the seller. For example:

Inputs:

• Seller dust
• Buyer payment 1
• Buyer payment 2
  …

Outputs:

• Counterparty data
• Seller payment
• Buyer change

Once Counterparty supports this type of transaction we could stop there and leave it to the wallet developer to set up a process (centralized or not) to generate this type of transaction, for example using PSBT.

Then we can decide to integrate PSBT into the Counterparty protocol but this normally involves including a raw transaction in the data of another transaction. We must carry out tests beforehand to know what is the minimum size of the data that we must store on-chain and if this is possible/reasonable.

For the third point (attaching assets to UTXOs) I am not convinced that the game is worth the effort. It seems to me that the discussion already took place about ten years ago but at the time it was called Colored Coins. The only advantage I see is being compatible with Ordinals. This seems to me to be more of a political discussion than a technical one.

[DerpHerpenstein]

Hey Ouizel,

Currently, its not particularly difficult to create the tx you are describing using tools like bitcoin-js. However, If the atomic swap in your example is performed in a single transaction, there is nothing to stop the seller from monitoring the mempool, watching for this transaction and executing a transaction to move the asset at a higher miner fee. The outcome being that the tx mined first is a valid counterparty tx and the one mined second with the BTC payment is invalid (but both are valid BTC transactions), so the malicious seller keeps their asset and received the BTC as well.

This type of transaction will have the same trust problem that dispensers have because with the current counterparty transaction structure, any such deterministic transfer that utilizes BTC will require at minimum two and in practice 3 transactions(BTCPay)

In order to execute a deterministic swap in a single transaction and mitigate against a malicious counterparty, bitcoin must somehow be made aware of the existence of the counterparty data, such that the rules for valid transactions on layer one can be used to enforce data validity on counterparty

[ouziel-slama]

@DerpHerpenstein thank you for these clarifications! you're right I take back what I said :)
I re-re-read your proposal again and ultimately what bothers me the most is:
"The counterparty node will need to check every transaction hash in every bitcoin transaction in each block against the list of UTXOs holding assets to see if the asset has been moved."
By design (broken by the "dispensers") a Counterparty transaction is recognized without needing to make a query in the database. By not respecting this principle it becomes impossible to parallelize the first step of the parsing (i.e. recognizing a Counterparty tx). If we decide that it is worth it for a real atomic swap it will probably be necessary to directly store the UTXO balances in a key/value type database (leveldb or rocksdb for example).

[DerpHerpenstein]

It certainly would require more processing. Ultimately the upper limit right now is ~4k transactions in a block, which should be do-able. If rocksdb is going to be used to replace addrindexers perhaps its a good fit? Some benchmarking on modest hardware to determine the overhead would be needed. It's worth noting that other metaprotocols currently use this transactional structure at scale.

Another option would be to go the route proposed by JP.
#134 (comment)

In his proposed configuration, each asset movement could be accompanied with a counterparty opreturn signifying the transfer to ensure tx's maintain the current structure.

I prefer the direct utxo binding, but both structures would allow for deterministic swaps in a single transaction.

[adamkrellenstein]

yeah it'll be heavy, but I think we can do it. (FYI, currently working on using SQLite for the address index data as well; should be performant enough)

[blocklack]

Currently atomic swaps can be done with low probability of frontrunning, one of them is to make sure that the parties exchanging the assets have only one utxo to spend, the only attack vector is to use the CPFP, but that can also be solved using CLTV.... of course this requires dapps to implement stricter measures in the Swap using PSBT......

[blocklack]

https://docs.counterparty.io/docs/advanced/how-to/atomic-swap/