Zcash t-addresses (which appear on the blockchain) could potentially also be targeted by a dusting attack so I wanted to post some information about what a dusting attack is:
If you think you might be a target of a dusting attack (ie: you receive a random small amount of ZEC for no reason) you could potentially avoid privacy compromise by sending the dust to a private Z-address. Then sometime later including that dust in a larger private z2z or z2t transaction.
z_mergetoaddress would slurp up all t-address balances simultaneously, so it won’t solve the linkability attacks.
Even if the user runs z_mergetoaddress very often, the dust transactions can all show simultaenously in a single block, and will then be swept up together by the next merge, making their t-addresses linkable.
That links the taddrs as they’d be part of the slurp but once its gone to a zaddr any link is broken. If you only spend from a zaddr then there’s nothing to worry about ?
You’re right that the link to to further transactions is broken by entering the shielded pool. The concern is that linking the t-addresses may already be harmful, e.g., because the user used these in different contexts.
Of course, the real answer is to not use t-addresses in the first place.
From what i see these dusting attacks happen since over 1 year, at least… I’am pretty sure Zcash adressed this problem allready, at least internally.
This is inaccurate. z_mergetoaddress takes a list of source addresses, which could just be a single t-address; it also allows the caller to specify ANY_TADDR (instead of any individual t-addrs) to merge from all t-addrs in the wallet. A user can therefore avoid the linkability issue when using z_mergetoaddress by never specifying ANY_TADDR.
You can also specify a limit on the number of txns (ie: 1) which should make it safe for ANY_TADDR, but it only makes sense if its worth more than the fee.
I assumed @ChileBob meant using z_mergetoaddress with ANY_TADDR to slurp up everything.
Yes, of course one can shield the t-address balances one by one, whether by z_mergetoaddress or by z_sendmany, and also take the requisite care to do so at random intervals (and from random IP addresses).
My point are
1.There is no ready-made tool for this
2. Even if merging into a z-address, the t-addresses of the inputs remain as linkable as they would be in vanilla Litecoin/Bitcoin
As written above, the solution is to not use t-addresses in the first place.
Zcash and its forks, when using z-addresses, are perhaps the only cryptocurrencies that are inherently not susceptible to such linkability attacks.
(Caveat: even with z-addresses, there is a small amount of residual information leakage, since the number of notes spent in a transaction is discernible.)
Ok, that’s the solution you know, me now and some other forum members that readed that statement, but do all the ZEC users know that as well? IF they don’t know it, they can’t react to it…
