PoC Miximus application for end-users

[HarryR]

I am a user, I want to use Miximus, I have tokens or Ether which I want to convert into anonymised tokens. How do I do this?

Once my tokens have been anonymised I need to withdraw them again, to convert them back to the original tokens or Ether that I originally deposited. I should also be able to give these anonymised tokens to other people, without revealing that it was I that deposited them. As a user, should it be possible to lose access to my anonymised tokens even though I still have the private key for my Ethereum account?

We need to make a proof of concept application which uses Miximus and allows users to do common tasks, like deposit, withdraw, transfer etc.

There is JavaScript code which uses node-ffi and web3 to perform deposits/withdraws: https://github.com/HarryR/ethsnarks-miximus/blob/master/solidity/test/TestMiximus.js

And Python code to use the native module to create proofs: https://github.com/HarryR/ethsnarks-miximus/blob/master/python/test/test_miximus.py

Using either of these, can a proof-of-concept application be created that allows people to use Miximus more easily?

---

How does this work as a command-line application?

The command-line app needs to connect to an Ethereum full node, it needs to store state, provide a mechanism for converting currency into anonymised tokens, and provide a mechanism for converting the anonymous tokens back in to the original currency.

e.g.

$ miximus deposit 10 ETH
 - Deposited
$ miximus balance
 - 10 ETH
$ miximus send 5 ETH <my-friend>
 - Sent
$ miximus balance
 - 5 ETH

Then as

$ miximus balance
 - 3 ETH
$ miximus withdraw 3 ETH
 - Withdrawn 3 ETH
$ miximus balance
 - 0 ETH

Then as me again:

$ miximus withdraw 5 ETH
 - Withdrawn 5 ETH
$ miximus balance
 - None

There is a problem with this 'ideal user flow' - at any given point in time you know exactly what your balance is, you can send money to others, and withdraw an arbitrary amount. This matches the account model of Ethereum (and most other wallets) by creating a useful abstraction regardless of the number of underlying transactions, for example with Bitcoin you have N UXTOs which represent your balance.

This makes anonymity difficult because with a UXTO model your account can be correlated to determine the exact value of a transfer - e.g. if I do 10 transactions with a fixed coin size of 1ETH then 'they' know I'm sending 10 ETH to somebody.

Technical Challenges

How do you have an account-style model with anonymous tokens?

Following on from ZCash you need a split and join circuit, in addition to an arbitrary value for the transactions.

For example, you deposit 10 ETH, you now have a single token worth 10 ETH. You can then transfer 5 ETH to a friend by using a 'split transaction' where you take a single input and output two new coins. To receive the coins you need to use a Join transaction to combine your current balance with the new input. If 100 people send coins to you, you'd need to perform 100 join transactions to collect it all into a single account.

The alternative is a UXTO model where your available funds exist as separate coins, however in that case if you had denominations of 0.3, 0.5 and 0.2 you'd have to create a join transaction with 3 inputs and 1 output. This becomes a problem when the circuit is of a fixed size.

Compromise between usable and perfect

In a perfect world the zkSNARK circuit could join an unlimited number of inputs into an unlimited number of outputs, this is technically possible if you were to process the merkle tree update for spendable coins within the circuit - but that limits everybody to 1 transaction per block otherwise everybody else gets rejected due to conflicts.

What is the worst case though?

[HarryR]

Use case: Bob sends 10 ETH to Alice, by depositing into Miximus

• the way it would work, probably, is for Bob to pay Alice 10 ETH, Alice would provide Bob with 10 hashes.
• Bob doesn't compute a zkSNARK or anything like that to deposit, he just calls the 'Deposit' function of the contract, each time with 1 ETH and one of the 10 hashes Alice gave him
• Alice can see that somebody has deposited for those hashes, so when all 10 have been deposited she knows Bob has made the payment
• the hashes Alice creates are of two secret values, so she needs to keep a database with her secrets in.
• When it comes to spending a coin, she uses the secrets and merkle tree path of her hashes inputs to the zkSNARK circuit to prove 1) she owns the coin, 2) the coin exists in the tree

The secrets that Alice generates can be derived in the same way as a HD wallet.

e.g. for every coin you need 2 pieces of key material, 1) a nonce, 2) the secret key for an secp256k1 key pair (provable with ecrecover).

Via the command-line interface it would look something like:

Alice first creates the hashes:

$ miximus receive 10
Enter payment reference: Recieved from Bob...
 [1] HASH1
 [2] HASH2 ..
  ... etc.

Then Alice gives the hashes to Bob, who deposits coins for her:

$ miximus send 10
Enter deposit hashes:
  [1] ....
  [2] ...
  ...

 - Deposited

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 500.0 DAI (500.0 USD @ $1.0/DAI) attached to it.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $54,221.53 more funded OSS Work available on the Gitcoin Issue Explorer

[HarryR]

@uivlis Hey, thanks for applying. Feel free to ask any questions, if there's anything you need just let me know and I'll see what I can do.

[uivlis]

Hi @HarryR ! I can barely set up the repository, I've been running make's for quite some hours now. Have you ever stumbled upon this error:

* G1 elements in proof: 2
* G2 elements in proof: 1
* Proof size in bits: 1019
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path> >'
  what():  No such node (gammaABC)
Aborted
make[1]: *** [test] Error 134
make[1]: Leaving directory `/home/ubuntu/workspace/python'
make: *** [python-test] Error 2

Note that this is a Cloud9 workspace, maybe there's the problem?

[HarryR]

Hi @uivlis - I haven't come across this error before.

This looks like it's trying to load a verification key from a JSON file, but is failing because the gammaABC entry doesn't exist.

Ah, this is when running the python tests.

See: #9 for more details - I'm unsure why you're encountering this problem, and I can't reproduce it locally (or via the CI build system), but I could offer assistance via video conference etc. to help you resolve it.

[uivlis]

So, I must say that the first issue I ran into was this:
TypeError: the JSON object must be str, not 'bytes' in line 110 from miximus.py. I changed

return Proof.from_json(data)

into

return Proof.from_json(data.decode('ascii'))

only to result in the error from my first comment. Even before that, I ran into issues like ImportError: module 'Crypto' could not be found etc. I think it must be something from the set-up of the blank Ubuntu for Cloud9 (I use this service since my laptop runs on Windows). There must be some missing python package that is not installed by default, or some other tool.

Yeah, I would feel grateful for some assistance, is this mail live: [email protected]?

[HarryR]

Yeah, I would feel grateful for some assistance, is this mail live: [email protected]?

Yes it is live.

I'll see if I can reproduce the error with different versions of Python, it seems fairly straightforward.

[nanspro]

@HarryR i tried setting it up locally as i am interested in this one, i've read a paper related to coin mixing for my college project and looks like you are actually trying to implement some kind of anonymity in txs.
Uhmm yeah so the error when i am running make -C python test is

ERROR: test_miximus (unittest.loader._FailedTest)
----------------------------------------------------------------------
ImportError: Failed to import test module: test_miximus
Traceback (most recent call last):
  File "/usr/lib/python3.6/unittest/loader.py", line 428, in _find_test_path
    module = self._get_module_from_name(name)
  File "/usr/lib/python3.6/unittest/loader.py", line 369, in _get_module_from_name
    __import__(name)
  File "/home/fnatic/ethsnarks-miximus/python/test/test_miximus.py", line 4, in <module>
    from ethsnarks.mimc import mimc_hash
  File "/home/fnatic/ethsnarks-miximus/ethsnarks/ethsnarks/mimc.py", line 38, in <module>
    assert H(123) == 38632140595220392354280998614525578145353818029287874088356304829962854601866
  File "/home/fnatic/ethsnarks-miximus/ethsnarks/ethsnarks/mimc.py", line 35, in H
    hashed = keccak_256(data).digest()
  File "/home/fnatic/ethsnarks-miximus/ethsnarks/ethsnarks/mimc.py", line 10, in <lambda>
    keccak_256 = lambda *args: keccak.new(*args, digest_bits=256)
TypeError: new() takes 0 positional arguments but 1 was given

[HarryR]

Hi @nanspro apologies for the delay.

I have made a ticket for this and included what should fix the problem: HarryR/ethsnarks#118

Can you confirm this fixes the problem? I'm surprised Crypto.Hash.keccak.new isn't compatible with the Python hashlib conventions, I am sure that at when I implemented it this was working - but if it's not compatible with all Crypto.Hash versions it should be changed to avoid errors like what you encountered.

Alternatively, you can install pysha3

[nanspro]

@HarryR sorry for the delay, was busy with exams and then hackathon :)

Yes after changing the code as you suggested it is working now!!

[nanspro]

We want to create an application which uses miximus and through that users should be able to deposit, transfer, withdraw ether.
So should i jump into creating a CLI for end users according to the use case you suggested or do you want me to first go through the codebase and improve the workflow?

[HarryR]

No problem :D

There are a few things which are in the gap between 'Miximus as a PoC' and 'Miximus as a usable application'.

• There is no framework to interact with the Miximus smart contract
• How do you keep track of coins which you own that have been mixed?
• What kinds of abstractions, at a program architecture level, need to exist?
• If we wanted to take the proof-of-concept and make it a CLI program (to find out the edge-cases) then progress that into being a mobile wallet or web app... how do we get from A to B?

Does it make sense that you can have these anonymous 1 ETH tokens, you can give them to other people, or 'mix' them then withdraw them again, Miximus gives you a way to do this, but... we just need a way of using those tokens, and IMO the best way forward is to try and make examples where you can use these anonymous tokens.

The more you get into it, the more you'll figure out right? But, ideally, if we think of scenarios like 'I want to mix a token' or 'I want to pay somebody with an anonymous token', then if you see which steps both people would have to do to make that happen, then you can write software to automate it etc.

I guess the end-goal is figuring out what is possible, how does that work step-by-step, and how can we make this as easy as possible where 90% of it is automated, so people can do it without having to think (e.g. I have mobile phone, you have mobile phone, we press the 'transfer button' and bump the phones together, and the rest is magic) etc.

Even if you make a program which could work if you added Miximus to it, but which is only a proof of concept or an idea, that is still really helpful, because it works towards finding out all of these details and how it can be used. e.g. if you made a CLI program to manage 'anonymous tokens', and the 'mix' function just returns true, at least we can work out how to put Miximus into it later.

[janus]

@HarryR There is a interesting issue ... and with you help and support it would help me dig deeper . It is still open, am I allowed to give it a trial

[HarryR]

Hi @janus

There is a good example of how a client-application can be made for Miximus: https://github.com/argentlabs/hopper

If you need anything - just let me know and I'll try to assist.

[janus]

@HarryR
Thanks so much ... I will go through the material, and once I have clear picture of what needs to be done I would start off. I would come to you once I need help.

[nanspro]

Hey @HarryR
Thought this was expired but saw it recently listed on the hackathon isues. I already familiarized myself with the idea few months back and loved the concept. Just now i went through the contracts, tests again to remember how you are simulating user interaction.

You actually provided a lot of useful info above but i am little confused with what PoC means here?
https://github.com/argentlabs/hopper is already a good application using mixer, why do you want something similar or a CLI when you already have a mobile wallet.

I am thinking about a CLI application which will perform tasks as you mentioned above and i think such app will make it easier to test/improve the workflow of miximus. I will have more idea once i start and i'll try to address the technical issues like how one can track his owned anonymized tokens etc.

Just wanted to confirm with you once whether this is something which you'd like to see or not :) Thanks!

[HarryR]

Hi

I have no idea what's going on with GitCoin tbh. But, it seems the bounty is still up for grabs.

We were looking for people to get onboard with making these zkSNARK proof of concepts more user-friendly, with a bounty to help as an incentive so we could figure out how to make it as easy to use as possible and find out the challenges involved in integrating it into wallet software etc.

That's a good question - if Hopper exists - why would we need a CLI? Is a CLI even a good idea etc.

I still think there's a lot of discovery worth doing, maybe Miximus isn't the best project to put effort towards, maybe there are other similar concepts which the codebase could be easily adapted to fit (like Semaphore) where having a good CLI interface would help figure out the first steps and define a model that more user-friendly applications could re-use or implement without having to do all of the work and re-invent wheels.

What are your thoughts?

[janus]

Hi

I have no idea what's going on with GitCoin tbh. But, it seems the bounty is still up for grabs.

We were looking for people to get onboard with making these zkSNARK proof of concepts more user-friendly, with a bounty to help as an incentive so we could figure out how to make it as easy to use as possible and find out the challenges involved in integrating it into wallet software etc.

I am free and would like to participate.

[nanspro]

Hey @HarryR
So yeah i think having a CLI can be useful. If we can generate a flow like you have shared above in respect of cli then after that we can test different types of experimental solutions for the technical problems you mentioned.

I am actually very fascinated by zero knowledge proofs and been reading about them lately. The actual maths behind them is little difficult to understand so i am reading about their implementations as of now. I guess the best way for me to understand more would be to contribute to such issues so that's why i reached out. Let me know if there's anything you'd like me to do particularly for this one.

Ohh and i'll be coming to devcon also as i got an scholarship from EF to attend. I'll definitely be attending this workshop https://devcon.org/agenda?talk=recHnsoAr2afR4CfJ to know more about zkps.