You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The interface proposed is more agnostic to the underlying crypto being used:
The mixer has two functions:
deposit(bytes32 commitment) payable verifies that DENOMINATION ETH (eg. 1 ETH) was sent along with the call, and if so it adds the commitment to a list of commitments. It also maintains a Merkle tree of all commitments to far that uses some SNARK-friendly hash function (even Pedersen to start off would be ok).
withdraw(address destination, bytes proof) verifies that (i) proof is a valid ZK-SNARK that proves that destination and some commitment in the tree are related to each other (eg. destination = H(commitment + salt)) but does not reveal whichcommitment the witness corresponds to, and (ii) destination has not yet been used. Upon success, it pays out DENOMINATION - FEE to the destination and FEE to msg.sender
We should adjust the interface used by Miximus to adhere to this specification.
The text was updated successfully, but these errors were encountered:
As per: https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/rJj9hEJTN?type=view
The interface proposed is more agnostic to the underlying crypto being used:
The mixer has two functions:
deposit(bytes32 commitment) payable
verifies thatDENOMINATION
ETH (eg. 1 ETH) was sent along with the call, and if so it adds thecommitment
to a list of commitments. It also maintains a Merkle tree of all commitments to far that uses some SNARK-friendly hash function (even Pedersen to start off would be ok).withdraw(address destination, bytes proof)
verifies that (i)proof
is a valid ZK-SNARK that proves thatdestination
and somecommitment
in the tree are related to each other (eg.destination = H(commitment + salt)
) but does not reveal whichcommitment
thewitness
corresponds to, and (ii)destination
has not yet been used. Upon success, it pays outDENOMINATION - FEE
to the destination andFEE
tomsg.sender
We should adjust the interface used by Miximus to adhere to this specification.
The text was updated successfully, but these errors were encountered: