Pages:
Author

Topic: Is a "safely compliant" (semi-)centralized CoinJoin service possible? (Read 459 times)

member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Are you seriously contending that in a WabiSabi coinjoin, two parties merging their coins have the required program set up to effectively communicate?

I'm communicating to you using Bitcointalk aren't I? Why would you think that two people communicating with each other is impossible given the fact that we are communicating with each other right now?
sr. member
Activity: 364
Merit: 300
Thanks, I'm glad I proved that any two people can connect to the same coordinator and verify with each other they are participating in the same round. I don't know how you could possibly reason your way into concluding that anyone can't easily do this.

Are you seriously contending that in a WabiSabi coinjoin, two parties merging their coins have the required program set up to effectively communicate?  And even if they do and communicate to "ensure" they're not subjected to a sybil attack (lmao, "trust me, I am not attacking you"), it still remains an entirely trustless process.  Roll Eyes

As I said, top-tier level of argumentation.  
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Top-tier level of argumentation.  You should be proud of yourself. 

Thanks, I'm glad I proved that any two people can connect to the same coordinator and verify with each other they are participating in the same round. I don't know how you could possibly reason your way into concluding that anyone can't easily do this.
sr. member
Activity: 364
Merit: 300
Yes you can.

Top-tier level of argumentation.  You should be proud of yourself. 
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
You cannot interact with anyone in a coinjoin

Yes you can.
legendary
Activity: 990
Merit: 1108
Are you equating N to the number of servers in each set or is N equal to the amount of organizations?  Huh
One coinswap service is offered by N organizations each employing one server.
Even if 51% of N are colluding, they would learn nothing about any coinswap they choose to complete. The worst that can happen is one server going down and the protocol cannot complete.

Then there could be multiple coinswap services being offered, each with its own set of organizations.

That sounds pretty decentralized to me.
sr. member
Activity: 364
Merit: 300
No it doesn't. You can interact with anyone.

You cannot interact with anyone in a coinjoin, and even if you could, it would no longer be trustless.  Let me pose the question again:  If Alice refrains from interacting with any other coinjoin participant, as is typically expected, can she discourage the coordinator from sybil attacking her?  From what I can see, she cannot.  Hence, WabiSabi remains highly susceptible to sybil attacks (launched by the coordinator). 
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Your "solution" relies on Alice interacting with strangers

No it doesn't. You can interact with anyone.
sr. member
Activity: 364
Merit: 300
In this incredibly far fetched scenario, Alice can ask Bob or Charlie to verify they are able to join the same round.

There's nothing implausible here.  I'm presenting a realistic scenario where the coordinator operates under chain analysis without Alice, Bob, and Charlie knowing.  It's entirely feasible for a chain analysis company to trace Alice's inputs and launch a sybil attack against her. 

Your "solution" relies on Alice interacting with strangers, and it still doesn't address the core issue.  The coordinator could use the excuse that their round was already full before Bob and Charlie requested their coins to be combined, or they could claim they 'randomly' assigned Alice to a separate round from Bob and Charlie. 
legendary
Activity: 2282
Merit: 2057
A Bitcoiner chooses. A slave obeys.
There is no such thing as "semi" centralized. Either it is centralized or not.
Then please tell us: if mixing is done by a set of N servers each with its own published public key, and belonging to N different organizations from all over the world, then for which values of N is it centralized, and for which is it not?

Assume that mixing is done in such a way that privacy is compromised only if all N servers collude.



Are you equating N to the number of servers in each set or is N equal to the amount of organizations?  Huh

But if you want my own personal benchmark, then let me give you a percentage: 51%. As long as the 51% attack is achievable, or in this case, 51% of servers are under control of one entity (government), I do not consider the service as decentralized.
legendary
Activity: 990
Merit: 1108
There is no such thing as "semi" centralized. Either it is centralized or not.
Then please tell us: if mixing is done by a set of N servers each with its own published public key, and belonging to N different organizations from all over the world, then for which values of N is it centralized, and for which is it not?

Assume that mixing is done in such a way that privacy is compromised only if all N servers collude.
legendary
Activity: 2282
Merit: 2057
A Bitcoiner chooses. A slave obeys.
There is no such thing as "semi" centralized. Either it is centralized or not. And I would never trust any kind of centralized platform or service. And furthermore, regulations change with time, how will such a service update its compliance without a centralized entity governing responsibility?

member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
This assumes that the coordinator isn't analyzing the blockchain.  It's plausible that the coordinator is fully aware of the inputs belonging to Alice, Bob, and Charlie.  

What if her additional inputs aren't denied access?  What if the coordinator has scrutinized her and can identify which of the requested coins belong to her?  What if the coordinator declines to coinjoin any other input?  Wouldn't that expose her anonymity without her knowledge?  

In this incredibly far fetched scenario, Alice can ask Bob or Charlie to verify they are able to join the same round.
sr. member
Activity: 364
Merit: 300
The coordinator is not able to determine that E, F, and G do not belong to Alice.

This assumes that the coordinator isn't analyzing the blockchain.  It's plausible that the coordinator is fully aware of the inputs belonging to Alice, Bob, and Charlie. 

If Alice sees her other inputs are refused entry, then she can detect the coordinator targeting input A.

What if her additional inputs aren't denied access?  What if the coordinator has scrutinized her and can identify which of the requested coins belong to her?  What if the coordinator declines to coinjoin any other input?  Wouldn't that expose her anonymity without her knowledge? 
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
Okay, I grasp the concept more clearly now.  Fidelity bonds come into play when there are takers and makers, such as in Joinmarket.  The method to establish provable identities within a decentralized network involves locked value.  An attacker cannot generate identities without first paying the corresponding amount of money.  In WabiSabi, this process isn't necessary because there are no distinct roles of takers and makers; each participant pays for their own inputs and outputs.  Correct?  

Mostly correct. Fidelity bonds are optional, so you can still generate as many identities as you want, it's just they won't be prioritized as often by takers.

I still don't get how this stops sybil attacks or makes them less likely.  Imagine Alice registers input A, and the coordinator registers their own inputs B, C, and D.  Now, if Bob and Charlie want their inputs (E, F, G) mixed together, but the coordinator refuses, how can Alice be sure the coordinator isn't sybil attacking her in this situation?  

The coordinator is not able to determine that E, F, and G do not belong to Alice. If Alice sees her other inputs are refused entry, then she can detect the coordinator targeting input A.
sr. member
Activity: 364
Merit: 300
Since there are no free handouts in WabiSabi, there's no job for fidelity bonds to accomplish.

Okay, I grasp the concept more clearly now.  Fidelity bonds come into play when there are takers and makers, such as in Joinmarket.  The method to establish provable identities within a decentralized network involves locked value.  An attacker cannot generate identities without first paying the corresponding amount of money.  In WabiSabi, this process isn't necessary because there are no distinct roles of takers and makers; each participant pays for their own inputs and outputs.  Correct? 

I did quote the specific message, I'll just copy and paste the content here

I still don't get how this stops sybil attacks or makes them less likely.  Imagine Alice registers input A, and the coordinator registers their own inputs B, C, and D.  Now, if Bob and Charlie want their inputs (E, F, G) mixed together, but the coordinator refuses, how can Alice be sure the coordinator isn't sybil attacking her in this situation? 
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
What's the connection between block space and fidelity bonds?  I understand that fidelity bonds serve a purpose by discouraging attackers from launching sybil attacks, as they would need to lock up bitcoins for an extended period.

In JoinMarket and Whirlpool, one coinjoin participant pays for another participant's block space. This creates a misaligned incentive that encourages a single person to assume many identities in order to be chosen for this free handout as often as possible. This misaligned incentive is corrected by fidelity bonds in JoinMarket which allow the free handouts to be targeted towards distinct participants instead of unbonded identities.

Since there are no free handouts in WabiSabi, there's no job for fidelity bonds to accomplish.

Can you quote your specific message instead?  There's a lot of discussion there.  

I did quote the specific message, I'll just copy and paste the content here:

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.
sr. member
Activity: 364
Merit: 300
There isn't a need for fidelity bonds with WabiSabi because no one is paying for anyone else's block space.

What's the connection between block space and fidelity bonds?  I understand that fidelity bonds serve a purpose by discouraging attackers from launching sybil attacks, as they would need to lock up bitcoins for an extended period. 

I don't know what you mean by "a regular coinjoin".

I'm referring to a system where there's a coordinator and user connection.  Users register their coins through it. 

The coordinator is not "relied on not to orchestrate a Sybil attack", any non-coordinator entity can be a Sybil attacker

Especially the coordinator, as they are responsible for approving or disapproving coins in every round.

I answered these questions here: https://bitcointalksearch.org/topic/m.63555300

Can you quote your specific message instead?  There's a lot of discussion there. 
member
Activity: 378
Merit: 93
Enable v2transport=1 and mempoolfullrbf=1
As far as I know, WabiSabi doesn't have fidelity bonds.  How does it defend against Sybil attacks?

There isn't a need for fidelity bonds with WabiSabi because no one is paying for anyone else's block space.

In a regular coinjoin, the coordinator must be relied upon not to orchestrate a Sybil attack.

I don't know what you mean by "a regular coinjoin". The coordinator is not "relied on not to orchestrate a Sybil attack", any non-coordinator entity can be a Sybil attacker:

I reviewed your research paper, and it doesn't explicitly address Sybil attack protection; it only briefly mentions it in section 7.2.2.  

I answered these questions here: https://bitcointalksearch.org/topic/m.63555300
sr. member
Activity: 364
Merit: 300
This network has already been created, the coinjoin protocol you are referring to is called "WabiSabi"

As far as I know, WabiSabi doesn't have fidelity bonds.  How does it defend against Sybil attacks?  In a regular coinjoin, the coordinator must be relied upon not to orchestrate a Sybil attack.  I reviewed your research paper, and it doesn't explicitly address Sybil attack protection; it only briefly mentions it in section 7.2.2.  

Quote
Sybil attacks [Dou02] are an inherent threat to privacy in mixing scheme ...
Quote
A malicious coordinator may tag users by providing them with different issuer parameter ...
Quote
A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks ...
Pages:
Jump to: