arielgabizon/gist:67ec4a85900f19af880d909cfaf72f7d

## gistfile1.txt
H was reading about atomic cross-chain trading in the wiki link above 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 above 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 know 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)
0.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).
1.Bob will create such a note N=(pk,v=10,s) by generating a keypair (sk,pk) and random serial number s.
2.He'll send N to alice.
3.Bob will check what the current Merkle root rt is on the Zcash chain note commitment tree.
4.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"
5. 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.
6.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 need 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 number s).
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 uses the note N' she's suppose to pay him with in a different Zcash transaction, then he can invalidate the contract.
	H was reading about atomic cross-chain trading in the wiki link above 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 above 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 know 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)
	0.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).
	1.Bob will create such a note N=(pk,v=10,s) by generating a keypair (sk,pk) and random serial number s.
	2.He'll send N to alice.
	3.Bob will check what the current Merkle root rt is on the Zcash chain note commitment tree.
	4.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"
	5. 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.
	6.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 need 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 number s).
	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 uses the note N' she's suppose to pay him with in a different Zcash transaction, then he can invalidate the contract.