Welcome, and thanks for the thoughtful posts!
The example attack you describe is a “dusting” attack. Andrew Miller actually demonstrated it live on twitter one time — using 7 dust payments instead of 13. It looks like some of the tweets may have been deleted or something, but it was somewhere in this twitter thread… Oh, here’s the rest of the demo! (Thanks to TripsCrypto on twitter for linking to it.)
I think you’re right that it is a real possible attack, but imho it wouldn’t typically be easy for an attacker to leverage it to learn much more. I explained why I think that in detail in this twitter thread.
As an aside, this is totally different in Zcash than in Monero! In Zcash (Sapling), all that is revealed on the blockchain is the total number of input notes used and the total number of output notes created in the transaction. In Monero what is revealed is which specific input notes/decoys—out of all possible input notes on the blockchain—were used and which specific output notes were created. That is a much richer set of information to give to the attacker, and it is the basis for the devastating attack on Monero that I describe in this video, which I call “the Make Two Controlled Purchases Attack” and which the Monero researchers call “EAE” Attack (Eve-Alice-Eve).
Now the suggested defense of sending the dust inputs to yourself is a strong defense in Zcash, because after you’ve done that a single time, no further information derived from those dust inputs will ever be revealed either on the blockchain, through the network layer, or to your recipients. (Aside: unlike in Monero, where more information continues to be leaked to the attacker, and churning is kind of swimming upstream against the attacker’s information-theoretical advantage. It could even do more harm in Monero. But not in Zcash.)
However, this is the kind of thing that wallets should do for the user automatically instead of the user having to become an opsec expert and try to outfox their attacker. Halo+Orchard will make this possible! Let me explain…
There is a bundle of interacting issues in the wallet’s decisions about whether to send funds to yourself and when, and what notes to use. These include autoshielding (moving funds from the t-pool to the latest shielded pool), automigration (moving funds from older shielded pools to the latest shielded pool), defending against dust attacks, how long it takes to generate a transaction, and also the “I can’t tip the barista!” problem. Let me explain that last one…
The “I can’t tip the barista problem” has to do with the fact that when you use an unspent input note to pay someone, and you send the change from it back to yourself, you can’t spend that change for a while until the transaction that produced it has finalized. That’s why in most/all Zcash wallets, after you make a payment, your “available balance” temporarily goes down. If all of your ZEC was in that one note you used (which isn’t uncommon, as we’ll see below) then your “available balance” temporarily goes down to zero.
That means if you use a note to pay for coffee with ZEC (which I do almost every day), and then you want to give a tip to the barista (which I also do almost every day), then sometimes you can’t, because all or almost all of your ZEC is still in pending state waiting for that change to come back to you.
Okay, so there is a multidimensional tradeoff here. Your wallet could make it possible for you to make multiple successive transactions if it maintained many small notes instead of one large note. And it could help protect you from dust attacks if it either (A) Used more input notes in a typical transaction so that it could use some dust inputs in a transaction while that transaction would still be indistinguishable from a typical transaction, and/or (B) Sent funds to yourself in a transaction (like it does with auto-shielding and auto-migration) just for merging dust.
Now the current behavior in all Zcash shielded wallets does the opposite! It basically tries to keep your ZEC in few big notes instead of many small notes, and it tries to use few input notes in each transaction. This means it yields pretty bad results on the resistance-to-dusting tradeoff and on the “I can’t tip the barista” tradeoff, but it optimizes for the other one I mentioned up there — the time it takes to generate a transaction!
(And remember, even though the current Zcash wallets do this in a way that makes them vulnerable to dusting attacks, I still think — as far as I can tell — that dusting attacks are not a huge threat against Zcash users in the use cases that I can imagine…)
So why do wallets do it this way? Because in Zcash Sapling (with the Groth16 ZKP), the time it takes to generate a transaction is approximately ~0.1 seconds plus ~4 seconds per input note. That means if you were using, let’s say, 10 inputs notes in a transaction, it would take maybe 40 seconds of waiting.
So what’s going to be better in Orchard (with the Halo ZKP)? Two things:
-
The time it takes to generate an Orchard proof is more like ~4 seconds per transaction plus ~0.1 seconds per note. [*** Caveat: these timings are approximate. Real, precise and reliable numbers will come from actual benchmarks.] Therefore you could generate a 10-input transaction proof in only ~5 seconds.
-
The ECC core team came up with a really cool hack in Orchard to improve privacy and usability, which is that on the blockchain, input notes and output notes are indistinguishable! So instead of the eavesdropper seeing that X input notes were used and Y output notes were created, all they see is that Z input-and-output-notes were involved in this transaction.
So you could imagine a wallet that, for every typical transaction it makes, it tries to use the same number of notes (inputs and outputs added together) as all other wallets’s typical transactions, and that number could be—let’s say—10 and then the wallet would have the flexibility to do a better job of keeping extra ZEC available for immediate use, protecting the user from dust attacks, and still generating transactions quickly so the user doesn’t have to wait.
Most importantly, wallets might be able to do this without requiring the user to understand these issues or to make any explicit decisions.
However, it still won’t be easy! Balancing multiway tradeoffs like this is tricky. At ECC, we’re currently focused on shipping a bulletproof Halo, Orchard, and Shielded By Default!
Thanks again for the thoughtful posts on this and on the quantum computers topic.