Thank you waxwing, I added your correction and gave a response in some follow up tweets. https://twitter.com/super_testnet/status/1788287748618723651 I copy/paste my response here: Joinmarket's coordination model is unique and awesome because the coordinator is just one of the people in the coinjoin (the "taker"), changes in ~every round, and does not take a fee -- rather, they pay fees to the makers. I do not like that the coordinator in joinmarket can map everyone's inputs to their outputs. This could be fixed with blind signatures and I am happy to help make this happen if it would be a welcome change in joinmarket. I also do not like that there *is* a coordinator. If it's possible to do this stuff without a coordinator, why have one? A deterministic protocol like emessbee removes variables introduced through the coordination mechanism. And it also might keep some people out of jail til the feds criminalize mere participation too.
Keep in mind that makers are there to earn fees. Any privacy achieved by them is a side effect, it isn't the goal of their participation. Significant changes would have to be made to enforce their privacy. For example, blind signatures wouldn't help if the taker can select only one maker for the coinjoin, since the two outputs that don't belong to the taker belong to the maker. So the minimum number of makers in a transaction would have to be enforced. Having the taker be the coordinator has its advantages. A user that needs to mix their coins can do so any time they want, with any schedule they want. They don't have to wait for enough participants to join or for the round to start. They can even pay someone through a coinjoin, since they choose the amount and destination of the transaction. With Wasabi or Whirlpool, you'd have to use an output from a former coinjoin for the payment, you couldn't start the coinjoin specifically to send the money. See these issues by @Max Hillebrand: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/1192 https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/583
Thanks, and in the spirit of doing something useful and not only complaining, I opened an issue on your coinjoin-workshop repo to get a bit more into the weeds of how blame would work for that kind of protocol.. well, 'useful' might not be the right word but anyway ;)
Can you give a comparison of supernet, joinmarket, samourai whirlpool, wabisabi of wasabi And whether your protocol is decentralised enough with no toxic changes
> Can you give a comparison of supernet, joinmarket, samourai whirlpool, wabisabi of wasabi By "supernet" I assume you mean Emessbee The advantages of Emessbee are: - there is no coordinator, so there is no one to shut down or "leave country X" - due to no coordinator, there is no coordinator fee, so Emessbee is cheaper than alternative coinjoin implementations (except joinmarket, which pays you to coinjoin) Drawbacks compared to Wasabi: Wasabi has no toxic change, Emessbee does Drawbacks compared to Samourai: In Samourai you only pay for your first coinjoin, the other ones are free (for you). In Emessbee you pay for every coinjoin, so over time it's more expensive than Samourai Drawbacks compared to Joinmarket: Joinmarket pays you to coinjoin, Emessbee does not > And whether your protocol is decentralised enough with no toxic changes Emessbee does have toxic change Also worth pointing out: Emessbee is not complete coinjoin software and is not ready for use on mainnet. It only demonstrates that doing a coinjoin without a coordinator is feasible and has significant benefits. IMO the other coinjoin implementations are better than Emessbee (because they are actually ready to use right now) and you should use those, not Emessbee. But I do think it would be good if the other coinjoin implementations "upgraded" to use Emessbee's coordination protocol instead of using a coordinator.