Add Mixer with In-pool transfers and proof-of-innocence

[jat9292]

A simple Mixer is Tornado Cash V1 we could reimplement and adapt this same protocol in Noir directly inside the Private-Token contract which would contain the merkle tree of deposits. Instead of hash(secret1,secret2) for the leaves, we would use hash(decrypted_value,secret), so unlike tornado cash v1, deposits would require a zkSNARK to verify that decrypted_value amount is correctly burnt during deposit.

A Mixer which would support in-pool transfers is also possible if we re-implement the Tornado Cash Nova update. But bear in mind that in-pool transfers implies increased complexity for the proof-of-innocence feature, but solutions still exist as seen here.

Add proof-of-innoncence aka Privacy Pools feature for compliance : see Privacy Pools paper This would necessitate integration with onchain analysis services like Chainanalysis or TRM labs to get the blacklisted deposit sets.

[jat9292]

An interesting extension on top of the inpool transfers (possible via the utxo model of tornado nova) is mentioned briefly at the end of this video by Roman Semenov which would allow private atomic swaps between different tokens. But this would require some change in the architecture : instead of wrapping each new ERC20 in a new WrapperContract, we would have a unique Wrapper Contract for all ERC20 and ERC721 we which to wrap . In other words, just put a mapping between addresses of tokens and encrypted balances inside the singleton contract.

[critesjosh]

Instead of using hash(decrypted_value,secret), shouldn't we use something like hash(hash(decrypted_value, secret1), secret2)?

The first input to the hash function is used for generating the nullifer hash (in TC v1), and if just decrypted_value is used, it could be brute forced.

If we don't actually need the decrypted value for anything in the withdrawal function, we could just use hash(secret1,secret2) like TC.