Decentralized whirlpool!

[Medusah]

Today is a special day for Samourai Wallet.  They took the first step towards decentralizing whirlpool^[1].  There will be no more hardcoded coordinator servers in the upcoming version of their Samourai Wallet, Whirlpool and Dojo software.  The Soroban network will be used for coordinator discovery. 

[1]: https://blog.samourai.is/decentralized-whirlpool-stage-1/

[1714243110]

1714243110

[1714243110]

1714243110

[1714243110]

1714243110

[FinneysTrueVision]

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.

[ABCbits]

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.

[Kruw]

Having multiple coordinators is meaningless if Samourai is still running all of them.

^This.

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

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.

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

[BlackHatCoiner]

Good to see them going in that direction.

For example, is there any mechanism to protect against de anonymization by sybil attack?

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.

Whirlpool is uniquely vulnerable to Sybil attacks since the attack victims pay the mining fees of the attacker.

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?

[Kruw]

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.

[BlackHatCoiner]

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.

[Kruw]

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.

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

But, to be a premixer you need to pay the entrance fee in each coinjoin, which is quite high to discourage that particular attack.

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

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.

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

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

[BlackHatCoiner]

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

But, far more difficult and expensive the more the victim remixes.

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

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.

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

I was talking about Samourai's coordinator.

[Kruw]

But, far more difficult and expensive the more the victim remixes.

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.

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 just providing an example transaction that didn't fit your initial description, it's not a factor in this topic specifically.

I was talking about Samourai's coordinator.

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:

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

[JiiBs]

Good to see them going in that direction.

For example, is there any mechanism to protect against de anonymization by sybil attack?

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.

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.

[Kruw]

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.

[DooMAD]

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.

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.

[JiiBs]

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…

[BlackHatCoiner]

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.

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.

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.

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?

[Kruw]

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.

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

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.

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.

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.

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.

If I'm not mistaken, in Wasabi you can choose which round to join. Isn't that much more prone to sybil attack?

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

[BlackHatCoiner]

You don't have to trust the coordinator in WabiSabi.

Can't the coordinator simply choose to put me in a round where there is only their and my coins joined?

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

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.

[Kruw]

Can't the coordinator simply choose to put me in a round where there is only their and my coins joined?

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?

Could you explain how the Sybil attack will be detected?

Yes:  You try to register a private coin in the same round as your non private coin that is the supposed target of the attack.  If your private coin isn't denied, then the round is not under a Sybil attack.

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.

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?

[BlackHatCoiner]

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?

I remember, Kruw. I remember very well. Do you?

It obviously can't. If your coins are refused, you have no idea if it is due to Sybil attack or if Coinfirm has simply decided your coins are naughty and are not allowed to be coinjoined.

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.

Let's say the coordinator selects both C and D, (both owned by Alice) for the same coinjoin round. How should she respond?

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.

[Kruw]

I remember, Kruw. I remember very well. Do you?

It obviously can't. If your coins are refused, you have no idea if it is due to Sybil attack or if Coinfirm has simply decided your coins are naughty and are not allowed to be coinjoined.

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

It obviously can't. If your coins are refused, you have no idea if it is due to Sybil attack or if Coinfirm has simply decided your coins are naughty and are not allowed to be coinjoined.

You would know because the coin is private, therefore it can't be refused due to its history.

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.

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