Open kayabaNerve opened 4 years ago
artemii235
commented
4 years ago Thanks for creating the issue! Integrating such protocol can be really great enhancement for AtomicDEX. We will surely consider this after beta testing stage ends.
There is a proof of concept available
Is proof of concept code publicly available? If yes, could you please also post a link here?
kayabaNerve
commented
4 years ago It both is and isn't.
The above protocol relies on two pieces of cryptography; DL EQ proofs and adaptor signatures. If we consider the ETH/BTC pair, the former isn't needed (it's used so secp256k1 keys can interact with Ed25519 keys). The latter is still needed, and a few implementations are around, with the notable one being secp256kfun by a developer at Comit Network.
When it comes to the full transaction flow, namely generating the BTC TXs and transmitting data in the proper order, then yes, I built the PoC with a partner. It's named ASMR, yet it doesn't explicitly have ETH support. It's meant for XMR/MR/NANO.
ETH would take the place of XMR/MR/NANO to save fees. To get it working with the above proof of concept, you'd need to define the two trait implementations and add a couple lines to main so its recognized as an option.
That said, for a non-PoC implementation, I'd recommend bundling the software behind this with a generic suite also enabling XMR. I'm hesitant to keep bringing XMR up, due to the scope of this issue being targeted at ETH, though the software for one is the software for the other, so I feel its important to keep both in mind. There is an active proposal, as I said above, for such a suite.
artemii235
commented
4 years ago Thanks for link!
That said, for a non-PoC implementation, I'd recommend bundling the software behind this with a generic suite also enabling XMR. I'm hesitant to keep bringing XMR up, due to the scope of this issue being targeted at ETH, though the software for one is the software for the other, so I feel its important to keep both in mind. There is an active proposal, as I said above, for such a suite.
It's ok to mention XMR and other coins as we would like to have the ability to support as many different coins as possible. So I consider "reducing ETH fees" just as positive side effect of suggested protocol. It is very interesting and more important that a coin might not have time locking capabilities or even scripting at all, but can be still atomically swapped with 4 transactions.
kayabaNerve
commented
4 years ago 2, actually, if the funds are already in a SegWit wallet. 3 if they're not, with a worse case of 4 (SW; lock; refund; claim).
Currently, ETH trades on AtomicDEX charge extremely high network in fees (over 10 dollars as this is posted). This is due to the smart contracts executed, with a gas limit of roughly 350k. That said, it possible to reduce this to 42k.
https://github.com/h4sh3d/xmr-btc-atomic-swap proposes a new atomic swap protocol enabling BTC/XMR atomic swaps. That said, calling it a BTC/XMR atomic swap protocol is inaccurate. In reality, it is a way to conduct atomic swaps where one coin simply has a secure private key exchange, so a standard transaction can be created.
With BTC as the scripted coin, it uses the exact same scripts as that paper includes. That said, the DL EQ proof is omittable due to both coins using secp256k1, and there's no view key in place. Crafting ETH transactions with the keys described enables the ETH side of the swap to only have two ETH transfers; no smart contracts. As an ETH transfer costs 21k gas, the two transfers costs a total of 42k.
This represents multiple dollars in savings, not to mention less load for Ethereum. That said, it does require implementing this new protocol, which also enables swaps with XMR/NANO/MR/GRIN. That said, those first three will need the DL EQ proof. A generic implementation of this protocol, with BTC and then backends for ETH/XMR/NANO, would greatly expand AtomicDEXs functionality and efficiency. There is a proof of concept available, which I was behind with my partner. There's also a proposal for a properly reviewed, fully fleshed, extendable, modular, and integrable library, yet that is another discussion.