RGB scriptless atomic swaps

[fedsten]

Atomic swaps are a powerful tool to exchange assets without intermediaries and without counterparty risk in a blockchain or across blockchains. Atomic swaps typically require the two parties to fund HTLC outputs, from which the assets will be redeemed using a secret if the swap is successful, or using a timelock if the swap fails. In RGB, it is possible to have atomic swap without the need for any scripting mechanism, and without having to perform two rounds of transactions, achieving both efficiency and privacy benefits.

In an RGB swap, the two parties will create together a Bitcoin transaction spending as inputs their respecting colored UTXO containing the RGB assets, and having as outputs the two change addresses where both parties can send back the bitcoins contained in their UTXO (minus the network fee) and an output containing the commitment to both RGB state transitions, one for Alice to send her assets to Bob, and the other for Bob to send his assets to Alice.
N.B. the output used for the RGB state transition commitment can either be a dedicated OP_RETURN output as in the example below, or a Taproot output also used for the bitcoin change of one of the two parties.

The atomicity of the exchange is guaranteed by the fact that both RGB state transitions are committed to same Bitcoin transaction, so either both of them get finalised or both of them fail. Compared to traditional atomic swaps, with RGB there is the advantage that much less on-chain space is used, and a blockchain observer cannot distinguish the atomic swap from a generic Bitcoin transaction.

The same scheme can work also for swaps between RGB asset and bitcoin, with the only difference that only one RGB state transition will be committed in the Bitcoin transaction, and one of the Bitcoin outputs will be dedicated to send bitcoin to the party who is acquiring bitcoin in the swap.

[dr-orlovsky]

I think we should develop sort of interactive protocol for this, like BIP78. Also, the same scheme can be re-utilized for RGB payjoins, i.e there is no on-chain difference between RGB atomic swap and RGB payjoin

[dr-orlovsky]

Such protocol has to be made compatible with what we have in #122 and #126

[dr-orlovsky]

Important that RGB state transitions prepared by Bob and Alice are not shared and prepared/kept independently (even though commitment to them goes into the same bitcoin transaction output). I made this possible with the introduction of RGB state transition bundles in RGB Core v0.7 (if you remember I was saying they are really important for multi-party transactions). With bundling, Alice and Bob put assets into different inputs, the state transitions are kept separately and they will operate two different & independent consignments for it.

[fedsten]

I would expect the protocol to work as follow:

1. The two parties exchange information about the input and change outputs they expect to use.
2. One of the two parties construct the PSBT and shares it with the other.
3. Both parties create a consignment (including the change if needed) and share it with the other.
4. The parties ACK each other consignment.
5. One of the parties construct the commitment and signs the transaction.
6. The other party verify the consignment, signs the transaction and broadcast it.

[cryptoquick]

Makes sense.
A couple more questions:

• In step 1, are the outputs blinded?
• If I have other tokens on my UTXO, do I need to provide them in the consignment to my peer, thus revealing all my assets?

[fedsten]

• There was referring to normal Bitcoin outputs to send the change to, so no blinding there.
• I think it is enough to share the commitment to the consignment for the LNPBP4 tree that needs to be built, but probably for the correct positioning in the tree you still need to share the asset ID and keep confidential amount and outputs. @dr-orlovsky surely has a better understanding on how it could work.

[dr-orlovsky]

From what I see what @fedsten has described is overall correct.

One thing I can add here is regarding transition bundling. Since each of the peers own a dedicated input(s), which are not shared between peers, they do create two state transitions which commits to specific input in LNPBP-4 style of commitment, i.e. it can be proved that there is no double-spending (each input is spent only once in a separate state transition linked to that input). Thus, sharing state transitions between parties is not required and two histories of atomically swapped assets remain "unentangled" in case if both parties had multiple assets of the same time on the same inputs, additionaly to the assets swapped.

I will try to explain the later once more.
Let's see both Alice and Bob has assets A and B on each of their UTXOs. Alice want to swap A to Bobs B, but she already have some B on the same UTXO where the A resides. The same applies to Bob. Without transition bundling they would have to create a "blank state transition" for each of the unswapped asset on their input, and this transition will entangle A from Alice with A from Bob - and B from Bob with B from Alice. Bundling allows to avoid this entangling and remove at least one of interactive steps (so that the Fererico's explanation with it remains correct even for multiple assets on the Alice and Bob's inputs).

[cryptoquick]

Perfect, that's exactly what I was hoping for, thanks, @dr-orlovsky! This way, when swaps occur, all your other tokens aren't revealed to your peer, but you still must create your own blank state transitions.

[adambor]

Question that comes to mind with this approach is what happens if e.g. Alice produces a signature for her input, but Bob instead of producing his and creating a valid transaction just waits (maybe till an exchange rate is more favorable for him) and only after e.g. 1 day submits the transaction. This would put the first signer of the transaction in a tricky position where the other party can execute the swap at any time in the future (or till the input UTXO is spent). Is there some way we can make the transaction valid only if sent within e.g. 10 blocks, kinda like a reverse timelock?

[adambor]

I was thinking about this a bit more, the main issue is that this free option is pretty much infinitely-timed and we cannot put an expiry time (reverse timelock) directly into bitcoin script. But can we put this expiry time into RGB smart contract? The way I was thinking about it...

Party A wishes to sell token A.
Party B wishes to buy token A for token B.
Create 2 state transitions such that:

1. Transfer token A from party A to:

if transaction blockheight <= expiry then:
    transfer to UTXO controlled by party B
else:
    transfer to UTXO controlled by party A

2. Transfer token B from party B to:

if transaction blockheight <= expiry then:
    transfer to UTXO controlled by party A
else:
    transfer to UTXO controlled by party B

This way both state transitions only execute when transaction is confirmed before it's set expiry, otherwise each party keeps their tokens. Question is if it is possible to have the outputs of the state transition dynamically defined by the RGB smart contract.

[fedsten]

Why do you need reverse timelocks? Normal ones can do the job equally well. You can set up a timelock that allows the party not holding the option to take back his assets after a certain amount of time that under normal conditions should be enough to execute the swap. In this way, if your counterparty keep holding the option indefinitely, as soon as the timelock expires you can cancel the trade by spending from the timelock.

[adambor]

Where would you put that timelock? In the output of the swap? Because this would then require 2 transactions per successful swap (swap tx + sweep tx) and would also need to include OP_CSV for option claimer's branch, as to give option offerer enough time to act and refund the transaction in case it's confirmed after expiry. So the option claimer will have to wait some time (a day?) till he can actually use the funds from the swap.

[dr-orlovsky]

While it is possible to add encumbrances in RGB on top of Bitcoin script requirements (leading to the loss of the state - or its automatic transfer to some default target in a case that the underlying bitcoin transaction doesn't satisfy some conditions) - I agree with @fedsten that there is no reason of doing that in our case (and RGB scripting must only be used when something is impossible with Bitcoin script).

Because this would then require 2 transactions per successful swap (swap tx + sweep tx) and would also need to include OP_CSV for option claimer's branch, as to give option offerer enough time to act and refund the transaction in case it's confirmed after expiry. So the option claimer will have to wait some time (a day?) till he can actually use the funds from the swap.

The atomicity of the exchange doesn't come from an HTLC (like in a case of atomic bitcoin swaps) but from the fact that both state transitions are committed to by the same bitcoin tx. Thus, Alice and Bob change outputs are simple key-bound outputs (or any other form of output Alice and Bob prefer for themselves). There is no way how Bob can prevent Alice from using her funds - or Alice can prevent Bob from using his funds; they can do it wherever they want and no timelocks (reversed, direct) or hashes are required at all.

[dr-orlovsky]

@fedsten there is no reverse option in this setup at all - see my comment above.

[adambor]

I am not sure if this is obvious from this description, but with tapret commitments this can be made non-interactive for RGB -> BTC swaps (this might useful for NFT/UDA sale listings).

Seller A of an RGB asset, can create 1-in (utxo with rgb asset) & 1-out (output to the seller with tapret commitment) transaction, which is unspendable by itself (spends more BTC on the output that it receives on the input), and contains a tapret1st commitment sending his RGB asset to ~:1 (2nd output of the witness transaction - which is yet undefined in the transaction). Seller signs that transaction with SIGHASH_SINGLE|ANYONECANPAY and publishes this pre-signed transaction along with the consignment.

Buyer B takes the pre-signed transaction, verifies the consignment. He then adds another input to the transaction making the transaction valid now (enough BTC on the input), and also adds another output for him to receive the RGB asset to (remember the RGB asset is sent to ~:1), he signs the whole transaction with SIGHASH_ALL and publishes it concluding the swap.

[adambor]

One can also implement dutch auction with this, using a set of pre-signed transactions with decreasing price and increasing locktime.