Monero-Tari Atomic Swap RFC

Hot on the heels of the Bitcoin-Tari Atomic Swap
proposing two methods to perform
Monero-Tari Atomic swaps. These atomic swaps are significantly more complex than a Bitcoin atomic swap because Monero
does not include any scripting features or appropriate time-locks. This means that the majority of the complexity of the atomic swap needs
to be done on the alternate chain that is being swapped with Monero.
The RFC proposes two methods; the first is inspired by the approach taken by the
Farcaster project
Comit network
is very similar but uses a slightly different approach to the signatures.
goes into great detail. In short, let’s assume that Alice wants to send Bob some Tari in exchange for Monero.
Alice and Bob will collaborate to produce several transactions that contain aggregate keys and adaptor signatures
that become valid at a staggered timeline of lock heights. The parties will then publish the transactions in an
order that ensures both parties funds are safe at all times.
The gist is that Alice and Bob collaborate to produce a Monero transaction locking up Bob’s XMR that is spendable by an aggregate key.
Alice and Bob both have a secret portion of this key, and the Monero transaction can only be spent once one party has both
parts of the aggregate key. This will be revealed when claiming the transactions that will be placed on the Tari chain.
The Tari transaction is constructed and published first because it has multiple modes of refunding.
Alice and Bob collaborate to produce a Tari transaction that locks up Alice’s portion of the swap that can be spent by
different script keys. If any of these keys are used to spend the output, information about the Monero aggregate key is revealed, allowing the correct party to claim the Monero. Usually, it allows Alice to claim the Monero once Bob claims the Tari, but there are contingencies for Bob refunding his Monero after some expiry period.
The following is the TariScript that defines how the script keys can be used to spend Alice’s portion of the swap.
CheckHeight(height_1)
LtZero
IFTHEN
CheckHeight(height_2)
LtZero
IFTHEN
This script says that before
, the output can be spent if you can provide a signature for
Bob’s portion of the Monero key allowing Alice to claim the XMR.
is an aggregate key with a part that Alice needs
to provide to Bob before he can claim it; she will provide this portion of the key when she sees Bob has published the
Monero transaction. After
, if Bob has not claimed the XTR then Alice has an opportunity
to claim a refund of her XTR via
. Doing this will reveal Alice’s portion of the Monero key, allowing Bob to reclaim
his XMR. If Alice does not claim her refund before
then Bob is able to claim the XTR via
This, however, reveals Bob’s portion of the Monero key so that Alice now has the information required to claim the XMR when
she eventually comes back online.
Once all of the aggregate keys have been constructed by the two parties, Alice will publish the Tari transaction, knowing that
if Bob does not publish the Monero transaction she will be able to reclaim her funds after the time lock expires. Bob cannot
claim the XTR transaction yet because Alice still needs to provide him with her portion of
. Bob now knows that he can
safely publish the Monero transaction because either Alice will give him her portion of
or else she will reclaim
, which will reveal her portion of the Monero key so that he can reclaim his XMR. Otherwise, enough time will pass
that he can claim the XTR using
. Once he has published the Monero transaction, Alice will give him her portion of
Bob can then claim his XTR revealing his portion of the Monero key, and then Alice can claim her XMR.
This approach to the problem requires a very complex initial negotiation between the parties. This negotiation will consist
of many rounds of communication. In the
, a variation on this approach is proposed that does not use adaptor signatures.
In theory, this will reduce the number of initial communication rounds significantly. However, this approach still needs to
be reviewed. We invite the community to check out the
and welcome any input on the design of these protocols.