nopara73
commented
6 years ago The coordinator can also just simply have like a bunch of keys to sign with and for each session one key is assigned for output denomination. (Not randomly, otherwise the tumbler could cheat.)
In this case the client, when it knows all the outputs can check if the blinded output was signed with the right key or not.
So no need for all this zero knowledge protocol.
Related Issues: https://github.com/nopara73/ZeroLink/issues/73, https://github.com/nopara73/ZeroLink/issues/74, https://github.com/nopara73/ZeroLink/issues/75 Related Question: https://bitcoin.stackexchange.com/questions/73431/mixing-unequal-inputs Non-entropist Approach Measuring Anonymity: https://www.freehaven.net/anonbib/cache/entropist.pdf Knapsack Algorithm: https://www.comsys.rwth-aachen.de/fileadmin/papers/2017/2017-maurer-trustcom-coinjoin.pdf
If optimal algorithm is found CCJ can be extended to handle unequal CJ outputs the following way:
The difference is: Alice doesn't provide change and active CJ outputs right away, rather, the coordinator builds the mix when all the inputs are provided and gives the output amounts to Alice.
Unlike in my sloppy illustration, there are more things are happening here: These output amounts will be paired up with outputs (scriptPubKeys), and these pairs will be blinded one by one.
These pairs then will be sent to the coordinator, the coordinator signs them blindly and send back to Alice along with a flag. The flag tells Alice if she has to unblind and expose the output-value pair to the server or not. If Alice lied and blinded the incorrect amount she'll be banned. The point is: when Alice blinds, she doesn't know if the server will ask for the information back or not. (Mental note: this will result in many unused receive addresses to be generated.)
Finally Alice changes to many Bob identities, unblinds the signatures and proceeds with the CCJ protocol normally.