Some comments on the first part of the paper

[dangershony]

Some initial comments, I will continue the next part after that.

• I think Mike Heren comment was about bloom filters and the case where a cloned wallet will not know if our utxo was spent as a bloom filter wallet does not monitor that

  The problem starts when we realize that what we actually care about is not transactions but rather transaction chains.

• I definitely get the post/pre wallet utxo linking, but that's true only with with denominated mixing

  1. So the question is how severe is that in terms or privacy leaking?
  2. Second question (I also noticed that in the ValueShaful paper) why is fixed value mixing so important, to me its actually worthening as the coins become marked as mixed coins and may result in liking pre mixed coins. wont randomizing the output values be better?

• When all the Alices signed [transactions] arrive,

• "By allowing the user to register eight outputs within one round, this issue can be bypassed" "The drawbacks are weaker anonymity set" - why weaker anonymity? "and longer mixing rounds." - why longer mixing rounds

• "The issue is various timing attacks can deanonymize users." I didn't understand this sentence

• "at low liquidity could take hours or days" is that a necessity or a configuration?

[nopara73]

I think Mike Hern comment was about bloom filters...

Indeed, I removed it, it's just waffle quote.

I definitely get the post/pre wallet utxo linking, but that's true only with with denominated mixing
So the question is how severe is that in terms or privacy leaking?

Really bad:

Second question (I also noticed that in the ValueShaful paper) why is fixed value mixing so important, to me its actually worthening as the coins become marked as mixed coins and may result in liking pre mixed coins. Wont randomizing the output values be better?

Amount analysis is obvious:

When all the Alices signed [transactions] arrive,

• Alices send the signatures to the Tumbler, the Tumbler adds the signatures to the transaction and propagates. If one doesn't sign after 1 minute, Alice gets banned and the round restarts.

"By allowing the user to register eight outputs within one round, this issue can be bypassed" "The drawbacks are weaker anonymity set" - why weaker anonymity? "and longer mixing rounds." - why longer mixing rounds

At the issue I detailed it: https://github.com/nopara73/ZeroLink/issues/21

"The issue is various timing attacks can deanonymize users."
I didn't understand this sentence

Tumbler can talk to one Alice and delay its communication with the rest in order to figure out which Bob is that Alice.

"at low liquidity could take hours or days"
is that a necessity or a configuration?

Configuration. See achieving liquidity: https://github.com/nopara73/ZeroLink/blob/master/README.md#b-achieving-liquidity

If you want to make sure you provide privacy you must do something like this. Otherwise you'd end up people coinjoining with themselves, just like what I suspect will be the case at TumbleBit in practice. Many people will just tumble coins with themselves, because the rounds are fixed and new users to register is not awaited.

[dangershony]

Thanks for the comments, I am now shocked how easy it is to link payments, perhaps it might even be a good idea to add more about transaction chaining (as Mike Hern was talking about). Indeed post mix coins should not be used with pre mixed coins, even one time usage might compromise the entire post mix coins.

I will continue to review the rest of the paper.

[dangershony]

What algorithm maybe some more details or a link?

How long does a round take? - , using the recommended dynamic anonymity set algorithm

Why is a secure connection important, are we not assuming post mixed coins are coming directly from the mixer?

Pre-mix wallets MUST either get bitcoin addresses of the post-mix wallet where the mixed coins are going directly through a secure connection

Why is this a requirement?

In the former case the post-mix wallets must be online while mixing is in process.

I don't understand this.

pre-mix wallet might want to acquire all the Chaumian CoinJoin transactions that ever happened in the Blockchain

[nopara73]

What algorithm maybe some more details or a link?

It is in the previous section: https://github.com/nopara73/ZeroLink/blob/master/README.md#b-achieving-liquidity:

How should the desired minimum anonymity set be chosen? Manually or utilizing a dynamic algorithm:
Choose the minimum anonymity set to three and the maximum to 300. If the previous non-fallback Input Registration phase took more than three minutes then decrement this round's desired anonymity set relative to the previous desired anonymity set, otherwise increment it.
More sophisticated algorithms may be applied, too.

Why is a secure connection important, are we not assuming post mixed coins are coming directly from the mixer?

My mistake, not the coins have to go through secure connection, but the addresses, modified it:

Pre-mix wallets MUST either get bitcoin addresses of the post-mix wallet directly, for instance through a local RPC API or through the sharing of the post-mix wallet's extended public key.

Why is this a requirement?
"In the former case the post-mix wallets must be online while mixing is in process."

This just means for instance if the addresses are served through an RPC API, the addresses cannot be served when the RPC application is not running.
So this is not a requirement, it's just a consequence, pretty obvious, so I removed it, it just causes confusion.

I don't understand this. "pre-mix wallet might want to acquire all the Chaumian CoinJoin transactions that ever happened in the Blockchain"

I specified the approaches in greater detail:

Retrieving Transaction Information

A pre-mix wallet can use a privacy breaching way to retrieve transaction and balance information, for instance it can query its address balances through a web API. In this case the web API knows about all the addresses the user possesses. However a pre-mix wallet MUST NOT use a privacy breaching way to acquire information about the childs of the extended public key, otherwise it would expose the post-mix wallet to a third party. An additional problem is that the pre-mix wallet cannot ever register the same addresses twice a Tumbler. Therefore the pre-mix wallet must always register the next unused extended public key child, that was not registered before.
A user to use the same extended public key in multiple pre-mix wallets is unlikely to happen, as well should be discouraged. If this is a given, a pre-mix wallet can keep records which derived keys it already registered before and never acquire their balances. This approach brings additional issues at wallet recovery.
Another way to solve this is to have a server that tells the pre-mix wallet all the addresses those have ever been used in CoinJoin transactions. In this case the pre-mix wallet does not expose which addresses it is interested in, because it gets all the addresses a any pre-mix wallet can be interested in. Additionally a pre-mix wallet MUST keep records which derived keys it already registered before.
This approach is reliable, it can handle proper wallet recovery and the case if multiple pre-mix wallets use the same extended public keys. Some information leak is still possible, however it is unlikely.
Information leak happens if:

• a malicious attacker disrupted a round that the user is participated in
• AND the user either decides to recover its wallet OR is using the same extended public keys in another pre-mix wallet right after the disrupted round
• AND the Tumbler does not reject the already registered, but unused address
• AND the Tumbler is malicious.

If all the above conditions are true, the Tumbler may be able to deanonymize the user. The Tumbler MAY be the third party who serves the addresses. In this case the Tumbler could serve the already registered, but unused addresses, too.