Yes, precisely. [Edit: Actually that assertion is simply false; there are attacks that apply to this situation where the seed phrase is intentionally revealed that would never apply to normal transfers.]
The risks involved in moving all of my funds, which I would never normally do, twice, are extremely serious:
- I need two hardware wallets (because there are currently no hardware wallets that support
multi-accountmulti-seed for Zcash [edit: with corresponding software wallet support]). So at best, I’ve added the opportunity of a supply chain attack on the second wallet. - I have to keep the seed phrase of the second wallet secure, so the whole process needs to be done in a physically secure environment (and I need enough time in that environment where I can pay close attention without interruptions).
- I have to communicate the address of the second hardware wallet to the software wallet in such a way that I can check it on the first hardware wallet (and vice versa for the return transfer). I can’t easily compare QR codes so I have to communicate full addresses, and it’s actually not trivial to get wallets to show full UAs.
- As it happens, I designed F4Jumble and its use in UAs, and I understand the security properties I’m getting from UAs that in some cases would allow me to safely check only partial addresses (although in a case like this I would still check full ones if possible). I don’t assume other users to understand this.
- I’ve added two opportunities to make a mistake or fall victim to an attack in the transfer in any of (at least) the following ways:
- selecting the wrong address in such a way that I end up also checking it against the same wrong address;
- some kind of spoofing attack where the h/w wallet display does not give me enough information to detect the attack;
- failing to check everything I needed to.
- I also have to make certain that I’ve received the full amount back at the original wallet before revealing the seed phrase to the voting software. But doing so requires me to trust software and the general-purpose platform it’s running on. The h/w wallet itself does not display balances or incoming transactions, so there is actually no way to ensure that the return transaction is confirmed using that hardware on its own.
- I could “confirm” the funds have been returned, use the seed phrase, and then be subject to a rollback attack that steals them using that seed. (This is a risk that is not present for normal transfers, even of all my funds.) Or my wallet might be displaying received funds based only on a mempool transaction.
And for what? To use a protocol I don’t trust (because it uses an unaudited circuit that at the very least relies on nontrivial undocumented properties to avoid potential soundness bugs) and don’t think people should be relying on anyway?
Cryptocurrency transfers always involve risk, but it is usually acceptable risk because you’re strictly limiting how much you send at a time, and if something goes wrong you will stop and figure out what the problem was. But in this case that would also be artificially limiting my voting power.