My comment is about using unique Tor circuits to broadcast transactions. Some IP has to be the originator and a fresh Tor exit node is the best choice available for that. The issue, if you run zcashd behind Tor, is that you don’t get fine control over its networking and your best way to force it to have a new connection to Tor is to reboot it entirely. This can be disruptive and also raises its own metadata questions (as a node is going offline immediately before broadcasting just for a new node to come online and broadcast), yet if it’s solely behind Tor those may be considered negligible. I’m just discussing what the best path is, even if others are probably fine.
So if you want a fresh Tor circuit, without constantly rebooting zcashd or extensively modifying it, you want a separately run app entirely to connect over Tor, ensure uniqueness, and then broadcast TXs. This still could be a zcashd instance (boots up, presumably on a sufficiently unique circuit, broadcasts, killed) or a custom script which better integrates with and manages Tor, providing guarantees accordingly. So if we do write some Python script to handle this, the problem is you can only send transactions via some custom Python scripts where you have to manually ferry the bytes and…
That was the rest of my comment. You can have your Python script proxy zcashd’s RPC. Any wallet using the RPC to send transactions would have those calls intercepted, broadcasting TXs over fresh Tor circuits by the Python scripts. All of your other messages would still hit zcashd though and your wallet wouldn’t know the difference.
It’s the unique circuits part that makes this a better solution. Again, it’s probably fine just to have zcashd behind Tor as it should handle circuits per-socket, not per-app, meaning a few nodes will see your TXs from a few IPs already. The problem is when you do your second TX that will also be seen by a few nodes by a few IPs. Overtime, this could allow determining a series of TXs as all being from the same sender, despite coming from multiple Tor exit nodes. I’d have to check how frequently Tor rotates circuits, yet too frequently and you’ll have network stability issues, hence my commentary about a separate program effectively integrated with Tor which only lives for a few seconds for each individual TX.
I’ll again say Dandelion++ would also be a good step forward, and zcashd can do a lot with Tor itself to resolve these problems. My commentary about an additional service is because zcashd doesn’t and it’s much easier to write a script than maintain a fork of a large codebase you can’t quickly edit the networking stack of without risking ramifications. That doesn’t mean zcashd shouldn’t. Our grant to Arti should open this doorway more in the future, yet Arti has some code out we may be able to already work with, and failing that, we can even just work with the existing Tor codebase on these goals.