We just did a fully trustless shielded ZEC to EVM atomic swap with no new signing primitives! And yes, it is programmable

[strahncryptography]

@aryaethn

1. After Party A locks ETH, what happens if Party B never broadcasts the matching Zcash tx? Is there a timeout/refund path, and how do you size it against Zcash confirmation depth so B can’t lose ZEC to a refund race? Also, how do you handle the free-option problem, where B only completes if the price moves in his favor?
   If you haven’t thought in the game theory side, I have some ideas for it.

Yes, the contract does maintain a timeout state for the transaction. Well, I’m not sure if I coded this specific bridge to have a timeout, but I seem to recall I did plan to add one so.

A “refund race” is a mempool concept, which doesn’t apply here unlike classic adaptor signatures as all transactions are required to be mined into a block first, requiring you to spend considerable hashpower. And yes, a finality mechanism is planned!

@aryaethn

2. Both party A and party B are disclosing their connection of EVM address to the Zcash address. If you haven’t thought of a way for this, again, I can help.

Funnily, no. The sender on the ZEC side (party B) never discloses their sender address ANYWHERE, and as for the receiver, we are working on a BLS12-381 Groth16 CMX proof system to hide that by proving the cmx (commitment note hash) is valid. It is a b*tch to deal with because its Sinsemilla, which is a 255-bit hash, making it completely unfeasible in BN254, and we are only experimenting with BLS381 (where modadd is virtually native mod p, but modmul is still a headache)

@aryaethn

3. Since this design looks like a simple P2P-style swap/bridge, have you thought of ways to have ways for an intent-based-style of it, with market makers to do the work for a fee?
   Again, if you haven’t, I have some ideas.

Did you- I literally mentioned a programmable side to the post. Why is no one reading the post??? Shielded to EVM cross-chain programmability while keeping the sender anonymous

@aryaethn

I think I have come up with a viewing-key style of verification, which if in your interest, we can discuss it to see which is more reliable, securer, and definitely less costly.

Why would that be needed? The entire point of this was to prevent a spending or viewing key from entering the process, a là trustless. Plus, that would be SHIT EXPENSIVE to do as a proof, trust me, we tried ages before we devised this.