A thought experiment: how to design cross-chain atomic swaps from scratch (discussion with @gdsoumya)

gistfile1.txt

for atomic swaps, as you stated in your proposal, the basic primitive is a hash time-lock contract (or those four words in a similar order :)
I don't know the exact details, but if I were to make it up from scratch, it would go something like this (a double-escrow)
most blockchains support a multisig address, one where two or more signatures are needed to spend funds, or some other secret / hash is needed which is not known beforehand but can be verified
party A and party B both have keypairs for blockchain A and blockchain B (there are 4 keypairs involved)
furthermore, most of those blockchains also support a "limited time only" feature where a temporary multisig can only be spent before a certain block number
party A on blockchain A locks up some funds in a temporary multisig, valid for time_A blocks, where the other authorization to spend is something like party B's blockchain A signature of a multisig tx on blockchain B
likewise party B on blockchain B locks up some funds in a temporary multisig, valid for time_B blocks, and the other authorization to spend is party A's blockchain B signature of a multisig tx on blockchain A
when party A and B coordinate offchain and have each locked up the agreed amount on their respective chains, each one signs the multisig tx hash on their own chain with their key on the other chain and passes it to the other party
each party verifies on the other chain that the multisig tx is valid, then they authorize the multisig spend on their own chain (party A verifies multisig on blockchain B before releasing the funds on blockchain A, etc.)
otherwise, if either party can't verify the other's signature / successful multisig cross-signing, they release their funds and the atomic swap is cancelled.
This is probably not exactly how traditional atomic swaps happen, but I just made it up in 10 minutes just now after remembering vaguely what I read two years ago.
But "spiritually" something like this is how it works. A problem with my protocol is that one party could just forget the last step. So something unstoppable must be put in place so that either party can drive the swap forward

So if you have some extra time and enjoy it, you might try to make up your own protocol as well, knowing what you know of ETH and XTZ contract operations :)


Paul Pham @cryptogoth Aug 06 08:44
Okay, sorry for that long explanation.

Liquidity is an amount of ETH and XTZ, on their respective blockchains, that is locked up in a contract and made available for swapping.

On Uniswap, you can lock up both halves of a trading pair, like ETH and any ERC20 token, into a pool.
Anyone who wants to convert between that pair deposits one token, and withdraws the other, and pays a 0.3% fee that is divided up between all liquidity providers.

You get a pool token back, which generally goes up in value over time b/c it represents the underlying asset compounded with 0.3% trading fees all the time,
and you can trade the pool tokens to someone else, or redeem it to get your share of the underlying assets back.

Liquidity are funds that other people are "renting" or "loaning" on both blockchains, where they are willing to accept blockchain A funds in exchange for blockchain B funds.
In your case, party A wants to be matched with any party B, not a particular person beforehand that they know,
so you probably want to allow people in general the chance to stake, if they have both A and B funds
These are "liquidity providers" (LPs) or pool participants

And the protocol automatically matches you up with a pool, it is sometimes called an "automatic market maker" or AMM,
whereas you as the person who wants to make the swap is called the "taker"