So I searched 'joinmarket' on birdsite and found some interesting discussions.

nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s I want to take issue with something you wrote: "In contrast, the coordinators in samourai/wasabi/joinmarket interact with the other users, creating/sharing psbts, validating info, kicking trolls out, and taking fees".

Note that (and this is common to other of your posts there) you're referring to Joinmarket as a protocol with a coordinator, because the taker is the coordinator for each coinjoin that it wants to do; but please realize that almost every person reading this will not grok the subtlety. To them a coordinator is a static coordinator. Also you say at the end "taking fees" and this is *in no possible way* a correct description of Joinmarket, since even if you treat the taker as "one time coordinator" (correct), they pay fees, they do not take them. Considering the sensitivity of this issue I *really* don't think it's OK to write that, since it's not true.

The whole paragraph *strongly* suggests that Joinmarket uses the same model as the other two, whereas in fact it's almost purely p2p, especially in the recent structure where directory nodes act only as name servers essentially, and peers then negotiate coinjoins over their own ephemeral onion services.

(Taker/maker is not a static role and in fact it's good for people to switch between them).

Reply to this note

Please Login to reply.

Discussion

What are the benefits of swapping between maker taker as per your very last point? I've not considered that before...

Improved privacy

I figured that was why, but I don't understand why?

There are some (unreliable, but still) heuristics one could use to tell takers and makers apart. For example, if the money sits dormant for a long time without entering new coinjoins, it's unlikely to belong to a maker. Switching roles defeats those heuristics. See this issue for more info: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/948.

As a maker you earn fees, and your coins go through a bunch of coinjoins at random times and for random amounts. What you cannot do as a maker is to send a specific amount to a specific destination in a coinjoin. You need to become a taker to do that.

Mixers are great! I’ll tell you what’s even better?

Non-KYC sats by default. Send me a message if you live in London and would like to trade.

taker/maker either/or

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 nostr:npub1klkk3vrzme455yh9rl2jshq7rc8dpegj3ndf82c3ks2sk40dxt7qulx3vt:

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.

Nice 👍