Good catch. I’ve updated above and will make sure it’s reflected correctly in the polls.
1 Like
Note that the suggested approach to shielded coinholder voting is a hassle (in that it requires moving shielded funds to the control of a one-time-use key, and then moving them back out before using the untrusted voting software) but it does not introduce risk to funds apart from the normal risks associated with making those transfers.
5 Likes
Unshielding is not required.
1 Like
Do we have instructions for the actual vote yet? I’ve never done this before but I believe there are magic strings (e.g. URLs) that we need to put into the coinvoter app, yes?
1 Like
Coinholder polling will start later today. I will announce and provide detailed instructions on the forum and X.
2 Likes
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.
6 Likes
This was quoted out-of-context. The original post was clear: I will not unshield it just for a vote (so I will not use the transparent voting protocol), and I have other explicitly stated issues with the shielded voting protocol.
This is not correct; Keystone devices can support 3 seeds each. However, Zashi does not support interacting with more than one of those seeds, so for practical purposes you’re correct. I do want to distinguish between accounts and seeds, though; one would not want to use a distinct ZIP 32 account for this.
3 Likes
Personally I use 2 machines with Zkool. One completely offline to generate the seeds and to sign the transactions, and one online to broadcast everything with the viewing keys:
This way, unless I’m missing something, your seeds are 100% safe and never exposed.
Quick update on the coinholder poll: The Voting Authorities are coordinating to get the poll set up as soon as possible. While we’re aiming to have it live today, there may be a delay as final steps are completed. We’ll share updates as things progress and appreciate everyone’s patience.
7 Likes
With yesterday’s update to question 3, its going to be unclear if the token holder vote saying NO to 60% of tx-fees going to the NSM will be an issue of parameterization (60% is very high!), or fundamentals.
Ideally we could have two responses, support but different parameter, support at 60%, reject.
(I do separately agree, splitting out what aspects of the NSM people are voting on is great!)
1 Like
Can question (2) be reworded a bit to make it clearer that the halvenings will be removed? So changing from
What is your general sentiment toward adding protocol support for the Network Sustainability Mechanism (NSM), including smoothing the issuance curve, which allows ZEC to be removed from circulation and later reissued as future block rewards to help sustain network security while preserving the 21 million ZEC supply cap?
to instead:
What is your general sentiment toward adding protocol support for the Network Sustainability Mechanism (NSM), which includes: (1) removing the discrete halvenings, and instead smoothing the issuance curve. (2) Allowing ZEC to be voluntary burned, and later reissued as future block rewards to help sustain network security while preserving the 21 million ZEC supply cap
I’m sorry, but we can’t change the questions at this point because the poll is already live. We shared draft questions in advance and gave everyone an opportunity to review them and provide feedback. If needed, we can run future polls that go into more granular questions, but this poll is intended to capture general sentiment on the proposals that have been put forward.
I’m open to hearing your concerns and considering a different parameter. Could you elaborate on your reasoning here and propose an alternative in the NSM thread?
2 Likes
A post was merged into an existing topic: Network Sustainability Mechanism (NSM)
Well, the suggestion I had to include a “qualified support” response would have helped with that, but it was not taken up.
1 Like
Where? The last post you made on this discussion is that it hadn’t come out yet. I don’t see the details with the URL we have to put into the voting app or anything.
Here 
1 Like
It would also be a self-fulfilling prophecy if there are no wallet supporting Sprout after zcashd deprecation because we don’t ever build one.
The wording of the question seems to imply that tx v4 might as well be removed because there are no wallet that supports Sprout after zcashd deprecation anyway.
That is the implication I intended with that sentence, yes. If you want to build a wallet that supports Sprout, have at it. I think it’s a waste of time, and I don’t think that hypothetical wallet support should be used as an argument for retaining Sprout. I was simply pointing out what is most likely to happen (that there will be no wallets that support Sprout after zcashd stops working).
I don’t really want to build a wallet for Sprout, nor do I think Sprout should be kept.
I wanted to point out that the question could be interpreted in this way and IMO, it presents some bias.
Edit: This question → “This would disable the ability to spend Sprout funds, for which there will be no wallet support in any case after the prior deprecation of zcashd.”