Todo el mundo puede tener conjeturas pero si no se demuestran caen en saco roto. El coordinador de Whirlpool es ciego, de hecho esta basado en las firmas ciegas de Chaum, puedes revisar el código para eso es open source. Cuando un usuario mezcla, cada una de las entradas que entran al mix van a diferentes ciclos, nunca se juntan (si en Wasabi y JM). Y no hay ningún dev seleccionado que utxos entran en que mezcla a su gusto.

En cuanto al cliente, todas las wallets móviles conectan by default a sus servers, por que si no un user sin servidor propio no podría usar ninguna wallet entonces. SW y Sparrow te van a preguntar antes que quieres hacer, si conectarlo a tu server o a los suyos o propuestos. De hecho aquellos users que mezclan sin conectar a su propio nodo se desmotivan ya que tienen bastantes problemas de conexión en segundo plano. De hecho la mayoria usan su server propio. El proceso de remix y el cliente de Sparrow mitiga el en el caso de que SW fuera un "honeypot" y tuviera información deesea minoría sin server

Cuando se habla de coinjoins está bien siempre revisar la técnica del mismo y no basarse en emociones. Me gustaría haber leído mas acerca de un análisis objetivo por tu parte.

Puntos débiles que deben ser mitigados: pasar de tx0 a multitx0 para romper la heurística de propiedad de entradas y descentralizar coordinadores (uno por server). Ambas están en proceso de implementarse. Uno de sus puntos fuertes son las herramientas de gasto para salir del cj y un alto anón set gracias a ser un cj determinista. Si medimos de forma objetiva la entropía por utxo obtenida se obtiene un resultado mayor a 1. Ningún otro cj llega a esos valores.

De Wasabi, obviando lo evidente y enfocándome en la técnica, diría que no sabes el resultado que vas a obtener pudiendo obtener muchas salidas de poca cantidad (véase issues en su github). A parte se siguen reusando direcciones y el gasto es a través de tx simples. Los remixes se pagan y se notan, sobre todo ahora.

Joinmarket.

Que sea descentralizado en cuanto a red es un punto fuerte. Pero dejar la coordinación del cj a un usuario no es la mejor opción. Ya sabemos los errores que comentemos los usuarios. Y como bien dices, una mezcla como taker no aporta nada de privacidad (dicho por Belcher y verificado por mi mismo). La pregunta es, si un single cj como taker no aporta privacidad prospectiva, por que combinar entre taker y maker y no ser solo maker?

Hay muchos users haciendo single cj como taker sin saber que no están ganando privacidad, aunque es beneficioso para los makers. Luego como maker tienes que estar atento todo el tiempo y gestionar utxos tóxicos. Se que muchos users seleccionan esos cambios juntos para hacer cj como taker rompiendo así gran parte de lo ganado. Un tumbler si hubiera incentivo se podría deshacer, ya que es una combinación de varios single cj. Recomiendo el informe de Ergo sobre JM y como se pudo desanonimizar a un user que alternaba entre taker y maker. Si quieres beneficiarte sé maker y haz toda la gestión que requiere para mantener lo ganado. El sistema esta descompensado mucho maker y poco taker

Como ves esto es un análisis técnico sin basarse en teorías. Esta bien siempre conocer y probar todas lasimplementaciones para poder hablar con mas criterio. Aquí un usuario que prueba y conoce todos los coinjoins a parte de otras opciones como LN.

No hay balas de plata en cuanto a privacisad, si no herramientas mas o menos eficaces dependiendo de la situación.

Por cierto no creo en sistemas donde cedamos la custodia a otros o dependamos de una federación. Seria ir para atrás.