If they truly intend to make Whirlpool coordination decentralized then it is a step in the right direction. The blog they posted doesn’t have much details about how everything will eventually work. Having multiple coordinators is meaningless if Samourai is still running all of them. This is only the initial phase though so we’ll have to wait for further developments to see how decentralized this will actually be.

^This.

The decentralization of WabiSabi coinjoin coordination is ahead of this already since Nostr is used for discovering new coordinators.


Whirlpool is uniquely vulnerable to Sybil attacks since the attack victims pay the mining fees of the attacker.  JoinMarket has a mechanism to prevent Sybil attacks called "Fidelity Bonds", see https://reyify.com/blog/poodle and https://github.com/JoinMarket-Org/joinmarket/issues/156

It doesn't matter whether the attacker is able to choose their round since there's no additional cost to participate in a remix, all rounds the attacker is chosen to participate in adds to their data set.

Exactly. The extra small round sizes in Whirlpool makes it far easier to attack than coinjoins that include hundreds of coins into one round.

There can be only 1 user remixing btw - https://mempool.space/tx/3cef999a3c006be772f7f63fc87b718cd01146ab593644e0eeb3d61e753f02b8


This fee does nothing when the attacker is also the coordinator.


Did you read about JoinMarket's fidelity bonds? It explains how to defend against a Sybil attacker who gets to remix for free (or in JM's case, for profit):

Exactly. Unlike the WabiSabi and JoinMarket protocols which allow you to remix as much as you want, remixing in Whirlpool is permissioned:  You have to trust the coordinator will eventually choose you.


I was just providing an example transaction that didn't fit your initial description, it's not a factor in this topic specifically.


Right. The cost of the coordinator fee does not provide a defense against a coordinator Sybil attacking their own round since they are paying themselves. However, mining fees do provide a defense against coordinators Sybil attacking their own round since they are consumed by an external party.

I would encourage you to read about how JoinMarket addresses the possibility of Sybil attacks being conducted by remixers:

Coinjoins are already non custodial, so an escrow doesn't do anything here.

Looked up for coinjoin and it translates to mean, having multiple users putting in there coins and have it mixed up with the service here being the mixing of several users coin in addresses to get out same value and promote anonymity in the process.

Hence, the service as described in OP is more about, the said platform having to integrate from a centralized means to coinjoin which might run into trouble due to some user's downtime to a more decentralized means of operation where some algorithm will make necessary adjustments for downtimes and continue the process of coinjoin with other available users.

Sure am on track with this…

It's not the same, remixers are *required* to wait in Whirlpool since their fees are paid by new entrants, a remixed output can't afford to pay another mining fee because then the output would drop below the fixed 0.5/0.05/0.01/0.001 pool size. WabiSabi and JoinMarket allow you to remix at any time (JoinMarket takers can remix immediately, WabiSabi at the end of the coordinator's round timer).


You don't have to trust the coordinator in WabiSabi. You gain no privacy against the coordinator (taker) as a JoinMarket maker. JoinMarket takers, who are their own coordinator, don't have to trust makers thanks to fidelity bonds.


This doesn't have anything to do with the coordinator.

However, explain why wouldn't Alice double register ("Mix with herself") in this scenario?

- Alice creates premix inputs A, B, C.
- The first round creates postmix outputs D, E, F,
- After waiting, D, E, F, all remix creating G, H, I,
- When waiting for further remixing, let's say the coordinator selects both G and H, (both owned by Alice) for the same coinjoin round. Alice has an incentive to register both.


All participants join the same round, there's no choosing (under normal conditions).

There's no trust required since you would be able to detect this because the coordinator would have to block all other inputs from joining. We already discussed this, remember?



Okay, how about this scenario?

- Alice creates premix input A
- The first round creates postmix output B
- After waiting, B remixes creating C
- Alice creates premix input D
- Let's say the coordinator selects both C and D, (both owned by Alice) for the same coinjoin round. How should she respond?

I responded to that post, how did you miss it?



Wouldn't the coordinator be able to gain extra information from pairs of inputs that refuse to participate with each other?