By the way, really, according to what algorithm and on whose side (coordinator or user) are the output amounts formed? If the amounts are formed on the user side, then how does it happen that different users have the same outputs for non-standard amounts? If suddenly someone has already been interested in this question, maybe there is a link to GitHub to the right place in the code?

i.e. is it technically possible to do this? but the user may notice that not all of his inputs are taken into the round.

I would like to ask:
can the coordinator, if he wants, arrange rounds for certain inputs only with this inputs and his own known inputs?
i.e. when the coordinator sees an attempt to register an input of interest to him, he throws out other inputs unknown to him from the round and supplements the round only with his own inputs.
not taking into account how expensive this may be and where the coordinator gets his inputs.
is this technically possible and how can the user be sure that this does not happen?

LM traders, where can I find you, where do you trade now?
I tried Hodl and Bisq.
BTC<>XMR trade is extremely sluggish. Literally a few people.
Hodl generally seemed somehow unfinished.
Are there any other dex?

Thank you very much for your help.
The problem was that I reasoned like this: since Tor management interface settings are not in the Sparrow settings, then the interface is not used (spoiler: in fact, I was right).
It turns out that the developer " trying to avoid adding too much complexity to Whirlpool configuration" so much that the software tries to determine itself whether tor is running and whether  management interface is configured. If it is possible to determine this and it is possible to log in, then the interface is used.
This attitude towards it is not surprising, because, it seems that the only purpose for which this interface is used is to obtain a new tor identity when the user has configurated tor proxy in the Sparrow settings, but the connection does not work in principle.
I think you’ve already read yourself that during the coinjoin process, tor identity is not changed, and establishing a new connection does not give anything for privacy.
 
The same thing happens with Wasabi. Wasabi uses a management interface, but does not change tor identity during the coinjoin process (at least in practice this is absolutely accurate. Anyone can verify this using the way I tested it)

Those. Both of these services are not blinded and can track the chain of your mixes.

Samourai (and, accordingly, Sparrow) are introducing a new feature - Soroban network. As far as i can understand, the network will be built on Ronin Dojo nodes and the connection between the coinjoin participants and the coordinator will pass through these nodes and during the coinjoin the participant’s identity will change.
My knowledge, unfortunately, is not enough to study the Soroban code. This could probably be cool. On the other hand, given that the Samourai developers are not concerned about user security today and if they were unable to configure the correct operation of coinjoin through tor, perhaps they also implement privacy in Soroban ass-backward.

Plus, it turns out that Samourai uses some other features to link user inputs and outputs. As Kruw wrote above when synchronizing inputs:
"- A coinjoin participant shares their input address and output address in the coinjoin with Samourai when syncing their wallet's xpub"


In total, after studying the topic, i can conclude that of all similar services (Samourai, Wasabi, JoinMarket), only JoinMarket looks honest and reliable. There is no coordinator at all and the coinjoin transaction is formed by the one who pays for the coinjoin.
However, the problem with Join Market is the high price of the mix due to the fact that you have to pay mining fees for all participants every time.

We are not talking  about different participants, but about one participant in coinjoin, who during the coinjoin needs to transfer to the coordinator the address from which he will pay from one IP  and the address to which he will receive from another IP. So that the coordinator cannot link its inputs and outputs.


Can you please explain in more detail how exactly you can get a new tor circuit without using tor management interface?

From the code I don’t understand what exactly happens when executed:
 // change Tor circuit
  config.getTorClientService().changeIdentity();


Is this function running?

https://github.com/sparrowwallet/nightjar/blob/08fd60cd5256ce4842701c6c179c18f997fd252f/src/main/java/com/sparrowwallet/nightjar/tor/WhirlpoolTorClientService.java

  public void changeIdentity() {
        Authenticator.setDefault(new Authenticator() {
            public PasswordAuthentication getPasswordAuthentication() {
                return (new PasswordAuthentication("user", Integer.toString(secureRandom.nextInt()).toCharArray()));
            }
        });



btw,

Sparrow wallet code is here:
https://github.com/sparrowwallet/sparrow
(Desktop Bitcoin Wallet focused on security and privacy. Free and open source. )

nightjar is separate project
https://github.com/sparrowwallet/nightjar
(Whirlpool client single module)

Thank you so much for understanding and writing about this!

It should be noted that Wasabi Wallet, which works through tor and where, unlike samourai, there are settings for managing tor identities, does not receive new identities during the coinjoin, does not assign connections to them, and accordingly works in this sense just like Samourai.
How I checked this without reviewing the code: I connected to the tor interface that uses wasabi:
> hexdump -e '32/1 "%02x""\n"' .walletwasabi/client/control_auth_cookie
3c1ec4821044621f34e24ef114fa3e27b95b286a2d9f01e2a82dccab323d9521

> printf "AUTHENTICATE 3c1ec4821044621f34e24ef114fa3e27b95b286a2d9f01e2a82dccab323d9521\r\nSETEVENTS SIGNAL STREAM\r\n" | nc 127.0.0.1 37151 | tee events.txt

I launched the coinjoin and after it I saw that not a single SIGNAL event happened...

Once again: simply working through tor is not enough to ensure “blindless”, i.e. register your inputs and outputs with the coordinator from different IP addresses.

Let's briefly define how tor works in the part we are discussing (https://spec.torproject.org/tor-spec/creating-circuits.html):
1. Tor creates so-called “circuits” - chains of nodes through which connections (“streams”) pass. those. some program needs to connect through tor, in our case it is Sparrow. Sparrow directs the connection to tor interface (tor proxy port). the connection is assigned one of the chains (“circuits”) through which this connection will work.
after some time, Sparrow needs to open a new connection, again Sparrow routes new connection through tor interface and again the connection is assigned one of the chains through which this connection will work.
here is the key point: Tor in normal operation does not create a new chain of nodes ("circuit") for each connection, therefore, from the example above, both Sparrow connections can go through the same chain of nodes, i.e. for Samourai coordinator will look the same - from the same ip address.

2. in order to be able to create new chains exactly when necessary and assign the necessary connections to a chain, there is a special interface and special commands in tor program.
(https://spec.torproject.org/control-spec/index.html)


Unfortunately, I don’t know java and it’s  difficult for me to understand the code (that’s why I actually wrote on the forum in search of those who were already interested in similar issues and could help)

What can i say without knowledge of java:
Sparrow  does not use tor connection management interface (there are no settings in Sparrow for using this interface and no authorization settings) therefore Sparrow cannot create new chains, assign its new connections to them and cannot ensure that the user transfers his bitcoin inputs and outputs to the coordinator using different IP addresses. Without this feature, the coordinator associates the user's inputs and outputs by the ip address from which the user connects.

I don’t know what is meant by "NewIdentity" in the Samourai code from your links. Perhaps this is the creation of a new connection to the coordinator, however, I repeat, the created connections are sent through tor interface and can be exited there from the same IP address (exit node).

Using a "Tor proxy" and using "Tor settings management interface", which allows you to manage Tor connections, are two very different things.
Sparrow allows you to use a tor proxy, but the output node address will not change as this is necessary for Chaumian protocol to work.
Sparrow does not use the Tor connection management interface.
When mixing, you will send your input and output addresses from the same tor node (same ip).
There is some chance that one of the participants in the mix will also use the same tor node, but the chance is not very big.
same with whirlpool-cli

As provided in the Chaumian Coinjoin protocol:
At the first stage, all participants in the mix provide the coordinator with the addresses from which they will pay.
For example, 3 people gave 3 addresses. Everyone connected from their own IP address
Thus the coordinator sees:
btc address A was received from IP address 1.1.1.1
btc address B was received from IP address 2.2.2.2
btc address C was received from IP address 3.3.3.3
btc address D was received from IP address 4.4.4.4
Next, each participant using a new connection (new ip) transmits to the coordinator the addresses to which they will receive the payment
address E was received from IP address 5.5.5.5
address F was received from IP address 6.6.6.6
address G was received from IP address 7.7.7.7
address H was received from IP address 8.8.8.8

The meaning of the mathematics used is that everything is organized in such a way that the coordinator can be sure that the addresses received at the second stage (E, F, G, H) belong to one of the exchange participants who registered at the first stage. This is enough to form one transaction in which Bitcoin is transferred from addresses (A, B, C, D) to addresses (E, F, G, H).

However, in the implementation of the whirlpool protocol by Samourai it looks like this:
Thus the coordinator sees:
Address A was received from IP address 1.1.1.1
Address B was received from IP address 2.2.2.2
address C was received from IP address 3.3.3.3
address D was received from IP address 4.4.4.4
Next, each participant using a new connection  transmits to the coordinator the addresses to which they will receive the payment
address E was received from IP address 1.1.1.1
address F was received from IP address 3.3.3.3
address G was received from IP address 4.4.4.4
address H was received from IP address 2.2.2.2

And you don’t need any mathematics to write down which input and output belong to whom.

Hi all.
I'm trying to find the best way for Bitcoin anonymization.
People have long invented mixers.
However, there are two problems with "regular" mixers:
1. The owner of the service “sees” the inputs and outputs of each client
2. The owner of the service can steal funds.

From what I was able to find in open sources:
To solve these problems, complex mathematical algorithms were invented, which, judging by the documentation, are used on the Whirlpool service by Samourai (clients Sparrow wallet and Whirlpool-cli)
So, the first problem: The owner of the service “sees” the inputs and outputs of each client.
The whirlpool service has a so-called coordinator, i.e. owner of the service.
Very simplified: The coordinator creates a common transaction for the participants in the mix. To do this, the coordinator receives from each user inputs (addresses from which the user sends Bitcoin) and outputs (addresses to which the user receives Bitcoin). Without this data, the coordinator cannot form a general transaction in any way.
 
What is the secret then and how is the first problem solved? The solution is "blind signatures".
Very simplified: The algorithm works in 2 stages:
1. each user transmits to the coordinator the input from which he will send Bitcoin and some evidence that allows the coordinator to clearly verify that the output transmitted at the second stage belongs to one of the users participating in the mix round.
2. Each user transmits their output address to the coordinator, but with a different identity - a different IP address. The coordinator, using the certificate obtained at the first stage, makes sure that the output address belongs to one of the participants in the mix, but does not know who.
The key, basic point here is that at the first and second stages different user identities are used, i.e. different IP addresses. Otherwise, all of this makes absolutely no sense.
Those. Let's say a user uses a VPN with an output address of 1.1.1.1. From this IP address it transmits its inputs to the coordinator. Then it connects from the same IP address and transmits its outputs to the coordinator.
It is clear that the coordinator will, without any problems, link and record where the transaction came from and to whom it belongs.
In order for the coordinator to be unable to link user inputs and outputs, the IP address must be 100% different in the first and second stages.
How is this resolved? Very simply: using a VPN does not solve this problem. the coordinator will always be able to connect your inputs and outputs by VPN IP address. When using Tor, it is possible to form identity (chains of nodes) and route the necessary connections along one chain or another. Thus, you can use one identity at the first stage and another at the second stage.
In order to manage chains, tor software provides a special interface.

Now the crux of my question:
Sparrow wallet and Whirlpool-cli do not use tor connection management interface. How then do they organize that the user's identity is not the same on first and second stages?
If the ip address does not change, then it turns out that the Samourai whirlpool solves only the second problem: service cannot steal user funds, but they can easily match inputs and outputs.