Skip to content

Instantly share code, notes, and snippets.

@nimbosa

nimbosa/ZEC-ETH.md

Forked from arielgabizon/gist:7e9906d3e06106cb5cfb7651a954c8b4
Last active April 15, 2018 05:03
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save nimbosa/1b07be48b8a2d96ba1f1d302816fe840 to your computer and use it in GitHub Desktop.
Save nimbosa/1b07be48b8a2d96ba1f1d302816fe840 to your computer and use it in GitHub Desktop.
Download ZIP
ZEC-ETH atomic cross-chain trading
Raw
ZEC-ETH.md

I was reading about atomic cross-chain trading in the wiki https://en.bitcoin.it/wiki/Atomic_cross-chain_trading and think that perhaps the Zcash circuit could be used to easily get semi-private Zcash-ETH atomic cross-chain trading.

As in the wiki it would require the parties to communicate before and verify by themselves that certain things have appeared on the two chains. On the other hand, it doesn't require ETH chain to verify Zcash Proof of Work as I thought was needed. What the ETH client will need to do is verify a snark of the Zcash circuit (which was recently implemented for the C++ client as described in https://z.cash/blog/zcash-eth.html)

Semi-private means Alice will agree with Bob to exchange say 10 zec for 1 eth, and this 10 will only be known by both of them. Furthermore the address to which Bob's 10 zec note will be sent will be a z-addr known only by him and Alice.

So here's how it could work (simplified)

  1. Alice will send Bob the Eth address Addr where she wants to receive her 1 eth Recall a Zcash note consists of a value v, public address pk, serial number s. (I'm omitting the commitment randomness r for simplicity).
  2. Bob will create such a note N=(pk,v=10,s) by generating a keypair (sk,pk) and random serial number s.
  3. He'll send N to alice.
  4. Bob will check what the current Merkle root rt is on the Zcash chain note commitment tree.
  5. He'll compute comm=Hash(N) , and create a contract on the Eth chain containing 1 eth saying "if someone supplies a SNARK proof together with public inputs INP satisfying the Zcash circuit such that INP includes rt and comm, then send the 1 eth to addr"
  6. After seeing Bob created this contract on Eth chain, Alice will create a proof pi and public inputs INP satisfying the Zcash circuit s.t. rt and comm are contained in INP. She will supply (pi,INP) to Bob's contract and receive her 1 eth.
  7. Now note that (pi,INP) are all that is needed to create a joinsplit on the Zcash chain where the note N would actually be created, so Bob can use the input (pi,INP) supplied to the contract to create his note N worth 10 zec on Zcash chain.

Subtleties:

The contract needs to be more complicated in two ways (and perhaps more I have overlooked):

  1. It needs to demand that vpub_old part of INP is 0, otherwise (pi,INP) could only be used by Bob to create his 10 zec note if he adds value from some transparent note that he would need to supply.
  2. Alice could cheat Bob in the following way. Before supplying (pi,INP) to the contract she could spend one of the ZEC notes N' that she used to create (pi,INP) in a different transaction on the Zcash blockchain - transfering the value of the note N' to some other note N'' that she will control rather than the note N that Bob will control (btw Bob controls N cause only he know both the value sk and serial numbers).

So there needs to be a part of the contract saying "If a second snark proof and public input (pi',INP') for the Zcash circuit is supplied such that one on the nullifiers, i.e. hash of serial number, is the same as in INP, then the contract is revoked, and no eth is sent to addr". Using this, if Bob sees on the Zcash chain that Alice has used the note N' she's suppose to pay him with in a different Zcash transaction, then he can invalidate the contract.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment