- Decentralized and P2P
- Shielded, private
- Trustless
How are you guys feeling about this design?
How are you guys feeling about this design?
Awesome! I want to see more!
Excited this is being built. Seems there is a big appetite for atomic cross-chain style trades on twitter at the moment. I’ll need to reread your proposed design, but how does this compare to what is being used in the DCRDex? If this could be built-in to ywallet in the future that would be amazing.
Awesome!
Zcash definitely needs atomic swaps. BTC/ZEC pair is a must have, but I also think there should be a ZEC pairing with a smart contract currency with low fees.
Another thing to consider is the liquidity. I think most atomic swap protocols have low liquidity, or at least the Atomic DEX does. It would help if there was one common liquidity pool, or an aggregator for all the different swap protocols.
Wow. This is super interesting and exciting. The first swap pair must be BTC/ZEC. Will this be a standalone app or built into Ywallet?
@Milton It is technically not possible because zcash does not have programmability. You can wrap ZEC and trade (like renZEC). Or a DEX that use multi-sigs (like Thorchain). Zwap are native and atomic. The liquidity is a valid concern.
Btw, it seems that Atomic DEX is not truly atomic for native ZEC.
@gottabeJay Not sure how/if it is going to be built. It is a lot of work tbh.
To give you a sense of the scope: here’s the github for monero GitHub - comit-network/xmr-btc-swap: Bitcoin–Monero Cross-chain Atomic Swap
It is technically not possible because zcash does not have programmability. You can wrap ZEC and trade (like renZEC). Or a DEX that use multi-sigs (like Thorchain). Zwap are native and atomic
What is not possible? Atomic swaps with a smart contract currency? There are people working on an ETH/XMR atomic swap protocol.
Btw, it seems that Atomic DEX is not truly atomic for native ZEC.
Why?
As you can see, it is done by the same people with the same technique (comit).
I was referring to the low fees part. I think if you want zcash to be part of an existing liquidity pool, it needs to be wrapped.
Zcash has not ported the CheckLockTimeVerify.
(Bip 65) according to List which BIPs apply to Zcash · Issue #87 · zcash/zips · GitHub
While atomic swaps are very exciting, this is the main concern imo. From my understanding even XMR/BTC swap haven’t seen much adaptation, so ZEC/BTC won’t be better.
Have you looked into upcoming Serai DEX? They’re considering to implement a bunch of privacy coins but Zcash hasn’t been mentioned, don’t know if it’s due to technical complexity or not
I did shielded ZEC-BTC atomic swaps years ago.
You’re more than welcome to fork it into a production codebase with an order book. It’d definitely need modernization though (something I’ve been debating doing myself. Beyond general dependency cleanup, the whole CryptEngine garbage should be removable. Serai currently offers crates for an extension trait around ff/group, Schnorr signatures, and even a more efficient CG-DLEq proof). I have no interest in modernizing it to Orchard though, due to the inability to produce FOSS software utilizing Orchard.
Also, you cited COMIT’s work as “the github for monero”. ASMR was the first implementation. COMIT or the developer behind Basicswap was second. Then, the team behind the original paper built Farcaster. I believe COMIT has had the most usage over the years though.
@chmod: Thanks for the mention (I’m the lead developer behind Serai). We recently were asked about Zcash, and I said I’d be open to it if the right connections were made (which they since have been). I have no technical concerns at this time, and have resolved my legal concerns. The sole question is prioritization, where we’re mainly trying to get the network up and running right now. While I agree with you regarding adoption, hence my own work, it’s probably best to keep this thread to trustless solutions.
Edit: If anyone moves forward with this, an integration into BasicSwap probably makes vastly more sense than an independent effort.
And then specifically regarding the CG-DLEq, the Monero atomic swap paper used MRL-0010. Serai’s implementation made various optimizations. Halo 2 does not make sense in the slightest as you’ll have to bit decompose every single operation due to the non-native fields. If you don’t want to use the linear DLEq, use COPZ’s logarithmic DLEq proof (which Serai has a tracking issue to implement).
I would have used 1 proof on halo2-pallas and 1 proof on halo2-secp256k1. Each saying P=s.G (in their respective base field) and hash(s) = H. An algebraic proof is probably easier but the paper you referenced does not have an implementation whereas halo2 is available on pallas and secp256k1. Thanks for pointing out your implementation.
That said, neither the original postulation (which had flaws) nor any construction here has been proven nor audited. Accordingly, they are solely experimental, and none are recommended.
In this case, what proof are you going to use?
Possibly, but with the current situation around access to private coins on CEX, I think there will be a renewed interest in decentralized p2p anonymous swaps.
The original didn’t prove knowledge of the DLog and had a notation issue. It solely need supplementing with a pair of Schnorr signatures.
The proofs offered include the original, and various tweaks on it for perf (instead of a 2-ring, a 4-ring can save a few elems without incurring cost since 2**2=2+2).
I think, out of all the tech being discussed, MRL-0010 is a valid candidate regarding tech. Regarding performance, it should be COPZ.
While you can do a non-algebraic hash in a SNARK, which avoids the non-native field arithmetic, props, I think COPZ would be much easier and much more performant. It’d also have much more flexibility.
As a clarification, sorry for making it so long after the fact, I’m not going to use any of these. My work is 1.75y old and used MRL-0010 with a shared challenge, notated ConciseLinear in my current work. My current work offers these proofs as a community service, not due to any usage on my end.
If I had to pick one, it’d be COPZ, which we do have a tracking issue to impl.