Double negatives are always confusing. I’d make it even more explicit:
a. Support (i.e. disallow v4 transactions and thus disable ability to spend Sprout)
b. Oppose (i.e. keep v4 transaction and thus keep the ability to spend Sprout)
4 Likes
The draft ZIP here is not sufficiently complete for me to be able to understand what is being proposed. Remember that a ZIP must be sufficiently complete that an implementer of the standard is able to fully satisfy the constraints of the ZIP without reference to any other implementation. In addition, I don’t believe that problem statement that a single, standardized scanning algorithm is required in order to produce a consistent view of wallet state is correct; for example, in-order and out-of-order scanning must produce the same terminal wallet state irrespective of the order in which blocks are scanned because the state of a wallet is a function of the state of the chain, not a function of the order in which the chain is scanned.
4 Likes
@Lowo88 As I said earlier more directly, if a wallet has undeterministic transaction history or balance, it is a bug in its code. There is no need for a ZIP to enforce that. Imagine if in real life your wallet behaved like that…
4 Likes
Can we include a question about retiring the transparent pool? Not for NU7, but just to continue the discussion with coinholder input.
1 Like
For this poll, the goal is to gauge community and coinholder sentiment on protocol features that are finished or expected to be ready within the next year. We also had a January 15 deadline for proposing questions for this round of polling, so we’re not adding new questions at this stage. That said, this is a topic that could make sense to include in a future poll.
3 Likes
Ok, I understand now thanks @nuttycom as well. This helps with my understanding of what’s going on with wallet features it’s a bug got it. 
1 Like
I know I’m slightly after the deadline; that’s because I was on holiday until today, and somewhat successfully resisting the temptation to do Zcash work instead of enjoying Paris with my friends.
I believe question 2 should be split into two questions:
2a. What is your general sentiment toward the following aspects of the Network Sustainability Mechanism: the ability to explicitly remove funds from circulation (ZIP 233), and smoothing of the future issuance curve leading to the eventual reissuance of these removed funds (ZIP 234)?
2b. What is your general sentiment toward the following aspect of the Network Sustainability Mechanism: requiring 60% of transaction fees to be removed from circulation?
This reflects the fact that in the ZIP Editors’ initial viability assessment of NU7 proposals, we were significantly more negative toward ZIP 235 than toward ZIPs 233 and 234. For the former we were “Inclined toward no; based on a combination of Safety and Usefulness issues, there is insufficient reason in our opinion to make this change in an otherwise heavy upgrade.” due primarily to limited benefit: “The amount involved is very low (as calculated in the ZIP), and so the rationale points given in the ZIP imply limited benefit in the short-term.”
Question 5 frames the effect of disabling v4 transactions in an entirely negative way. The point of it is to reduce attack surface and complexity. Also, typical users will not be able to spend Sprout funds in any case, because the only wallet that can do so is the zcashd internal wallet which will cease to function at NU7. That is, it should be written as something like:
- What is your general sentiment toward reducing the complexity and attack surface of the Zcash protocol by disallowing v4 transactions? (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.)
Question 6 seems to serve no purpose in the context of NU7 sentiment polling, since Tachyon will not be ready for NU7, and development of it will proceed anyway. (If, on the other hand, the scope is intended to be wider and include features not proposed for NU7, it is odd to include Tachyon but not Crosslink.)
I believe the fee market proposal mentioned in question 8 has not had time for adequate analysis.
Question 9 doesn’t include the main benefit of consensus accounts. I would suggest the following change:
- What is your general sentiment toward adding protocol support for consensus accounts, which generalize the functionality of the dev fund lockbox and reduce the operational expense of collecting ZCG funds and miner rewards?
Re: Question 10, I would argue that quantum recoverability (which for transparency, is primarily my proposal) is a necessity for the long-term security of the protocol. I think we are likely to do it anyway on the next note plaintext format change. (Either memo bundles or ZSAs require a note plaintext format change.) It’s a low-risk change because it doesn’t change the circuit (whether or not ZSAs are deployed at the same time) and is designed not to pose any significant risk of a regression of pre-quantum / discrete-log-dependent security. Whether and when to include it is the kind of highly technical decision that in my opinion should be left to protocol experts, not voted on.
Also note that the name has changed from “Quantum Resilience” to “Quantum Recoverability”, as reflected in ZIP 2005.
In any case, if we must vote on it, I would suggest the following wording change:
- What is your general sentiment toward the “Orchard quantum recoverability” proposal, which aims to ensure that if the security of elliptic curve-based cryptography came into doubt (due to the emergence of a cryptographically relevant quantum computer or otherwise), then new Orchard funds could remain recoverable by a later protocol — as opposed to having to be burnt in order to avoid an unbounded balance violation?
I would also like to point out that although the poll asks independent questions about each feature, actually there are some dependencies as shown in this diagram. I will be updating the diagram tomorrow to include the new proposals that are being voted on.
2 Likes
Hi @daira. Thanks for the feedback.
Our goal was to gauge general sentiment on the NSM, but I understand your reasoning here. I’ll discuss this with the team tomorrow morning and follow up.
I am open to making this change, but want to confirm with Alex and Josh. I’ll follow up with you tomorrow.
Please see Sean’s comment here for context. The question is specifically about adding a new shielded pool to support Tachyon, which Sean expects deploy later this year.
That’s true for many of the proposals included in this poll. The purpose here is to gauge general sentiment toward a dynamic fee mechanism. The design is not final, and we expect to refine it based on feedback received during development. It’s also worth noting that many of these updates can be rolled out gradually through node policy changes.
I will make your proposed change.
I will make your proposed change.
Are there technical constraints that would prevent the creation of a sprout only tx builder for the sole purpose of extracting funds post zcashd deprecation (provided tx v4 remains)?
If not, that’s something that we could consider funding.
I withdraw the concern, this is fine to include if Sean wants it. (I am highly skeptical it will be this year, but that’s okay.)
I’d say “two” rather than many (consensus accounts has also had less than a month for comment), but it’s fair that dynamic fees is not the only one I guess. I withdraw the concern.
(Aside from Tachyon which does not have a detailed spec proposal, all of the other questions besides consensus accounts and dynamic fees relate to spec proposals that have had more than a month for comment.)
Thanks for your responses on the rest.
1 Like
No, and in my opinion we should not consider funding that. It would be building something that is unlikely to ever be used; or if it is, then it would only be by self-fulfilling prophecy because some holders concluded that zcashd deprecation was not actually the deadline for getting funds out of Sprout.
The motivations for ZIP 2003 are very clearly explained and I urge people to read them.
I should mention a technical issue here. If we have an upgrade that changes the note plaintext format and does not include ZSAs, I believe that the new format for Orchard (with lead-byte \mathtt{0x03}) should nevertheless include the \mathsf{asset\_base} field. This would be required to be the constant 32-byte value \mathsf{LEBS2OSP}_{\ell_{\mathbb{P}}}(\mathsf{repr}_{\mathbb{P}}(\mathcal{V}^{\mathsf{Orchard}})) as long as ZSAs are not deployed — and it would be specified that any other value is reserved for a future deployment of ZSAs, not for any other purpose. The change from \mathsf{memo} to \mathsf{K^{memo}} would be applied iff memo bundles are deployed with this note plaintext format change.
The advantage would be that no further note plaintext format change would be needed to deploy ZSAs, which would simplify ecosystem compatibility with the ZSA deployment: wallets that do not support receiving ZSAs would automatically do the right thing for all outputs. This does not require any dependency on the ZSA specs, and so it has almost zero downside apart from front-loading a 32-byte increase in the note ciphertext size for an Orchard output.
Whether to do this is a technical protocol design decision and does not need to be voted on. The reason to mention it here is that it makes “deploy memo bundles + quantum recoverability in NU7, then ZSAs in NU8” a more feasible path. (I know @nuttycom was interested in this approach; I’m undecided but absolutely do want ZSAs to be deployed.)
[Edit: this idea is filed as Include AssetBase in the note plaintext · Issue #1217 · zcash/zips · GitHub .]
1 Like
My preferred path at this point is to make NU7 essentially as minimal as we can, with the extensible transaction format, the absolutely-minimal (definition TBD) version of consensus accounts required for lockbox disbursement, explicit fees, NSM fee burning, and quantum resilience with the requisite note plaintext changes. While I’d love to get memo bundles in, I think at this point I’d like to get them in with a separate release; the extensible transaction format makes this more reasonable (though still a larger disruption than if the pre-ZSA Sapling and Orchard bundles were to be built with extensible memo support.
One possibility is that the pre-ZSA Sapling and Orchard bundle types could be constructed to anticipate memo bundles but not require their use; that’s something we should discuss in an R&D meeting.
Doing memo bundles separately from quantum recoverability is adding unnecessary complexity because it means the note plaintext format change must be done in two steps. This is because the \mathsf{memo} to \mathsf{K^{memo}} change alters the plaintext length in a way that can’t be performed in advance (unlike the addition of \mathsf{asset\_base}).
To me the deployment schedules that make the most sense are:
| Feature | A | B | C |
|---|---|---|---|
| Extensible tx format | NU7 | NU7 | NU7 |
| Consensus accounts | NU7 | NU7 | NU7 |
| Explicit fees | NU7 | NU7 | NU7 |
| Disallow v4 txns | NU7 | NU7 | NU7 |
| NSM ZIP 233 | NU7 | NU7 | NU7 |
| NSM issuance smoothing | NU7 | NU7 | NU7 |
| Quantum recoverability | NU7 | NU7 | NU7.1 |
| Memo bundles | NU7 | NU7 | NU7.1 |
| ZSAs | NU7 | NU8 | NU8 |
and I favour schedule B. (Features that are not mentioned, such as NSM ZIP 235, can be done whenever.)
2 Likes
To follow up on my post from yesterday evening:
We are okay making this change.
We will split the NSM into two separate questions, but I wanted to respond to your comment.
I understand your concern about usefulness. However, while fees are small today, that won’t necessarily always be the case. They can change quickly as usage and demand evolve. From our perspective, it’s easier to introduce ZIP 235 before fees become meaningful, rather than waiting until there are stronger incentives to resist it.
Moreover, as I’ve mentioned to you before, implementing the NSM now with ZIP 235 also has the benefit of shaping behavior and market dynamics. Confidence in the network’s long-term sustainability is itself a meaningful economic signal, and having that mechanism clearly defined at the protocol level could matter to users and investors who are concerned about Bitcoin’s unresolved security budget issue.
Also, whether this ends up being a “heavy upgrade” depends in part on the outcome of this polling. If there is limited support for certain proposals, they may not move forward at all, which would naturally reduce the scope and complexity of the upgrade.
Here are the two questions:
- 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?
- What is your general sentiment toward burning 60% of transaction fees via the Network Sustainability Mechanism (NSM)? The goals are to prevent miners from manipulating fees, to demonstrate Zcash’s commitment to long-term sustainability, and to burn ZEC so that it can be re-issued in the future without exceeding the 21M supply cap.
I don’t understand how miners can manipulate fees. They can choose which transactions to include based on fees, but that’s not the same thing. That does of course gives them some leverage over fees if mining pools collude to censor transactions that do not have a particularly high fee, but ZIP 235 doesn’t prevent that, and that is not something that is currently happening. (Miners appear to be pretty strictly following ZIP 317, with occasional coinbase-only blocks.)
So I suggest writing 2b as just:
2b. What is your general sentiment toward burning 60% of transaction fees via the Network Sustainability Mechanism (NSM)? The goals are to demonstrate Zcash’s commitment to long-term sustainability, and to burn ZEC so that it can be re-issued in the future without exceeding the 21M supply cap.
Apologies for the confusion. I omitted that miner manipulation is in the context of dynamic fees. I’ve updated the question below:
- What is your general sentiment toward burning 60% of transaction fees via the Network Sustainability Mechanism (NSM)? The goals are to demonstrate Zcash’s commitment to long-term sustainability, to burn ZEC so that it can be re-issued in the future without exceeding the 21M supply cap, and in the context of dynamic fees, to prevent miners from manipulating fees.
1 Like
Below is the final list of questions. We’ve decided to remove “Abstain / Indifferent” as a response option. Because each question is voted on independently, and responses cannot be linked across questions, there is no need for an option to abstain, and excluding it helps produce clearer signals of support or opposition. If you wish to abstain on a particular question, simply skip that question.
Poll Questions
-
What is your general sentiment toward including Zcash Shielded Assets (ZSAs) as a protocol feature?
a. Support
b. Oppose -
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?
a. Support
b. Oppose -
What is your general sentiment toward burning 60% of transaction fees via the Network Sustainability Mechanism (NSM)? The goals are to demonstrate Zcash’s commitment to long-term sustainability, to burn ZEC so that it can be re-issued in the future without exceeding the 21M supply cap, and in the context of dynamic fees, to prevent miners from manipulating fees.
a. Support
b. Oppose -
What is your general sentiment toward including Memo Bundles, which let transactions include memos larger than 512 bytes and share a memo across multiple recipients, and also permits inclusion of authenticated reply-to addresses, as a protocol feature?
a. Support
b. Oppose -
What is your general sentiment toward adding protocol support to enable Explicit Fees, allowing transaction fees to be clearly specified and committed to in the transaction?
a. Support
b. Oppose -
What is your general sentiment toward reducing the complexity and attack surface of the Zcash protocol by disallowing v4 transactions? 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.
a. Support
b. Oppose -
What is your general sentiment toward deploying a new shielded protocol or pool to address scalability challenges as part of Project Tachyon?
a. Support
b. Oppose -
What is your general sentiment toward adding protocol support for STARK proof verification via Transparent Zcash Extensions (TZEs) to enable Layer-2 designs on Zcash?
a. Support
b. Oppose -
What is your general sentiment toward adding protocol support for a comparable-based, dynamic fee mechanism?
a. Support
b. Oppose -
What is your general sentiment toward adding protocol support for consensus accounts, which generalize the functionality of the dev fund lockbox and reduce the operational expense of collecting ZCG funds and miner rewards?
a. Support
b. Oppose -
What is your general sentiment toward “Orchard quantum recoverability”, which aims to ensure that if the security of elliptic curve-based cryptography came into doubt (due to the emergence of a cryptographically relevant quantum computer or otherwise), then new Orchard funds could remain recoverable by a later protocol — as opposed to having to be burnt in order to avoid an unbounded balance violation?
a. Support
b. Oppose
12 Likes
The questions look fine now, except that “Orchard quantum resilience” should be “Orchard quantum recoverability”.
I suggest adding a “Qualified support” response option for each question. The problem this solves is that voters often would support a proposal only under certain conditions (which they would then explain on the forum). Having this as an explicit option does not preserve all of that information, obviously, but it provides an indication of how much of the support comes with caveats. It also potentially allows people to vote “Qualified support” if they have a specific, potentially solvable, issue that they would otherwise feel required an “Oppose” vote or abstention.
[Deleted argument questioning the removal of “Abstain”, because skipping a question is abstaining on it. So that’s just a ballot encoding issue.]
I should mention that I will not be participating in the coinholder vote because:
- I hold my ZEC shielded. I will not unshield it just for a vote.
- The current protocol and implementation for shielded coinholder voting has not been adequately reviewed or audited, and required unsafe operations the last time I looked.
2 Likes