anwfr commented 6 years ago

Hi, I summarized ZeroLink in one schema, any review welcome. Feel free to use if useful for the project.

zerolink-global

nopara73 commented 6 years ago

Hi @anwfr , this graph was long overdue for me. I never had the time to create it, thank you for that.
A couple of things before I review it:

Would you like to come to slack? If so, send me an email and I invite you. adam.ficsor73@gmail.com
What program did you use to create this? (It'd definitely be a level up to my Paint drawings.) So I'll have the ability to modify it as needed.
I'd like to add it to the paper. Would you create a PR?
There are a couple of things I encountered during implementation. Admittedly I did a rushed job, so I did not figure out an optimal way to handle them, I went with the "good enough" compromise. For the record I drop here some of them:

Maximum Number Of Registered Inputs

Some people will want to register, let's say 300 inputs. It's unlikely, but this can cause the phase never switch from input registration, so there must be a limit. I went with 7 for now (configurable), that felt like a good number.

Too Long Mempool Chain

While it's configurable, but there is a maximum number of transactions that Bitcoin Core accepts into its mempool. This number is 25. As you probably noticed the Tumbler can accept unconfirmed transactions those are spending Tumbler transactions. Now it cannot go like that forever. While one solution could be to elevate the number from 25 to something else, but then double spending would be more likely, because the network propagation would suffer (since normal Bitcoin nodes do not elevate that number.) Again, I'm pretty sure this is not an optimal solution, but what I did is: if the Tumbler notices 24 chained unconfirmed tumbling transactions, it stops accepting new inputs those want to spend Tumbling transactions, until some gets confirmed.

Tumbler Vs Coordinator

It's just a side note: It's better way to call the Tumbler Mix Coordinator. It has less negative connotations and it's also more descriptive. And least, but not least, it's much less provocative, for example if CNN wants to show a screenshot of this software. In the future I'd like to rename this in as many places as I can.

Fees

What fee the Tumbler wants to create the transaction with is kind of a hard problem to figure out. What is the better? If we create with the highest possible fee? (estimatesmartfee 2 CONSERVATIVE) Or we prefer lowest sure fee? What's that anyway? Can even estimatesmartfee 1008 ECONOMICAL or estimatesmartfee 1008 CONSERVATIVE guarantee the tx will confirm? Or just go on the middle and target 144 blocks (one day)? But wait, the tumbling transactions are almost always CPFP transactions. Maybe we can play with it. The first tx would be 1008 target and as new transactions are created they the fees would go up more and more to fee target 2?
Not sure these are hugely important questions, but kind of hard to answer them.

IsStandard()

We must build IsStandard transactions, or else it won't get propagated sufficiently. This means maximum 100KB per transaction and no dust output (4xx satoshi, don't remember exactly).
This of course allows us to not have to define a maximum anonymity set (which I do for sanity check anyway), but rather look for at input registration, estimate the size and if it goes over 100KB the round starts, even if it doesn't reach the anonymity set.

Review

Typo

In Connection Confirmation Phase you wrote thumbler instead of tumbler.

Unblind

You said "unblind signed blinded output with the tumbler public key", but that would mean the tumbler could unblind the it, too, since the tumbler has its public key.
What actually happens is: at input registration we unblind the acquired blinded signature, then verify it against the original data (output).

Tor Hidden Service

You wrote "Tor Hidden Service" for the output registration (which is done by Bob). That'd mean the Alice is not on Tor Hidden Service. This could arguably work, because the identities are separated. However, this way the Tumbler would learn the real IP of Alice (the inputs), which is may be dangerous. I would rather wrote: "through another anonymity network identity". We are not married to Tor.
In the case of Tor, right now we are using different Tor circuits.

Output verification by Tumbler

"Output must not be BIP47", you wrote. Not even sure what that means. Do you mean "it must be bech32"? Because that'd be correct. (For ZeroLink's post mix wallet uniformity requirement).

Tumbler doesn't give txid to Alice

At the end of the graph. Remember, we enable segwit only inputs. This means, the txid won't change after combining the witnesses, so at the point when the Tumbler gives unsigned transaction to Alice, Alice already knows the txid, after signing, Alice has nothing else to do, but to wait for the transaction with that txid. If that doesn't happen, maybe someone did not sign.