Can we create a compliant semi-centralized CoinJoin service?

I think everyone has heard about the Samourai situation by now. I was wondering if it's possible to set up a CoinJoin service that simplifies the process while being completely compliant, so it doesn’t get labeled as a "money transmitter" by any regulatory body. Personally, I believe the U.S. authorities are mistaken in classifying Whirlpool as a "money transmitter," but I haven't examined the code, so I can't be certain. First off, what would we need to create a service that facilitates CoinJoins? We’d require some kind of storage for a pool of UTXOs that are ready for CoinJoins. I think Whirlpool does this in a centralized manner through their servers. But theoretically, users could handle this themselves: once they provide their own UTXOs, they could access information about other available UTXOs. This is pretty much how JoinMarket works, if I’m not mistaken. But that’s not exactly what I’m after; I’m envisioning a centralized service that charges a fee but is simpler to use than JoinMarket. So, the UTXOs would flow through a P2P network that is totally separate from the centralized server. Next up, we need the entity that actually creates the CoinJoin transactions. This could also be managed within the P2P network. Essentially, when a user identifies enough UTXOs to set up a CoinJoin, they could take, say, 5 or 10 UTXOs from this decentralized pool, construct their transaction, sign it, and send it out through the P2P network so that all the peers who contributed UTXOs can sign it as well. What role can the centralized server play in making CoinJoins easier? As far as I've grasped JoinMarket...

I think something like a decentralized network where users could engage in privacy-enhancing transactions without the risk of running afoul of regulatory bodies is needed.  Given the situations with Samourai and Whirlpool and the scrutiny it faced it's crucial to brainstorm a structure that avoids being labeled as a money transmitter The first challenge is managing the pool of UTXOs that users wish to mix. Instead of a central server holding this info (which could draw legal and security concerns)why not let the users themselves manage their UTXOs in a peer-to-peer manner? Distributed Hash Table? Utilize a DHT to store and retrieve UTXO information, each UTXO can be indexed by a hash derived from its attributeswhich could include the transaction ID and output index, masked with a privacy-preserving algorithm to prevent tracking Adding a gossip protocol to propagate UTXO information across the network.  This ensures redundancy and availability of UTXO data without relying on a central server.  It would also be possible to use cryptographic commitment schemes to ensure that UTXO data remains confidential until participants are ready to reveal them. This can prevent premature exposure of UTXO details. Apply homomorphic encryption to allow certain computations to be carried out on UTXOs, such as verification of amounts and eligibility, without revealing the underlying values. Multi-Party Computation could be used for constructing the transaction where each participant computes a part of the transaction without revealing their inputs to others.  This can be crucial for maintaining the confidentiality of which inputs and outputs belong to whom. Just some ideas

https://joinstr.xyz somewhat match idea you described.

Looks really interesting, thank you! It seems however still not be ready for mainnet, but definitely a solution which is worthy to observe. Some good ideas here, thanks! Yes, what I had thought about was that users manage the UTXOs in a P2P manner. But my question was in reality if you could build a compliant business model with such an idea. I don't know how many of those technologies you mentioned (DHT, gossip, homomorphic encryption/multiparty computation) are already implemented in JoinMarket and Joinstr. Specificly homomorphic encryption and multiparty computation could be a game-changer if that part is still lacking, because they would allow a similar level of privacy than a trusted centralized service. My main doubt was about the need of a full node. JoinMarket requires it, Joinstr seems not, so it may already fit the idea of the service I had in mind. Possible business model could include to act as a market maker or even as a specialized Nostr relay maybe.

While Bitcoin's pseudonymous nature offers a level of privacy, all transactions are public on the blockchain, allowing for potential analysis that could link identities to transactions. To enhance privacy and security, advanced cryptographic techniques such as homomorphic encryption can be applied. using Microsoft SEAL, a C++ library for homomorphic encryption, to demonstrate how privacy could be further protected in Bitcoin transactions, particularly in privacy-focused protocols like CoinJoin. Homomorphic encryption allows computations on encrypted data without needing to decrypt it first. This property can be particularly useful in Bitcoin transactions for various reasons...  Users can participate in transactions without revealing their transaction amounts or other sensitive data to other parties or the public blockchain. Secure Multi-party Computations, enables the creation of complex multi-party protocols where inputs are kept private. Setting up Encryption Each participant uses a common encryption scheme set up using Microsoft SEAL. This ensures all parties can operate on the data homomorphically. users encrypt their UTXO values. This encryption does not reveal the amount of bitcoins each user intends to mix, but allows operations to be performed on the encrypted values. Serialize and Share Encrypted UTXOs, Once encrypted, UTXO data can be serialized and securely shared with other participants or a coordinating server without revealing the actual values. Aggregate Encrypted UTXOs, A trusted coordinator or the participants themselves can aggregate the encrypted UTXOs. This aggregation is performed homomorphically, ensuring that no individual inputs are exposed. Check Aggregated UTXOs Against Threshold: To ensure the transaction meets certain criteria (e.g., minimum input threshold for a CoinJoin), a homomorphic operation checks if the aggregated encrypted value meets the required threshold. Finalize Transaction: If the check passes, the transaction can proceed. This step would typically require converting the homomorphically encrypted data into a format suitable for a Bitcoin transaction, which may involve securely decrypting the data under strict protocols or through a zero-knowledge proof mechanism to maintain confidentiality. While it's not 100% solid idea yet could be worth exploring further.

This doesn't resolve the issue.  You're still required to place trust in the service to provide you with accurate information.  There are still security concerns, just like previously.  The problem (and feature) of JoinMarket lies in takers covering the costs of inputs and outputs for their makers.  When selecting an entity to mix coins with, I'm essentially covering the expenses for their inputs and outputs.  This quickly renders it unappealing in the present context, where we pay more than 15 sat/vB.  What's required is a network with no distinctions between makers and takers, that consists solely of users leveraging the network to create a shared space, because the main problem with coinjoins is being online at the same time with the other joiners.  Once a collective of participants is created, they could merge their inputs, generate blinded outputs, and cover only their respective portions of the costs.  I believe this network is feasible to create.  Fidelity bonds could still serve to discourage sybil attackers.  Sybil attacks.  By selecting random users, you're essentially relying on the assumption that an attacker doesn't control all of them and inject their inputs.  While you might think your coins have been successfully mixed, the attacker would still be aware of your outputs.

The WabiSabi coinjoin protocol deployed in Wasabi Wallet and BTCPay Server uses homomorphic value commitments   Check out the WabiSabi research paper: https://eprint.iacr.org/2021/206.pdf This network has already been created, the coinjoin protocol you are referring to is called "WabiSabi": - Users directly cover their own block space costs - No distinction between makers and takers - Timeout based rounds for liquidity

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.

There isn't a need for fidelity bonds with WabiSabi because no one is paying for anyone else's block space. 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 answered these questions here: https://bitcointalk.org/index.php?topic=5482818.msg63555300#msg63555300

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'm referring to a system where there's a coordinator and user connection.  Users register their coins through it.  Especially the coordinator, as they are responsible for approving or disapproving coins in every round. Can you quote your specific message instead?  There's a lot of discussion there.

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. I did quote the specific message, I'll just copy and paste the content here:

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 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?

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

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.

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?

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

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.

No it doesn't. You can interact with anyone.