What to do with leftovers after mixing

[dark_wanderer]

Hello

I have a simple question about what to do with leftovers after mixing funds (dead change).

Imagine I received DASH to address A in my wallet and immediately started to mix them. After creating denominations and after completing the mixing process, I can have some amount of non-anonymous funds returned back to A because that amount was smaller than the smallest denomination (i.e. 0.01 DASH right now). This leftover cannot be PrivateSent, and is not anonymous.

Imaging after having mixed the funds from A, I received DASH to address B and started to mix them. After mixing, I will likewise have some non-anonymous leftover.

Imaging after having mixed the funds from A and B, I received DASH to address C and started to mix them. After mixing, I will likewise have some non-anonymous leftover.

If I would non-anonymously send the inherently non-anonymous leftovers from A, B and C to address D, then it will break my anonymity because it will expose that the funds received to the addressed A, B and C belong to the same person (which can sign such a transaction).

The total leftover from the three mixing sessions can be greater than the smallest denomination. If I try to mix, creating denominations would "combine" the leftovers in one transaction thus breaking my anonymity. Actually it does not happen because the mixing algorithm does not "touch" the leftovers (they are toxic).

My question is extremely simple: is there any way to anonymize such leftovers without breaking the anonymity? Because otherwise those funds are useless and just sitting in the wallet.

 

[dark_wanderer]

Imagine you have three masternodes, mn1, mn2 and mn3. The collateral for all three is in one wallet (wallet1). You have a second wallet for mixing (wallet2).

You send the masternode rewards from mn1 to A in wallet2 and mix the funds. You will end up with a non-anonymous leftover in A.
Ditto for mn2 and mn3.

It is easy to determine that the funds sent to A are coming from a masternode since the public key of mn1 is public.

If you decide to "combine" the leftovers from A, B and C and send to another address for mixing, then you will expose that:

1) mn1, mn2 and mn3 belong to one person
2) the IP addresses of all thee masternodes are controlled by one person. NSA can now expose your identity by contacting the VPS provider. They will also know that you possess three masternodes.

Is that correct?

 

[Antti Kaikkonen]

I could be wrong but I think you could make 3 separate transactions: A->D, B->D and C->D. Then you could mix on D assuming that you have at least 0.01 and there is no solid proof that A, B and C are controlled by the same person.

 

[dark_wanderer]

I could be wrong but I think you could make 3 separate transactions: A->D, B->D and C->D. Then you could mix on D assuming that you have at least 0.01 and there is no solid proof that A, B and C are controlled by the same person.

If:
1) A, B and C received the rewards from the public addresses of masternodes mn1, mn2, and mn3
2) you make 3 separate transactions: A->D, B->D and C->D

then it does not, indeed, prove that the three masternodes belong to the same person, but it does not exclude it either (probability is quite high). What you do with D afterwards is irrelevant even if mixing is perfectly implemented.

The only safe option of spending masternode rewards at the moment would be:

1) mn1 -> E in wallet X, mix and spend via PrivateSend
2) mn2 -> F in wallet Y, mix and spend via PrivateSend
3) mn3 -> G in wallet Z, mix and spend via PrivateSend
4) never import the private keys of E, F and G into one wallet and spend

 

[Antti Kaikkonen]

If:
1) A, B and C are masternode public addresses
2) you make 3 separate transactions: A->D, B->D and C->D

then it does not, indeed, prove that the three masternodes belong to the same person, but it does not exclude it either (probability is quite high). What you do with D afterwards is irrelevant even if mixing is perfectly implemented.

The only safe option of spending masternode rewards at the moment would be:

1) A -> E in wallet X, mix and spend via PrivateSend
2) B -> F in wallet Y, mix and spend via PrivateSend
3) C -> G in wallet Z, mix and spend via PrivateSend
4) never import the private keys of E, F and G into one wallet and spend

I don't understand this example.

Also I don't see how is this a problem if you are running masternodes. Masternodes currently earn ~0.2 dash/day according to dashninja. That's 20 times the smallest denomination. And masternodes require 1000 dash so there is like 0.001% that you can't spend anonymously.

Also if you want to run masternodes anonymously you probably shouldn't be running it on a vps anyway. A better option would probably be using a masternode hosting service or trying to run the masternodes over the Tor network.

 

[dark_wanderer]

I don't understand this example.

public adddress of mn1 -> A -> D
public adddress of mn2 -> B -> D
public adddress of mn3 -> C -> D

means that mn1, mn2 and mn3 could belong to the same person.

Also I don't see how is this a problem if you are running masternodes. Masternodes currently earn ~0.2 dash/day according to dashninja. That's 20 times the smallest denomination. And masternodes require 1000 dash so there is like 0.001% that you can't spend anonymously.

Problem #1: a simple analysis above could reveal/indicate that a group of masternodes is controlled by one entity (which compromises privacy).
Problem #2: if you mix every masternode reward, you would have about 52 addresses (1 payment a week at the time being) with < 0.01 DASH a year or about 0.5 DASH. Which is not too much but still something you could make use of.

Also if you want to run masternodes anonymously you probably shouldn't be running it on a vps anyway. A better option would probably be using a masternode hosting service or trying to run the masternodes over the Tor network.

Every masternode requires a static IP. That is you cannot run a masternode over Tor.
Hiding IPs or allowing IP to be dynamic is not implemented (and not planned).
i2p will probably not be implemented (correct me if I am wrong).

Regarding a hosting service: it implies trust that the owner will not scam you. Crypto should be trustless, and, thus, using a masternode hosting service is not an option (at least for me). Would you trust $300'000 or even 1/10 of that sum to an anonymous forum user/hosting operator?

 

[Antti Kaikkonen]

Regarding a hosting service: it implies trust that the owner will not scam you. Crypto should be trustless, and, thus, using a hosting service is not an option (at least for me).

You don't need to trust the host with your private keys. All they could scam is the hosting fee. You are probably right that you can't run a masternode over tor anymore but it used to be possible.

 

[dark_wanderer]

You don't need to trust the host with your private keys. All they could scam is the hosting fee.

if you have 1000 DASH, then you, indeed, do not need to transfer that collateral to the hosting service as the service would be running dashd and you would be just starting the masternode. The service could scam just the hosting fee.

However, if you have less than 1000 DASH, then you would need to transfer your share to the hosting service thereby losing the ownership of the transferred coins. The service can scam 100% of your share. A trustless shared masternode is not yet implemented.

Just think of it: a hosting service that runs just 10 shared masternodes, owns, in fact, $3'000'000. Impressive, isn't it? What happens if the funds are seized by law enforcement? What happens to all those who sent the shares to the hosting service and did not declare the income from the shares? And logged in to the webpage of the hosting service from their home computers? And...