3 party "ABC swaps"

[Alrighttt]

I would like some peer review on this. I call this an "ABC swap". The basic premise is a three party atomic swap implemented via bitcoin script. There is a good chance there is a fatal flaw in the logic, so please do not get overly excited. I am asking you to please find flaws in it.

assuming market conditions of roughly 2 TOKEN == 1 KMD == 10 COIN

• bob places a limit order - selling his 10 COIN for 1 KMD

• alice announces she wants to trade her TOKEN for COIN ( via TOKEN -> KMD -> COIN assuming there is no direct TOKEN/COIN volume)

• charlie replies to alice(CCing bob) "I will statify bob's order of 10 COIN for you if you give me 2.5 TOKEN"

• Alice agrees to pay 2.5 TOKEN for 10 COIN or we stop here.

• Now we initiate a swap in which....

Alice ends up with COIN(success) or TOKEN(swap failed) Bob ends up with KMD(success) or COIN(swap failed) Charlie ends up with TOKEN(success) or KMD(swap failed)

• Charlie charges a premium of 0.5 TOKEN(in which alice will pay).

Now in order for this to work, we must hold some assertions

    Bob should be indifferent as to whether he directly trades with alice or trades with alice and charlie. There should be no additional risk to bob. 

    If alice does pay this premium, the swap must have been succesful for her. She receives 10 COIN.

    If bob negoiates and then fails to proceed, alice claims back her TOKEN. 

    Charlie could choose how much he will profit based on how likely he thinks both swaps will succeed and how likely alice will accept his offer. He can set his risk profile.

If we have competing charlies, this profit(and therefore alice slippage) gets thinner and thinner.

Now instead of bobs providing volume on a dozen different pairs(ex: DOGE/BTC DOGE/KMD DOGE/BCH DOGE/LTC DOGE/ETH DOGE/DASH), they only really need to provide it on DOGE/KMD. This should narrow the spreads on KMD pairs as something like a DOGE/DASH trade will actually be providing volume on a KMD pair, KMD/DASH.

Like I said, I am asking for peer review on the following script. It could be that it needs a redesign, but I am confident this concept of an "ABC swap" is in fact possible.

alice   COIN -> TOKEN
bob     TOKEN -> KMD
charlie KMD -> COIN

charlie creates secret1 and shares Hash160(secret1) with both parties

bob creates secret2 and shares Hash160(secret2) with both parties

Alice sends COIN to charlie with stipulation that secret2 must be known to spend and secret1 must be revealed
OP_IF <locktime*3> OP_CHECKLOCKTIMEVERIFY
        OP_DROP <alice pubkey> OP_CHECKSIG
OP_ELSE
        OP_SIZE 20 OP_EQUALVERIFY OP_HASH160 <secret hash> OP_EQUALVERIFY <secret hash2> OP_HASH160 <secret hash2> OP_EQUALVERIFY <charlie pubkey> OP_CHECKSIG
OP_ENDIF

bob sends TOKEN to alice with stipulation that she must know secret1 and secret2 to spend
OP_IF <locktime*2> OP_CHECKLOCKTIMEVERIFY
        OP_DROP <bob pubkey> OP_CHECKSIG
OP_ELSE
        OP_SIZE 20 OP_EQUALVERIFY OP_HASH160 <secret hash> OP_EQUALVERIFY OP_HASH160 <secret hash2> OP_EQUALVERIFY <alice pubkey> OP_CHECKSIG
OP_ENDIF

charlie sends KMD to bob with stipulation that he must reveal secret2 to spend
OP_IF <locktime*1> OP_CHECKLOCKTIMEVERIFY
        OP_DROP <charlie pubkey> OP_CHECKSIG
OP_ELSE
        OP_SIZE 20 OP_EQUALVERIFY OP_HASH160 <secret hash2> OP_EQUALVERIFY <bob pubkey> OP_CHECKSIG
OP_ENDIF

bob reveals secret2 and receives KMD

charlie uses secret2 and reveals secret1 to receive his COIN

alice uses secret2 and secret1 to receive her TOKEN

If the swap fails(bob goes offline) after alice locks her COIN into p2sh, she will claim back her COIN after `locktime*3`

If the swap fails(charlie goes offline) after bob locks his TOKEN, bob will claim back his TOKEN after `locktime*2`; alice will claim back her COIN after `locktime*3`

I have a few points I would like to discuss.

Would this actually increase volume(and therefore narrow the spread) on KMD pairs?

Does it make more sense to reverse the order of the transactions and locktimes to favor Alice?

Does the game theory hold? Is every party's best move to complete the swap? Even if two parties collude?

Are there any potential problems if this were implemented into a AMM-like UX? Alice says "I have COIN, I want 10 TOKEN". She immediately receives back offers from charlies and chooses one.

[Alrighttt]

I should note that this does seem extensible to "ABCD(...EFG)" swaps. Would there be any practical use for such a thing?

[theblackmallard]

Alrighttt, I really like this idea and it got me thinking about my own twist on it. I think the 3rd party Charlie facilitating a swap makes a lot of sense, especially for coin pairs where there isn't sufficient liquidity, or even liquidity at all. I don't think I have the expertise to peer review your work. I would however like to propose an additional idea that fits under this topic and is based on this problem set.

I think the issue being addressed here is how to get low liquidity pairs to have volume. If Alice has TOKEN and wants COIN, but there is not sufficient TOKEN/COIN liquidity available, then Alice either has to accept a different TOKEN/other pair, rely on Charlie(s) to bridge TOKEN == KMD == COIN for a fee, or just forget about it. This makes Charlie an active participant in seeing the happy resolution for Alice (her receiving COIN) for a fee, making Alice and Charlie both care about the total end result. While Bob doesn't care that Alice is using Charlie to route her order so long as Charlie takes Bobs order.

I think there is another way to address a low liquidity problem with only Alice caring about the complete end result. Here's my version of this (Alice wants to trade TOKEN for COIN) and we'll use KMD as the most common base pair. The main requirement is that there must be at least equivalent value of TOKEN/KMD as there is KMD/COIN available to trade on the books and Alice must have at least enough KMD to send a DEX fee.

`Alice looks at the value of TOKEN she has and looks for an equivalent value of COIN available. She checks this by looking that the TOKEN/KMD available orders are of at least equivalent value to the COIN/KMD available orders. Alice sees that Charlie has COIN and wants KMD, Alice also sees that Bob has KMD and wants TOKEN. Alice sends a DEX fee to both Charlie and Bob (using the small KMD she has)

Bob and Charlie both send their respective MakerPayments which are locked awaiting Alice's following payments

Alice now has two orders available to fill. But she doesn't have enough KMD to send as a TakerPayment to Charlie just yet, so she focuses on Bob.

Bob and Alice proceed with their atomic swap as normal. TOKEN for KMD. Meanwhile Charlie awaits the KMD TakerPayment.

Alice and Bob complete their swap and Alice immediately uses the KMD she received from Bob as a TakerPayment she sends to Charlie.

Charlie and Alice proceed with their atomic swap as normal.`

The end result is: Alice had TOKEN, wanted COIN, now has COIN. Bob had KMD, wanted TOKEN, now has TOKEN. Charlie had COIN, wanted KMD, now has KMD.

Some key points: This doesn't work obviously if there is NO available orders for TOKEN at all or insufficient liquidity of COIN available. In that case Alice could request that Bob facilitate this route for a fee through the way Alrighttt describes above.

Charlie now doesn't care about Bobs transaction and Bob doesn't care about Charlies, only Alice cares about both transactions which makes her the sole risk taker and also removes the need for Alice to communicate or negotiate with Charlie or Bob. She just uses the DEX fee to communicate intent to fulfill each order.

This requires Alice to have at least enough KMD to send a DEX fee to Charlie to begin the swap process, ie. a fee paid to secure a price for Alice with Charlie, but doesn't require she has enough KMD to actually complete the swap with Charlie. This need for KMD could also be seen as a benefit for buying and holding KMD.

If this looks like arbitrage type activities, it's because it is. The difference is that instead of profiting on the spread, Alice is simply looking to swap coins and by sending two DEX fees she secures a specific rate even before she has enough coins to complete one of the swaps. A simple visual of this would be if she did have enough KMD to buy the COIN and just did two regular swaps, TOKEN for KMD, and KMD for COIN, using the proceeds from TOKEN/KMD to replenish the KMD she just used to buy COIN.

Alice clearly takes the risk here, she is the only one who may end up with coins she didn't want (KMD) if the Bob swap is successful but the Charlie swap fails. But I believe this risk could be acceptable for a few reasons, Alice now has the more liquid coin and could attempt to secure another COIN swap should the Charlie swap fail; Alice is simply performing two "normal" atomic swaps which have a high success rate; Alice does not need to pay a fee to a 3rd party to facilitate the swaps; Alice does not need to inform Bob or Charlie of the end goal of swapping TOKEN for COIN nor does Bob or Charlie need to communicate a shared secret to one another, only the standard swap information with Alice.

Because there isn't the need for extra communication and negotiation, the logic only needs to be coded into the Client software used by Alice, so Bob and Charlie could be mobile users, desktop users, etc. This also means that Bob and Charlie are fungible, in other words, Alice could have just as easily did this backwards routing from Charlie to Bob, because there isn't a need for Bob or Charlie to perform anything different like negotiating, communicating, routing, etc. She doesn't need there to be someone willing to route her orders for a fee, because she can route them herself through any available market maker.

These are some thoughts I had been discussing with Alrighttt in PMs and wanted to get them out here on Github for others to see and comment on. These two ideas are not mutually exclusive, but I'd think they are complimentary. If there is not enough liquidity for my method, Alice could seek out a Bob to establish one for a fee. If there is enough liquidity, Alice could just route it herself.

[Alrighttt]

I appreciate the response. I've written this concept of an "ABC swap" with the idea being that it allows Alice to atomically swap on a pair with no direct volume. This is to facilitate UX similar to uniswap's or sushiswap's AMMs in which a user simply says "I have coin X; I want coin Y" and it can work without any volume on this X/Y pair. With this UX in mind, it would be unacceptable for a user to get stuck with an intermediary coin they did not want.

Your idea can be done with no modification to the network protocols, and I think it could be implemented much quicker and much more easily than ABC swaps. If you're interested, I can direct you to the relevant code, so you would be able to negotiate swaps prior to having the coins necessary for the swap. You will however still need to cover the DEX fee to initiate the swap.

[artemii235]

Hi, @Alrighttt, thanks for opening the issue!

Would this actually increase volume (and therefore narrow the spread) on KMD pairs?

We can implement it for any ABC pairs. I guess it will increase the liquidity on AtomicDEX in general.

Does it make more sense to reverse the order of the transactions and locktimes to favor Alice?

I need to think about it. As of now, Alice is obliged to send the dex fee before the swap payments. So in the proposed protocol, she is at risk of both losing the dex fee and locking her funds for a significant time if Bob and Charlie do not participate as expected.

Does the game theory hold? Is every party's best move to complete the swap? Even if two parties collude?

I think there isn't much of an incentive that will force all parties to follow the protocol. But we can say the same about the existing swap protocol.

Are there any potential problems if this were implemented into a AMM-like UX? Alice says "I have COIN, I want 10 TOKEN". She immediately receives back offers from charlies and chooses one.

It should be possible to implement it. The only potential problem I see for now - we will have an additional point of failure because of 1 more party involved.

[Alrighttt]

Hi, @Alrighttt, thanks for opening the issue!

Would this actually increase volume (and therefore narrow the spread) on KMD pairs?

We can implement it for any ABC pairs. I guess it will increase the liquidity on AtomicDEX in general.

Yes, the question assumes that KMD would be the "bridge", but it could be any coin. This is actually why Charlies must "send offers" to an Alice. It could be that there are significantly cheaper(from Alice perspective) paths depending on which coin the offering Charlie starts with.

Does it make more sense to reverse the order of the transactions and locktimes to favor Alice?

I need to think about it. As of now, Alice is obliged to send the dex fee before the swap payments. So in the proposed protocol, she is at risk of both losing the dex fee and locking her funds for a significant time if Bob and Charlie do not participate as expected.

I hadn't really considered a dex fee in this. It could be that I am missing something here, but it seems there is no technical reason to have a dex fee from Alice. The first transaction is Alice locking her coins. This alone shows bob and charlie that she is actually willing and now fully committed to do this swap.

There does seem to be an issue of Charlie being able to make the best offer without committing to anything. Maybe a malicious Charlie will respond to every Alice query with the best possible offer. Could it be that Charlie's "offer" itself is a dex fee transaction? This would incentivize Charlie to only make offers he is confident Alice will accept.

Does the game theory hold? Is every party's best move to complete the swap? Even if two parties collude?

I think there isn't much of an incentive that will force all parties to follow the protocol. But we can say the same about the existing swap protocol.

Maybe it is not quite "game theory" I was asking about. A better question would be.. Can any of the two parties collude to rob or exploit the third?

Are there any potential problems if this were implemented into a AMM-like UX? Alice says "I have COIN, I want 10 TOKEN". She immediately receives back offers from charlies and chooses one.

It should be possible to implement it. The only potential problem I see for now - we will have an additional point of failure because of 1 more party involved.

Related to the above response re: "game theory", we should consider how to incentivize this from failing. How might we disincentivize negotiating such a swap then going offline?

[artemii235]

but it seems there is no technical reason to have a dex fee from Alice

Alice is a taker here, so she must pay the dex fee - it is a core requirement of the protocol.

Could it be that Charlie's "offer" itself is a dex fee transaction? This would incentivize Charlie to only make offers he is confident Alice will accept.

I assume that both Bob and Charlie have maker orders, which means they should not pay additional fees. Zero trading fee is an important advantage of market making on AtomicDEX, and we also want to create more incentives for them (https://github.com/KomodoPlatform/atomicDEX-API/issues/714).

Can any of the two parties collude to rob or exploit the third?

It does not seem that the proposed protocol has such an exploit, but I will take a look one more time to be sure.

Related to the above response re: "game theory", we should consider how to incentivize this from failing. How might we disincentivize negotiating such a swap then going offline?

If we have additional market-making rewards, then Bob and Charlie will be financially motivated to complete the swap. Also, we plan to have a reputation system that can be used to select the most reliable peers on the network.

[Alrighttt]

but it seems there is no technical reason to have a dex fee from Alice

Alice is a taker here, so she must pay the dex fee - it is a core requirement of the protocol.

It does not make sense for Alice to pay the dex fee in this situation. The technical reason for having Alice pay a dex fee in a typical swap is to prevent Alice from spamming the network and locking up all available bob volume. It must cost something to tell a bob to lock his coins otherwise any alice could tell every bob to lock up all of their available coins. In the same vein, it must cost Charlie something in order for him to tell Alice and Bob to lock their coins.

Alice can spam requests to the network all she wants, but without a compatible Charlie, these requests do nothing at all. However, we have an issue here in that Alice might query the network looking for a compatible Charlie, and a malicious node may send back an appealing offer with no intent of going through with it. Alice is paying a premium to Charlie. Charlie can simply pass on the dex fee cost to Alice.

Why is it "a core requirement of the protocol"?

Could it be that Charlie's "offer" itself is a dex fee transaction? This would incentivize Charlie to only make offers he is confident Alice will accept.

I assume that both Bob and Charlie have maker orders, which means they should not pay additional fees. Zero trading fee is an important advantage of market making on AtomicDEX, and we also want to create more incentives for them (#714).

Charlie does not have maker orders. Please let me know if you need a further explanation of this.

Related to the above response re: "game theory", we should consider how to incentivize this from failing. How might we disincentivize negotiating such a swap then going offline?

If we have additional market-making rewards, then Bob and Charlie will be financially motivated to complete the swap. Also, we plan to have a reputation system that can be used to select the most reliable peers on the network.

I think reputation systems should be the absolute last resort. I believe they can be useful for improving UX, but the protocol should in no way rely on it. From a protocol standpoint, a swap should look exactly the same with or without reputation system in mind. To be blunt, I see it as a crutch.

[artemii235]

The technical reason for having Alice pay a dex fee in a typical swap is to prevent Alice from spamming the network and locking up all available bob volume.

Why is it "a core requirement of the protocol"?

Because the protocol is not just an abstract technical entity, but a thing that is used in the real trading application. It is quite common on exchanges that market participants taking the liquidity from the market have to pay higher fees for that. The opposite - market participants, who provide (make) the liquidity pay less or no fees at all. I personally consider this a much more important UX requirement, than anti-spamming capabilities, etc.

Charlie does not have maker orders. Please let me know if you need a further explanation of this.

Let's imagine that Alice uses the GUI and she wants to initiate a COIN/TOKEN/KMD swap. To understand that it is even possible she will need to see Bob's COIN/KMD order and Charlie's TOKEN/KMD order. This means that Bob and Charlie should create their orders before this. Alice will then select this available trading path and start an ABC swap.

If Charlie doesn't have the maker order prior to this event, how will Alice know that the ABC swap is possible?

I think reputation systems should be the absolute last resort. I believe they can be useful for improving UX, but the protocol should in no way rely on it. From a protocol standpoint, a swap should look exactly the same with or without a reputation system in mind. To be blunt, I see it as a crutch.

The swap will look exactly the same whether there will be a reputation system or not. The goal will be to choose more reliable peers before the swap, not to extend the swap protocol somehow, which doesn't look possible.

[Alrighttt]

bob places a limit order - selling his 10 COIN for 1 KMD

alice announces she wants to trade her TOKEN for COIN ( via TOKEN -> KMD -> COIN assuming there is no direct TOKEN/COIN volume)

charlie replies to alice(CCing bob) "I will statify bob's order of 10 COIN for you if you give me 2.5 TOKEN"

Alice agrees to pay 2.5 TOKEN for 10 COIN or we stop here.

Charlie does not have passive orders like Bob. Charlie is waiting for Alices to announce "I want to trade TOKEN for COIN". Charlie then calculates the cheapest path to do this, and responds to Alice with his "offer".

[Alrighttt]

To be clear, it is not simply "anti-spam". It is anti-robbery, anti-dos as well.

[artemii235]

Charlie does not have passive orders like Bob. Charlie is waiting for Alices to announce "I want to trade TOKEN for COIN". Charlie then calculates the cheapest path to do this, and responds to Alice with his "offer".

The tricky part is it looks very similar to me as having a maker order. If I envision it correctly, Charlie should have some record for which pairs he would like to receive such offers. And know the price and volume at which he will accept them. So, even if it's not visible in the order book, it still exists on the Charlie node in a form of "hidden" liquidity.

And again - it will be used in GUIs. If there is such a "hidden" offer from Charlie it will be a more complicated process to implement.

It is quite controversial who is the maker in the proposed protocol, but it seems to me that Bob and Charlie are providing the liquidity to Alice, so she should pay the dex fee.

[Alrighttt]

I don't think it quite matters who exactly you term the "maker". At least for the order of events that I have proposed, there is a clear technical requirement for Charlie to pay a fee or otherwise lose something if he decides to maliciously tell Alice and Bob to lock their coins. Alice and Bob do nothing if Charlie does not first make a commitment.

In a traditional two party swap, this concept of "making a commitment" is why Alice pays a dex fee. This commitment is a crucial part of the protocol itself. It does not exist because of the idea of "Taker pays fee, Maker doesn't".

In a two party swap, if Alice did not lose anything for creating bogus or malicious offers to Bob, she could tell every single Bob to lock all of their coins. A single Alice could DOS the entire network for literally 0 cost.

If you are still convinced Alice must pay a fee, we can impose an artificial fee on her, but it serves no technical purpose. Regardless of whether we impose a fee on Alice, Charlie must still lose something if he maliciously tells Alice to lock her coins.

And again, Charlie can simply pass on the ENTIRE fee to Alice via his premium. Charlie is making a guaranteed profit in every single ABC swap he participates in(assuming he is not acting out of charity).

[CHMEX]

I do love the concept of this ABC swap and I believe it can increase the usage of AtomicDex significantly.  Maybe not on the top 50 coins pair but specially in the ERC20 world or for small cap coins. If you lock at current defi swaps and it's very common to hope via another token.

As an example: On atomicdex we have buy orders on THC KMD and BTC KMD but nothing on THC BTC. Somebodys perfectly happy paying KMD for THC and BTC for KMD but nobody wants to pay BTC for THC. Doing an ABC swap seems the perfect decentralized solution for it and if the protocol can not handle it alice might do it herself after the first swap is completed. She will just waste more time and trx fees. In the end Charly might end up with the KMD anyways and giving BTC why not do it faster and by sending it directly to alice (via proposed way). Alice shall pay the dexfee Bob and Charly should not: if Charly needs to pay the fee for commitment reasons than that is also fine and C can as mention before just increase his premium to offset it. IMO the Goal is to get Alice as quickly as possible the right coins we wants. It might be even possible that going that extra Charly route a swap completes faster for alice. After all if time is money as everybody says than Alice is more than happy to pay money*2 for time/2. So an increased dex fee for extra speed might even plausible.

[cipig]

the reason why THC/BTC is missing is because the price is 0.00000025 BTC as of https://www.coingecko.com/en/coins/hempcoin-thc... i simply don't post orders on such coins against BTC any more because every 1 sat change is 5% and more... and there are much worse coins out there... they should all do a reverse split 1000:1 through a new chain or burn 99.9% of their supply to fix the problem :-)

[CHMEX]

this kind of low sats coin "problem" will just increase if BTC goes to 300k (or whatever number) yes a burn in theory would "fix" that in a rational system.

[ptyx11]

I should note that this does seem extensible to "ABCD(...EFG)" swaps. Would there be any practical use for such a thing?

uniswap often does this. routes through multiple pairs to find the liquidity. with utxo chains the problem is the cost of transaction and block times.

[ptyx11]

Charlie does not have passive orders like Bob. Charlie is waiting for Alices to announce "I want to trade TOKEN for COIN". Charlie then calculates the cheapest path to do this, and responds to Alice with his "offer".

The tricky part is it looks very similar to me as having a maker order. If I envision it correctly, Charlie should have some record for which pairs he would like to receive such offers. And know the price and volume at which he will accept them. So, even if it's not visible in the order book, it still exists on the Charlie node in a form of "hidden" liquidity.

And again - it will be used in GUIs. If there is such a "hidden" offer from Charlie it will be a more complicated process to implement.

It is quite controversial who is the maker in the proposed protocol, but it seems to me that Bob and Charlie are providing the liquidity to Alice, so she should pay the dex fee.

definitely, alice initiates the swap.

[ptyx11]

This would be similar to the Uniswap router contract, only that it's for utxo coins. KMD Router

• User has Dogecoin Balance
• User wants to swap Doge -> LTC
• There is no liquidity for Doge/LTC but there’s liquidity for Doge/KMD and KMD/LTC
• User initiates swap for Doge -> LTC
• Router Swaps Doge -> KMD
• Router Swaps KMD -> LTC
• User receives LTC

[Alrighttt]

This would be similar to the Uniswap router contract, only that it's for utxo coins. KMD Router

* User has Dogecoin Balance

* User wants to swap Doge -> LTC

* There is no liquidity for Doge/LTC but there’s liquidity for Doge/KMD and KMD/LTC

* User initiates swap for Doge -> LTC

* Router Swaps Doge -> KMD

* Router Swaps KMD -> LTC

* User receives LTC

From an end-user perspective it could feel no different than AMMs. However, you might think of it as 3 people standing in a circle all agreeing to simultaneously hand the object they are holding to the person to their left.

[ilienongithub]

Has this gone any further DoDoex.io do it with an option to use Indirect Routing, would be great to have it on atomixdex. https://youtu.be/Ku_pmoiL5E4 have a look at video

[LiamRabbittGitHub]

not sure if this has moved on but here is an Idea of how it could all work. https://youtu.be/2RZ1Oxw18QU