Is the whirlpool by Samourai (Sparrow wallet and Whirlpool-cli) really blinded?

[SagittariusV]

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.

[1714521212]

1714521212

[1714521212]

1714521212

[1714521212]

1714521212

[1714521212]

1714521212

[1714521212]

1714521212

[AB de Royse777]

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.

Even with the different IP I guess the first problem still exits. The coordinator knows who belong the output address because there must be a link between input and output address so that coordinator can identify where to send the coins. Please correct me if I am wrong.

[SagittariusV]

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.

[BlackHatCoiner]

Sparrow wallet and Whirlpool-cli do not use tor connection management interface.

Where did you get this information from? Sparrow does have a Tor connection management interface, it's bottom left when you're into whirlpool:



Read more about it:

Further, if you have configured a Tor proxy, or are using an Electrum server on a .onion address, communication with the Whirlpool server will be over Tor. Note that you can configure a Tor proxy even if your server is on a local network IP address - Sparrow uses Tor only to connect to externally addressable services. You can verify whether Tor is set up correctly with the status bar icon to the left of the server toggle.

I have never used whirlpool-cli, but I can verify that it uses Tor to connect to the coordinator as well: https://docs.samourai.io/whirlpool/desktop.

Coinjoin users should never connect with their real IP address-- always through Tor. It doesn't make sense to doubt the blindness.

[SagittariusV]

Sparrow wallet and Whirlpool-cli do not use tor connection management interface.

Where did you get this information from? Sparrow does have a Tor connection management interface, it's bottom left when you're into whirlpool:


Coinjoin users should never connect with their real IP address-- always through Tor. It doesn't make sense to doubt the blindness.

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

[BlackHatCoiner]

Using a "Tor proxy" and using "Tor settings management interface", which allows you to manage Tor connections, are two very different things.

They are two things, but it doesn't make much sense to have the former, if you don't have the latter. That's what I meant here:

It doesn't make sense to doubt the blindness.

We connect via Tor, not only to hide our IP addresses, but to register our outputs in a blinded fashion. If we didn't have Tor, we would need more than an IP address, which is impractical.

- This is the part of the code in whirlpool-cli that changes the identity during output registration: https://code.samourai.io/whirlpool/whirlpool-client/-/blob/dex-wp/src/main/java/com/samourai/whirlpool/client/mix/MixClient.java?ref_type=heads#L276.
- Here's the relevant code of Sparrow that ensures identity change: https://github.com/sparrowwallet/nightjar/blob/08fd60cd5256ce4842701c6c179c18f997fd252f/src/main/java/com/samourai/whirlpool/client/whirlpool/ServerApi.java#L62. (You can search more about "identity", the function that changes identity is changeIdentity)

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.

How could this de-anonymize them?

[Kruw]

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.

This is 100% true, Samourai is able to easily match inputs and outputs of Whirlpool coinjoin participants in two different ways:

- A coinjoin participant does not use a separate Tor identity for input registration and output registration
- A coinjoin participant shares their input address and output address in the coinjoin with Samourai when syncing their wallet's xpub

By default, Samourai Wallet collects data in both of these ways, and does not notify the user that their entire financial history is being leaked. I opened an issue in their Gitlab to have these critical privacy features enabled by default, but it was deleted and covered up by their devs: https://web.archive.org/web/20230417145554/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/458

[SagittariusV]

We connect via Tor, not only to hide our IP addresses, but to register our outputs in a blinded fashion. If we didn't have Tor, we would need more than an IP address, which is impractical.

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

[SagittariusV]

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.

This is 100% true, Samourai is able to easily match inputs and outputs of Whirlpool coinjoin participants in two different ways:

- A coinjoin participant does not use a separate Tor identity for input registration and output registration
- A coinjoin participant shares their input address and output address in the coinjoin with Samourai when syncing their wallet's xpub

By default, Samourai Wallet collects data in both of these ways, and does not notify the user that their entire financial history is being leaked. I opened an issue in their Gitlab to have these critical privacy features enabled by default, but it was deleted and covered up by their devs: https://web.archive.org/web/20230417145554/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/458

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

[BlackHatCoiner]

- A coinjoin participant does not use a separate Tor identity for input registration and output registration

Coinjoin participants use separate Tor identities by default. Look on the code I've linked above. They'd have to deliberately mess with the source code of Sparrow or Whirlpool-cli to not use separate identities.

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

First of all, there is no exit node, because you're connecting to a hidden service, not to the clearnet: https://github.com/sparrowwallet/nightjar/blob/08fd60cd5256ce4842701c6c179c18f997fd252f/src/main/java/com/samourai/whirlpool/client/wallet/beans/WhirlpoolServer.java#L19.

Secondly, just because there is no "Tor management interface", it doesn't mean you can't have different identities. If you have the option to establish connection with Tor, then you also have the option to re-establish it under new circuit, therefore under new identity, which is literally what Sparrow is doing: https://github.com/sparrowwallet/nightjar/blob/08fd60cd5256ce4842701c6c179c18f997fd252f/src/main/java/com/samourai/whirlpool/client/mix/dialog/MixSession.java#L265.

[Kruw]

Coinjoin participants use separate Tor identities by default. Look on the code I've linked above. They'd have to deliberately mess with the source code of Sparrow or Whirlpool-cli to not use separate identities.

You are assuming coinjoin participants are using Tor at all. That's the point of the issue I opened - Tor is off by default in Samourai Wallet:

By default, Samourai Wallet collects data in both of these ways, and does not notify the user that their entire financial history is being leaked. I opened an issue in their Gitlab to have these critical privacy features enabled by default, but it was deleted and covered up by their devs: https://web.archive.org/web/20230417145554/https://code.samourai.io/wallet/samourai-wallet-android/-/issues/458

[SagittariusV]

Coinjoin participants use separate Tor identities by default. Look on the code I've linked above. They'd have to deliberately mess with the source code of Sparrow or Whirlpool-cli to not use separate identities.

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.

Secondly, just because there is no "Tor management interface", it doesn't mean you can't have different identities. If you have the option to establish connection with Tor, then you also have the option to re-establish it under new circuit, therefore under new identity, which is literally what Sparrow is doing: https://github.com/sparrowwallet/nightjar/blob/08fd60cd5256ce4842701c6c179c18f997fd252f/src/main/java/com/samourai/whirlpool/client/mix/dialog/MixSession.java#L265.

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)

[BlackHatCoiner]

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.

We are talking about the same thing. One participant uses the whirlpool client and changes identities when signing input and output.

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

I found this discussion in their github repo: https://github.com/sparrowwallet/sparrow/issues/1328.

So, as it turns out, nightjar is kind of depreciated, and replaced by a direct dependency of Samourai libs:

Nightjar is actually going away in favour of direct dependency on the Samourai libs, which have recently been updated to be compatible with Sparrow.

This is the code that changes identities: https://github.com/sparrowwallet/sparrow/blob/9d0c35bc750091abdca2769b4ff6fde819d7503e/src/main/java/com/sparrowwallet/sparrow/whirlpool/tor/SparrowTorClientService.java. You can see that it imports the relevant libraries for this purpose.

At this point, if you're still having trouble understanding what it does, we can continue the conversation, but note that I'm not a Sparrow contributor, so you'd be better asking themselves by opening an issue.

[SagittariusV]

At this point, if you're still having trouble understanding what it does, we can continue the conversation, but note that I'm not a Sparrow contributor, so you'd be better asking themselves by opening an issue.

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.

[Kruw]

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.

I forwarded your analysis to the Wasabi developers that are focused on Tor, here's what they responded:

What you first need to understand is that creating a new Tor identity is relatively computationally expensive, and therefore the client limits as much as possible usage of new circuits, and reuses circuits when it’s possible. You can look at the usages of WalletWasabi.Tor.Socks5.Pool.Circuits.Mode to see how Wasabi’s client manages your Tor Identities throughout the lifetime of the application, particularly during the coinjoin process.

DefaultCircuit is a circuit created at launch and maintained until closure of the software. It is used for requests that don’t require particular isolation. This is the case for looking at updates, or getting exchange rate information. The target can know that a client with this given identity is still online, but cannot link its activity to other more privacy critical information.

SingleCircuitPerLifetime is used when isolation from the rest of the application is required, but not isolation between the requests. The most interesting case where this mode is used is through the life of an Alice, an input: Several requests will be made for one input, and using one circuit for all the operations is enough, because all are linked altogether. So the client wants to register an input, a new instance will be created in SingleCircuitPerLifetime mode, which will create a new Tor identity, and this Tor identity will then be used exclusively for the operations of this input, such as Registration, Confirmation and Signing. Another input will have a new SingleCircuitPerLifetime for its operations, and so on, which guarantee exclusive isolation. You can see the code related here: CreateRegisterAndConfirmCoinsAsync. See particularly the line var (newPersonCircuit, httpClient) = HttpClientFactory.NewHttpClientWithPersonCircuit();

NewCircuitPerRequest is then used for the operations that requires absolute isolation. One request = 1 circuit. See how it’s used to register the Outputs in ProceedWithOutputRegistrationPhaseAsync. That way, the outputs are absolutely isolated one from another and from the inputs, as a circuit will be created every time a request will be made.

I hope that this referenced explanation alleviated your doubts of Wasabi’s management of Tor Identities. You can read a higher level explanation here: Explaining Wasabi Wallet’s Tor Implementation