Pages:
Author

Topic: Decentralized whirlpool! (Read 458 times)

member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
April 12, 2024, 11:04:37 PM
#27
Also, the coordinator can select their own remixed coins for free.

Exactly. So in order to Sybil attack Bob for free, the coordinator only needs to compromise the xpub address or IP address of Alice.

So, why not create Charlie, Dave and Eric, to make it seem as if many people are used as premixed inputs?

Why would the coordinator do that?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
April 12, 2024, 04:29:31 PM
#26
You don't think it looks like the coordinator is Sybil attacking Bob using Alice's coins?
If the Samourai coordinator suddenly turned evil, why would it make it apparent that it is sybil attacking? We have previously discussed that in a malicious coordinator scenario, the coordinator is paying themselves, so the coordinator fee does not discourage them from attacking. Also, the coordinator can select their own remixed coins for free. So, why not create Charlie, Dave and Eric, to make it seem as if many people are used as premixed inputs?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
April 12, 2024, 01:07:17 PM
#25
Maybe Alice is online more often than others. Or perhaps it just happened, it's normal to expect that sometimes a user might coinjoin with another more often, because the coordinator is supposedly selecting randomly. So, it's a matter of possibilities. Doesn't seem like the coinjoin is weak, though. Bob is simultaneously coinjoining with other people as well.

You don't think it looks like the coordinator is Sybil attacking Bob using Alice's coins?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
April 12, 2024, 12:58:20 PM
#24
Why is the coordinator continually selecting Alice and Bob to mix with each other?
Maybe Alice is online more often than others. Or perhaps it just happened, it's normal to expect that sometimes a user might coinjoin with another more often, because the coordinator is supposedly selecting randomly. So, it's a matter of possibilities. Doesn't seem like the coinjoin is weak, though. Bob is simultaneously coinjoining with other people as well.

Why don't you ask in their Telegram? I'm not Samourai contributor. Here you go: https://t.me/SamouraiWallet.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
April 12, 2024, 11:39:00 AM
#23
In Samourai, for example, there is structurally enforced liquidity going into a mix, which means one coin in per mix, without mixing with yourself.

Check out these transactions:

- Alice tx0, 25 premix coins created: https://mempool.space/tx/0640bf6524bdf88655e2547685719482aeaf96f28b2a7a2f0666e7f9c9c01fa3
- Bob tx0, 4 premix coins created: https://mempool.space/tx/c9b43c768b70721387dcb43bc7af29b78615c7f2c44585ff185125763f96944d

In 3 out of 4 of Bob's initial mixes, he was coinjoined with Alice:

https://mempool.space/tx/35c06d50fc67c8e7b175ccca4b8a4bd27cdcaed725e7bf12ad209231a4383e93
https://mempool.space/tx/e202645fbff7fe51ea4bfa874b1c4450d41160ff1cae00b63919a3c1b8819fe7
https://mempool.space/tx/8fc7b5b787459ed23ccb55b2dd7ffd87d2caeb6f92332f94d4478309180f884c

Why is the coordinator continually selecting Alice and Bob to mix with each other?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
March 28, 2024, 06:40:50 AM
#22
That's the insufficient response.

How is it insufficient?

It can conclude that Alice is probably remixing in the coinjoin she refused to join, but that's all. The coordinator doesn't know which one is her remixed coin.

As I previously said, I'm not a Whirlpool expert. My insights stem from observations of technically proficient people who discuss Samourai. I don't completely trust Samourai after reading about what's been said and done throughout the years. Usually, people behind Samourai typically refute criticisms of its ineffectiveness. Could you give me an article that would justify your critique on Whirlpool?

Why would I need an article to back up a simple Alice and Bob scenario?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
March 26, 2024, 01:40:47 PM
#21
I responded to that post, how did you miss it?
That's the insufficient response.

Wouldn't the coordinator be able to gain extra information from pairs of inputs that refuse to participate with each other?
It can conclude that Alice is probably remixing in the coinjoin she refused to join, but that's all. The coordinator doesn't know which one is her remixed coin.

As I previously said, I'm not a Whirlpool expert. My insights stem from observations of technically proficient people who discuss Samourai. I don't completely trust Samourai after reading about what's been said and done throughout the years. Usually, people behind Samourai typically refute criticisms of its ineffectiveness. Could you give me an article that would justify your critique on Whirlpool?
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
March 25, 2024, 08:17:31 PM
#20
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?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
March 25, 2024, 06:47:24 PM
#19
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
March 25, 2024, 06:02:02 PM
#18
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?
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
March 25, 2024, 11:04:08 AM
#17
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
March 25, 2024, 10:28:22 AM
#16
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).
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
March 25, 2024, 09:40:09 AM
#15
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?
member
Activity: 112
Merit: 41
March 25, 2024, 07:47:58 AM
#14
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…
legendary
Activity: 3724
Merit: 3063
Leave no FUD unchallenged
March 25, 2024, 07:41:49 AM
#13
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
March 25, 2024, 07:31:55 AM
#12
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.
member
Activity: 112
Merit: 41
March 25, 2024, 07:25:59 AM
#11
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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
March 23, 2024, 09:26:03 AM
#10
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
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
March 23, 2024, 05:47:50 AM
#9
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.

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.
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
March 22, 2024, 05:22:51 PM
#8
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
Pages:
Jump to: