Discussing a few extensions of the above protocol.
Outsourceable mixing
Observe that the mix can be done by a 3rd party, not necessarily the owner of a mix box.
This allows us to design more traditional mixers in a non-custodial manner. The mix will be done as follows:
- Create a mix box and add it to the pool
- Send the box id along with processing fee to a mixer.
This allows us to elegantly handle fee as well; the fee is simply paid by the 3rd party mixer from an independent pool of funding boxes, unrelated to the owners of the mix-boxes.
To avoid the bottleneck of depending only on a single mixer, we could use several of them in succession, hoping that at least one of them will provide privacy.
The positives of using a mixer is:
- A mixer can plan the sequence of transaction as they have bigger picture of the participants. Thus an honest mixer will provide stronger anonymity than mixing by self.
- Handling mining fee becomes very easy when using a mixer. The alternative approach, followed in ErgoMix uses mixing tokens which is a fairly complex mechanism involving several smart contracts interacting with each other.
One problem we have with this solution is the mixer can lose track of the box being mixed. Since anyone has the ability to mix, while a box is being processed by a mixer, another user may spend the same box, after which the mixer will lose track of the box to process (it can only guess with 50% chance assuming DDH is hard). To overcome this, we can put a time-lock in the box that allows the mixer to spend the box immediately and anyone else after a timeout. The mixer is determined by a group element (public key) stored in R6, which can be different in each mix for stronger privacy.
so the condition for mix will be something like
validW && validOuts && (proveDlog(r6) || HEIGHT > timeOut)