Wasabi Wallet - Open Source, Noncustodial Coinjoin Software

[Wind_FURY]

The same argument. If a coordinator doesn't have the reputation to attract enough users to put enough volume/liquidity into the coordinator then it can be sybil attacked by bad actors, and essentially make it function like their own honeypot. It's not a flaw in the coordinator, I'm merely saying that  low liquidity = less effective CoinJoins.

Sure, more liquidity is absolutely an advantage when defending against a Sybil attacker. The minimum input count of the round is known ahead of time, so you can avoid choosing a coordinator that provides an inefficient/insecure service.

You're actually right! That's why, after closing zkSNACKS' coordinator, it might take some time before another coordinator will gain enough reputation for it to gain enough trust from the community, and therefore gain the liquidity to give an efficient and secure service.

I'm curious about new coordinators, they do need to bootstrap the service with their own liquidity, no?

[Kruw]

You're actually right! That's why, after closing zkSNACKS' coordinator, it might take some time before another coordinator will gain enough reputation for it to gain enough trust from the community, and therefore gain the liquidity to give an efficient and secure service.

You don't have to trust coordinators, there's no reputation required.

I'm curious about new coordinators, they do need to bootstrap the service with their own liquidity, no?

No. Coinjoins are made of user inputs.

[Wind_FURY]

You're actually right! That's why, after closing zkSNACKS' coordinator, it might take some time before another coordinator will gain enough reputation for it to gain enough trust from the community, and therefore gain the liquidity to give an efficient and secure service.

You don't have to trust coordinators, there's no reputation required.

I'm curious about new coordinators, they do need to bootstrap the service with their own liquidity, no?

No. Coinjoins are made of user inputs.

But if a coordinator doesn't accumulate enough liquidity, then like you posted, it would be less secure, inefficient, and therefore a less effective way to CoinJoin outputs.

Plus, I know the liquidity pool is supposed to be made of user inputs, but if not many users actually want to use the coordinator, then there should probably be a bootstrapping process during the start, no?

[Kruw]

But if a coordinator doesn't accumulate enough liquidity, then like you posted, it would be less secure, inefficient, and therefore a less effective way to CoinJoin outputs.

Yes, bigger coinjoins are more efficient than smaller coinjoins.

Plus, I know the liquidity pool is supposed to be made of user inputs, but if not many users actually want to use the coordinator, then there should probably be a bootstrapping process during the start, no?

The coordinator can participate in their own coinjoins of course, but they still only count as 1 user.

[Wind_FURY]

But if a coordinator doesn't accumulate enough liquidity, then like you posted, it would be less secure, inefficient, and therefore a less effective way to CoinJoin outputs.

Yes, bigger coinjoins are more efficient than smaller coinjoins.

That's probably why the "reputation" of the coordinator matters, especially if the individual who bootstrapped it is an anonymous. But it would probably help if he/she is a known entity in the community.

Plus, I know the liquidity pool is supposed to be made of user inputs, but if not many users actually want to use the coordinator, then there should probably be a bootstrapping process during the start, no?

The coordinator can participate in their own coinjoins of course, but they still only count as 1 user.

I have a question, what if the entity that started the coordinator started bootstrapping it by using different wallets, pretending they're owned by different individuals, but with honest intentions?

[Kruw]

That's probably why the "reputation" of the coordinator matters, especially if the individual who bootstrapped it is an anonymous. But it would probably help if he/she is a known entity in the community.

How many times do I have to repeat this: You do not trust coordinators, so there's no reputation required.

I have a question, what if the entity that started the coordinator started bootstrapping it by using different wallets, pretending they're owned by different individuals, but with honest intentions?

Then they would be spending an enormous amount in fees to only create superficial results. Whether the intention is honest or not, this behavior is indistinguishable from a Sybil attack.

[PrivacyG]

How many times do I have to repeat this:

Probably until you finally realize your own stupidity,

You do not trust coordinators, so there's no reputation required.

more liquidity is absolutely an advantage when defending against a Sybil attacker.

you can avoid choosing a coordinator that provides an inefficient/insecure service.

Read the three quotes again.

And again.

And again!

Now explain this, smarty.

If there was no need for Trust, I would be able to join ANY COORDINATOR blindly.  If I open up Bisq, I can choose to work with ANY BODY, good or bad simply because no matter how things go, either the Transaction happens the right way or if any of the Parties does not fulfill their obligations, the other gets compensated.

I can not open up a list of Coordinators, pick one and roll with it carelessly.  I have to CHOOSE ONE.  I need to TRUST ONE.  Otherwise I can join one that may or may not Sybil attack me.

Bisq.  No matter what any of the Party does, they can not Scam you out or play against the rules.

Wasabi Coordinator.  You have to choose a Coordinator that will most likely not Scam you, according pretty much to your own subjective calculations which can never be perfect.

[Kruw]

If there was no need for Trust, I would be able to join ANY COORDINATOR blindly. 

Exactly. That's how trustless Wasabi is 

[BlackHatCoiner]

Wasabi Coordinator.  You have to choose a Coordinator that will most likely not Scam you, according pretty much to your own subjective calculations which can never be perfect.

It's pretty simple. WabiSabi is trust-requiring, because you need to trust that the coordinator will not turn evil and attack their own users. It's literally written in their whitepaper:

An attacker attempting to Sybil attack all CoinJoins would need to control some multiple of the combined Bitcoin volume contributed by honest participants, and to successfully partition honest participants to a sufficient degree. [...] However, this does not protect against a malicious coordinator which is only bound by liquidity and mining fees.

Following the next paragraph, we can see there are other attacks it can execute as well:

A malicious coordinator may tag users by providing them with different issuer parameters. When registering inputs a proof of ownership must be provided. If signatures are used, by covering the issuer parameters and a unique round identifier these proofs allow other participants to verify that everyone was given the same parameters.

A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks. In the worst case, the coordinator can attempt to linearize all requests by delaying individual to recover the full set of labelled edges. This is possible when k = 1 and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner

Similarly the coordinator may delay information such as the set of ownership proofs or the final unsigned transaction. In the case of the latter, this can be used to learn about links between inputs. This is because a signature can only be made after the details of the transaction are known. If the unsigned was only known to one user but multiple inputs have provided signatures, it follows that those inputs are owned by the same user.

Then, it probably wanted to say "the coordinator must be trusted":

Since the coordinator must trusted with regards to denial of service a more practical variant of this attack would involve more subtle delays followed by sabotaging multiple successive rounds during the signing phase in order to learn of correlations between registrations while maintaining deniability.

It can attack with Sybil attack. It can attack otherwise too. Perhaps Kruw interprets "trustless" differently than the rest of us. This wouldn't surprise me, considering I've been questioned about my choice of words when speaking with him before.

[Kruw]

An attacker attempting to Sybil attack all CoinJoins would need to control some multiple of the combined Bitcoin volume contributed by honest participants, and to successfully partition honest participants to a sufficient degree.

How did you miss the part about the liquidity and partitioning requirements?

A malicious coordinator may tag users by providing them with different issuer parameters. When registering inputs a proof of ownership must be provided. If signatures are used, by covering the issuer parameters and a unique round identifier these proofs allow other participants to verify that everyone was given the same parameters.

As noted, you can register multiple inputs with WabiSabi to verify that the parameters match each other.

A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks. In the worst case, the coordinator can attempt to linearize all requests by delaying individual to recover the full set of labelled edges. This is possible when k = 1 and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner.

As noted, clients would be able to detect this and defeat it by disallowing arbitrary timeouts.

Similarly the coordinator may delay information such as the set of ownership proofs or the final unsigned transaction. In the case of the latter, this can be used to learn about links between inputs. This is because a signature can only be made after the details of the transaction are known. If the unsigned was only known to one user but multiple inputs have provided signatures, it follows that those inputs are owned by the same user.

If I understand it correctly, this is handled by using a different Tor identity for listening to round updates than the Tor identities you register inputs with.  Because the coordinator does not know which Tor identity is listening for which inputs, they do not know who to target with this delay.

Since the coordinator must be trusted with regards to denial of service a more practical variant of this attack would involve more subtle delays followed by sabotaging multiple successive rounds during the signing phase in order to learn of correlations between registrations while maintaining deniability.

Clients abandon rounds after multiple successive failures as a basic way to prevent this.

[PrivacyG]

It can attack with Sybil attack. It can attack otherwise too. Perhaps Kruw interprets "trustless" differently than the rest of us.

Call it misleading.  Or, deception.  Or since we all here likely know about Orwell, call it doublethink,

Doublethink is a process of indoctrination in which subjects are expected to simultaneously accept two conflicting beliefs as truth, often at odds with their own memory or sense of reality.[1] Doublethink is related to, but differs from, hypocrisy.

Source https://en.wikipedia.org/wiki/Doublethink

A Coordinator, according to Kruw,
Requires Trust but it is Trustless.

For a Coordinator to function morally correct, according to Kruw,
Censorship is needed but unnecessary.

And finally from the early pages of dystopian 1984,

War is Peace.

I find it such a big irony that I can talk about 'the One Solution to Privacy' Wasabi using quotes out of a dystopian novel.  Weird and creepy if you ask me.

[NotATether]

I find it such a big irony that I can talk about 'the One Solution to Privacy' Wasabi using quotes out of a dystopian novel.  Weird and creepy if you ask me.

As of three days from now, it's not even going to be the One Solution to Privacy anymore. There's literally just going to be Kruw's coordinator left, unless someone else on Twitter ran another which I'm not aware of.

[Kruw]

A Coordinator, according to Kruw,
Requires Trust but it is Trustless.

I've been explicitly clear that no trust is required in coordinators:

You don't have to trust coordinators. There's no reputation required.

Read what I said again: You don't have to trust coordinators. There's no way to create a "honeypot".

You don't need any reputation because coordinators are not trusted.

You don't have to trust coordinators, there's no reputation required.

How many times do I have to repeat this: You do not trust coordinators, so there's no reputation required.

How are you still not able to understand this? What part of this is not clear to you?

[Wind_FURY]

A Coordinator, according to Kruw,
Requires Trust but it is Trustless.

I've been explicitly clear that no trust is required in coordinators:

But high liquidity is required to make it more effective, secure, and more resistant to Sybil Attacks. And how does it achieve a state of high liquidity? Reputation, and I'm sorry Kruw, but it needs a little "trust" from the users or else they won't send their outputs to the coordinator, and therefore might not have the required liquidity.

Technically, yes the system is trustless. But we're talking about the social trust required if to use the system or not. It's like those normies who question the feasibility of Bitcoin because "Satashi might come back and change the algorithm".

[BlackHatCoiner]

Orwell, call it doublethink,

Doublethink is a process of indoctrination in which subjects are expected to simultaneously accept two conflicting beliefs as truth, often at odds with their own memory or sense of reality.[1] Doublethink is related to, but differs from, hypocrisy.

No, he knows very well what's going on. He's just probably financially associated with Wasabi, and desperately needs to protect it. This explains his mania to direct people to Wasabi on nearly every post of his, or the diplomatic responses on zkSNACKs using coinjoin fees to fund a surveillance firm. He hesitated even commenting on that decision, even though WabiSabi is open-source and not strictly related with zkSNACKs.

However, I think he's right about the Sybil resistance. If you truly register each input with a separate Tor identity, then it's easy for the client to detect that the coordinator is Sybil attacking. I'm not totally sure, but confident enough. And I'm not sure the Wasabi client checks for all these things, but in theory, it is Sybil resistant.

The only thing I find difficulty understanding is when listening for round updates. For example, can't the coordinator initiate different rounds in which they continuously use their inputs and only few of the registered inputs each time? For example:

- Alice registers 10 inputs.
- Bob registers 2 inputs.
- Charlie registers 3 inputs.

David (the coordinator) receives 15 inputs that want to be coinjoined. He initiates 15 coinjoins, each of which contains 14 of his inputs and one of the 15 of the registered inputs, resulting in de-anonymization. Why can't this occur?

[Kruw]

But high liquidity is required to make it more effective, secure, and more resistant to Sybil Attacks. And how does it achieve a state of high liquidity? Reputation, and I'm sorry Kruw, but it needs a little "trust" from the users or else they won't send their outputs to the coordinator, and therefore might not have the required liquidity.

I don't know how many times I have to continue informing you that there is no "trust" required. You don't send outputs to the coordinator, your coins don't move at all unless the coinjoin succeeds.

Technically, yes the system is trustless. But we're talking about the social trust required if to use the system or not. It's like those normies who question the feasibility of Bitcoin because "Satashi might come back and change the algorithm".

Satoshi can't change the code running on your node. You don't have to trust him at all.

The only thing I find difficulty understanding is when listening for round updates. For example, can't the coordinator initiate different rounds in which they continuously use their inputs and only few of the registered inputs each time? For example:

- Alice registers 10 inputs.
- Bob registers 2 inputs.
- Charlie registers 3 inputs.

David (the coordinator) receives 15 inputs that want to be coinjoined. He initiates 15 coinjoins, each of which contains 14 of his inputs and one of the 15 of the registered inputs, resulting in de-anonymization. Why can't this occur?

This can't occur because users choose their own round. There would be no reason for a coordinator to run multiple rounds in parallel unless there's a MASSIVE amount of liquidity trying to register at the same time (for example, zkSNACKs splits into 2 rounds if over 400 inputs try to register to the same round).

[Wind_FURY]

But high liquidity is required to make it more effective, secure, and more resistant to Sybil Attacks. And how does it achieve a state of high liquidity? Reputation, and I'm sorry Kruw, but it needs a little "trust" from the users or else they won't send their outputs to the coordinator, and therefore might not have the required liquidity.

I don't know how many times I have to continue informing you that there is no "trust" required. You don't send outputs to the coordinator, your coins don't move at all unless the coinjoin succeeds.

I'm sorry if you can't get the context of the simple point I'm making. But a coordinator won't miraculously have millions in liquidity simply because it went online.

Technically, yes the system is trustless. But we're talking about the social trust required if to use the system or not. It's like those normies who question the feasibility of Bitcoin because "Satashi might come back and change the algorithm".

Satoshi can't change the code running on your node.

He can't, but some normies won't use it because they don't "trust" the trustless system.

[Kruw]

I'm sorry if you can't get the context of the simple point I'm making. But a coordinator won't miraculously have millions in liquidity simply because it went online.

This point doesn't change the trust model.

He can't, but some normies won't use it because they don't "trust" the trustless system.

It's a good thing that the opinions of normies don't matter.

[BlackHatCoiner]

This can't occur because users choose their own round.

Can I verify everything you've presented in this thread in Wasabi client? I'm curious. For example, I had used Wasabi when reviewing it, and I don't remember it allowed me to choose my own round.

I'm sorry if you can't get the context of the simple point I'm making. But a coordinator won't miraculously have millions in liquidity simply because it went online.

No matter how many times he repeats it, running a coordinator in the right way, isn't simple to do. To have coinjoin participants, you need liquidity, otherwise you're not attractive. It's like being a maker in Joinmarket, but takers need to manually type your URI.

[Kruw]

Can I verify everything you've presented in this thread in Wasabi client? I'm curious. For example, I had used Wasabi when reviewing it, and I don't remember it allowed me to choose my own round.

Choosing the round isn't manual when there's multiple, it's done automatically based on the round parameters. If a coordinator is running many rounds in parallel with low minimum input counts/fast input registration timeouts, you should already be avoiding them altogether since their config isn't making good use of scarce block space.