Highlighted context was restored by nullius to an overly-snipped internal quote:
LOL, I see that @str4d is playing it cool with his replies. Poker face! What did you mean about recursion? 
Probably nothing…
As I recently observed in another context, most people do not and cannot understand recursion. Most people cannot understand zero-knowledge proofs. Put the two together, and people will be stunned at achievements that seem impossible.
Recursive zero-knowledge proofs? Probably nothing…
You entirely missed my point. Will not repeat. A different mindset is required to understand zero-knowledge proof privacy.
By projecting your own view of ZEC onto the whole world, you are revealing your usage patterns of ZEC. I suggest that you should be more careful with your own opsec here. Anyway, it is irrelevant: All the world is not you.
Even for that use case, time within the shielded value pool is important. Linking close-in-time BTC→ZEC→BTC swaps in similar amounts is trivial for cross-chain analytics. That is not a Zcash problem: It is a PEBKAC problem. And it is an even worse problem if using Monero as a Bitcoin mixer. The amounts on the BTC side are always fully transparent; and Monero mixins definitely leak enough information for a confirmation attack. If BTC→XMR and XMR→BTC swaps show similar amounts on the BTC side (adjusted for known XMR/BTC price data), and the BTC chain preserves the approximate times when the swaps occurred on the Monero side, Monero preserves a clear trail leading from one transaction to the other—a trail that is highly improbable to occur by random chance—even if you churn. Zcash has no such problem.
Linking BTC→ZEC and ZEC→BTC trades of very different amounts, far apart in time—LOL, good luck with that. (I also have some other tricks which, for obvious reasons, I will decline to discuss publicly.) I have never used XMR for this purpose, for the above-stated reasons inter alia.
No, I didn’t. I mentioned that I think it’s a good idea not to show your counterparties if you have a large number of shielded notes in your wallet. That information would reveal nothing else, in itself; in particular, it would not reduce the notes’ “anonymity set” as you put it, counting potential inputs. In anonymity matters, I always just like to make things look as ordinary as I can.
This is true, within the four corners of what I have quoted. I use fully-shielded ZEC with counterparties who pay or accept it. For instance—not revealing anything that isn’t already public—I have some domain names registered with Njalla (onion). Njalla only has shielded Zcash addresses in their shopcart; if you send from a shielded address, then the tx is fully-shielded. I recommend them to others, and I recommend using fully-shielded ZEC with Njalla.
True. I will say it: Zcash blocks are too big and too fast. I should have said it years ago. Now, I am burned.
Question: I have never pruned—not on any chain. (I actually run zcashd with txindex enabled, at a very moderate cost, so that I can examine historical transactions without hitting an untrusted block explorer.) Do you have any practical, hands-on advice for how to switch suddenly to a very tight pruning policy, without potentially somehow shooting myself in the foot? I don’t want to—I really do not want to. But I may have no choice. (I have not even tried to catch up now, due to this aspect of the problem.)
That forbids people who aren’t rich from running full nodes. 2.14GiB per day devoted to zcashd alone may be trivial to you. It is cost-prohibitive to me, and no doubt to many others around the world.
The disk cost may be partly resolved by pruning—but as I have repeatedly urged in Bitcoinland, disk cost is, albeit problematic, the least problem. Pruning does not help with network cost. (Fortunately not an issue for me; but I have personally spoken to others for whom Blockstream Satellite makes obtaining the whole Bitcoin blockchain a possibility. Zcash has no equivalent infrastructure; and its blockchain is set up to grow much faster.) Pruning also does not help with the resource-use issues from UTXO set size (Zcash transparent pool will behave identically to Bitcoin here), or with any potential performance issues in the nullifier system that Zcash needs to prevent double-spends in the shielded pools.
And running a full node is even more important for Zcash than for Bitcoin: Light wallets for Zcash will never be able to match the privacy of running your own zcashd, unless they switch to some form of fancy PIR. A full node essentially gives the theoretically maximum benefits of PIR for viewing your own transactions.
(Yes, I am a “small-blocker” in Bitcoin. There is a reason for that. I never did “our team, rah rah” type of politics on any side.)
Edit: Fairly restored some context that I inadvertently chopped up in a way that I did not intend. I noticed this myself on a reread. See diff.