Currently the coordinator learns which specific utxo is being registered as input, there's even a signature over a challenge message to prove knowledge of the private key.

You might consider to somehow blind this, maybe by using ring signatures or a full zero knowledge proof, but this is both technically difficult, and also removes numerous important features that the coordinator provides:

If an input fails to sign a coinjoin, then it is put on a blacklist, removed from the upcoming blame round, and sometimes even blocked from future rounds as well. This ensures uptime of the service in an adversarial environment with denial of service attacks. If the coordinator can no longer do blame attribution because the utxo is blinded, then clients have to deal with it, bringing us back to implementing a decentralized consensus of blame attribution and transaction creation.

The coordinator also checks if the input comes directly or one hop from a coinjoin output in order to charge no coordinator fees. If we would blind the input registration, this fee insentive is no longer possible, or at least super complicated.

Of course if the coordinator knows which utxo is registered, he can also check non-blockchain databases for arbitrary metadata checks. This enables invite only coordinators, or coordinators that blacklist bad actors.

I don't see any obvious technical feasibility of fully blinding input registration, and even if it were possible, lots of features would fall apart.

But notice that even if we would have a usable decentralized coinjoin coordination protocol, building that in a way that input utxos are blinded from the participants is impossible. In that case the end users are those that can do metadata checks and not sign any transaction containing certain utxos.

The solution I see is a free market of coordination service providers with different policies and conditions. The barriers to entry are rather small, the biggest issue is to bootstrap liquidity.

Reply to this note

Please Login to reply.

Discussion

No replies yet.