Decentralized whirlpool is here!

Today marks a big milestone for Samourai Wallet. They’ve kicked off the process of making whirlpool decentralized. The next update for their Samourai Wallet, Whirlpool, and Dojo software won’t rely on hardcoded coordinator servers anymore. Instead, they’re gonna use the Soroban network for discovering the coordinators.

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.

Since the blog lack many details, i have so many question. For example, is there any mechanism to protect against de anonymization by sybil attack? I also wonder what will developer of wallet which offer Whirlpool feature (e.g. Sparrow Wallet) do.

^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

Good to see them going in that direction. I'm looking forward to see how sybil attacks will be discouraged in the case where the attacker launches (or bribes) a coordinator. At the moment, Whirlpool discourages by not allowing you to select which round to join. Round selection is random. But, this is trust-requiring to Samourai users, as far as I understand. Care to elaborate? The attacker can't remove them from the coinjoin or join a round of their choice. They must keep spending coins until they join the round they want. How is that vulnerable?

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.

In Whirlpool, the coinjoin is consisted of three remixers and two premixers, meaning that for every new coinjoin, two new entrances are required to begin, which will be joined with three already mixed coins. This means that if an attacker wants to de-anonymize a coinjoin, they need to have at least three remixed coins and another premixed coin (in the same round!), so that they can see where the premixer victim's coin ends up. But, to be a premixer you need to pay the entrance fee in each coinjoin, which is quite high to discourage that particular attack. And the more the remixes the honest user does, the more expensive this attack becomes, because the more entrances the attacker has to pay. I don't see how this is vulnerable.

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):

But, far more difficult and expensive the more the victim remixes. Wouldn't it be concerning if it was only one premixer? One remixer isn't going to harm. - If the other four premixed inputs belong to an attacker, then they know the respective remixed UTXO, which isn't crucial in and of itself; it'd be if they could work out the remixed input's past. - If less than four premixed inputs belong to an attacker, then they know even less than that. In other words, it can harm if the remixer has only participated in attacker's coinjoins where there was only one remixer. I was talking about Samourai's coordinator.

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:

Hearing the term Sybil attack for a first time. At first I thought it was some agency that acts against decentralization and had to check over the web. I was first met by, “it’s a Greek girls name” lol,,, but the meaning yo crypto sums up to mean, where a user spontaneously creates false identities to pretend to be other persons on a p2p network. My confusion though, It’s there really much to that, with this being a wallet of some kind. Haven’t completely got an idea about it yet but, i the platform in question would always serve as escrow to whatever transacting that is been done and if that be the case, then there would be little need to worry about the other party’s fulfillment of its end to the bargain. Or am I misunderstanding anything here.

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

Game theory generally implies that if there is a way to profit from cheating a system, someone will inevitably attempt it.  Better to make it as secure as possible and make cheating infeasible.  Limit the temptation for people to try. It's better still to build incentivisation into a system to encourage people to cooperate.  Make the system more profitable to secure than it is to cheat, like satoshi managed to achieve with the alignment of incentives in Bitcoin.  But that's no easy feat to pull off.

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

By the same line of reasoning, JoinMarket and WabiSabi are permissioned, because you need to trust that the coordinator or the offer makers will allow you to join their coins with them. Yes, however, if my understanding is correct, in every coinjoin implementation you'll have to trust the coordinator slightly at least. With maybe Joinmarket being the most resistant among all, due to fidelity bonds. In Samourai, for example, there is structurally enforced liquidity going into a mix, which means one coin in per mix, without mixing with yourself. That is verifiable by the client though (i.e., Sparrow), so you don't need to trust the coordinator. If I'm not mistaken, in Wasabi you can choose which round to join. Isn't that much more prone to sybil attack?

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).

Can't the coordinator simply choose to put me in a round where there is only their and my coins joined? I meant that your premixed coins are not going to be mixed in the same coinjoin. Each premixed coin will be mixed in separate coinjoins. They might share a coinjoin only if they are remixed. However, I don't want to play it smart. I have not studied the whirlpool protocol, and that's all I interpret from simply reading a summary from their Telegram and Twitter accounts.

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 remember, Kruw. I remember very well. Do you? Let's just leave that as is. I really don't want to turn this into another Wasabi thread. You couldn't provide sufficient responses back then, I predict that you can neither do now. That's fine, I guess. There would be a problem if all premixed coins entered the same coinjoin. But, even if it is problematic, Alice can simply refuse to sign the transaction.

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?