Miximus Deposit/Split/Join/Withdraw

[HarryR]

The Miximus circuit is lacking functionality which allows tokens to be 'fungible'.

Currently each leaf is of a fixed denomination, if that denomination is 1 ETH then you need to make 10 transactions to make a 10 ETH payment. And if you want to make a 0.1 ETH payment, then you're out of luck.

This ticket proposes a mechanism to make deposits, payments and withdraws of arbitrary values, meaning that you're not constrained to using coins of a specific denomination.

Currently, with fixed denominations, you must deposit that denomination and in return the smart-contract inserts a leaf into the tree. Because the smart contract enforces the deposit values we know that every leaf is of a specific value, and nullifying a leaf allows that value to be withdrawn (and optionally transferred to another person, by immediately creating another leaf).

By introducing the notion of arbitrary values, it means that each leaf can have a different value, and the zkSNARK circuit must strictly enforce the value. The following modifications to how Miximus works allows for arbitrary values to be exchanged:

New leaf format (ish):

leaf = H(value || nullifier_hashed)

• Deposit
  • zkSNARK proof is provided that the leaf which will be inserted into the tree matches the deposit amount
  • Inserts leaf into tree
• Split
  • Spends a leaf, by proving knowledge of its nullifier
  • Inserts two new leaves
  • Ensures the sum of the two new leave is equal to the spent leaf
• Join
  • Spends two leaves, by proving knowledge of their nullifiers
  • Nullifies the two leaves
  • Inserts one new leaf
  • Verifies the value of the new leaf is the sum of the two spent leaves
• Withdraw
  • Proves knowledge of one nullifier
  • Proves the withdrawn amount is equal to the value of the leaf

Use cases:

• To send a payment to somebody you perform a Split transaction, which spends one of your unspent outputs and creates two new leaves - one owned by you for your change, and another owned by the recipient of the payment.
• To aggregate incoming payments into a single leaf you perform a 'Join' transaction

Problems:

• The join/split process could allow correlation of payments

Questions:

• Is there a way to avoid having to consolidate funds using a 'join' transaction?

[nourharidy]

I strongly support this proposal. Fungibility is required for Miximus to become usable as a form of private payment rather than an occasional decentralized "coin mixer".

Same goes for join/splits, Miximus would be far more useful if withdrawal out of Miximus was not required by the recipient.

I'm working on a project where I am considering to use Miximus with DAI and both of these features are a must for it to work.

[HarryR]

Cool, I will make this a priority.

Have you considered fungibility between multiple stable coins? e.g. Deposit DAI withdraw USDC or TUSD of equivalent value?

[nourharidy]

Different stablecoins are generally not fungible among one another. That includes different stablecoins on the same chain and same CDP stable coins on different chains.

This is mainly because you make different trust & security assumptions for each coin. For instance, with DAI you trust in the MakerDAO price oracle, but you make an assumption that in case the pegging is broken, a global settlement will occur, replacing your DAI with the equivalent ETH. While for USDT, for example, you trust that it's backer, Tether, will (A) continue to exist (B) will continue to hold 1-to-1 USD reserves and (C) will continue to accept the token for fiat USD.

[nourharidy]

Also, can you explain how join/split can allow for a payment correlation to be noticed?

[HarryR]

Also, can you explain how join/split can allow for a payment correlation to be noticed?

I think this may have been a mental note to think about this again, however there some example I can think of:

• I send a payment to you, I do this by performing a Split, this creates two UXTOs (my balance, and the output)
• Recipient performs a Join, combining their balance with the UXTO
• The Gas payer allows correlation of events
• If the wallet software automatically performs the Joins immediately upon receiving a payment and the recipient is assumed to be online at the time of the payment then you can link the Sender and Recipient together - although you may not know the value of the payment.

The ability to correlate increases with the number of payments, e.g. if 10 payments are made, then somebody performs 10 Join transactions, there is a higher probability of that one entity being the recipient for all of the payments.

This worries me because it can erode anonymity, although Miximus with fixed denomination tokens has similar problems with correlation.

This all hinges on the 'Gas Payer' problem, and the lack of account abstraction or meta-transactions (although Gnosis Safe is working towards providing viable meta transactions which can enhance anonymity).

Other references worth reviewing:

• http://www.coinjoinsudoku.com/
• http://www0.cs.ucl.ac.uk/staff/M.Maller/slides/zcon0.pdf
• https://arxiv.org/pdf/1805.03180.pdf

[HarryR]

https://github.com/snjax/zDai-mixer allows arbitrary sized coins