Oh, thanks! I’ll update my post above …
I don’t agree. If, say, the question on ZIP 235 was answered with the total number of votes for “ZIP 235 should be a low priority for NU7” + “I do not support enabling ZIP 235” exceeding the total number for “ZIP 235 should be a {high, medium} priority for NU7”, then that would be a pretty clear signal not to include it, regardless of it already having been implemented. Consensus changes have a complexity cost that must be balanced against their utility. The implementation cost in full nodes is only part of a given change’s overall complexity cost.
In particular, I absolutely do not want to establish a precedent that merely implementing a proposal’s consensus changes is sufficient to get it into the Zcash protocol, without skeptical consideration of its utility. I think that would be actively harmful for the protocol’s long-term complexity and security.
I personally consider choosing the “should be a low priority” option for a given ZIP to also effectively be a vote against, especially in an otherwise busy upgrade.
I don’t see any point. My comments (and @nuttycom’s, I think) have been addressed, and there wasn’t any problem in doing so within the character limit.
With my ECC engineering manager and protocol designer hats on, it is important to get feedback relatively soon, so that the set of ZIPs that will need to be integrated and audited can be nailed down. It ideally would have already been decided by now.
ZIP 2002 is uncontroversial and complete in itself. I disagree that it doesn’t achieve its goals without ZIP 235; its goals are described in its Motivation section and it achieves them. There is no point in polling on it.
Note also that, by allowing the fee to be calculated for a standalone transaction without context from the chain, ZIP 2002 simplifies some Zcash-supporting software. So, unlike every other ZIP proposed for NU7, it arguably has a net negative complexity cost. That, plus the fact that we’ve been waiting for years to include it with the next transaction version change, makes it a “no brainer” to include.
@Dodger - A few more comments.
- In the poll description, can we change the first sentence of the NSM section from:
Shielded Labs has proposed three ZIPs to specify parts of the NSM, which could be deployed selectively or in stages:
To:
Please review this background information and FAQ from Shielded Labs who has proposed three separate ZIPs, which can be deployed selectively or in stages:
I’d like the background information we provide to be made as explicit as possible and my concern is that the current “NSM” link will be overlooked.
- Question 5 (ZIP 233) currently reads:
ZIP 233 (Network Security Mechanism: Burning) will enable the voluntary burning of ZEC to remove it from circulation, with the intention that burnt ZEC be reissued as part of future block rewards.
After “…part of future block rewards…” please add “…while maintaining the 21 million coin cap.”
- Question 6 (ZIP 234) currently reads:
ZIP 234 (Network Sustainability Mechanism: Issuance Smoothing) would smooth the issuance curve, and reintroduce burnt coins into circulation in a predictable manner, as part of future block rewards. (This is dependent on including ZIP 233.)
After “…as part of future block rewards…” please add “…while maintaining the 21 million coin cap.”
- Question 7 (ZIP 235) currently reads:
ZIP 235 (Network Security Mechanism: Burn 60% of Transaction Fees) would enforce the burning of 60% of transaction fees (reducing the amount received by miners to 40%). (This is dependent on including ZIP 233.) Please indicate how you believe this feature should be prioritized.
Can you please specify that 60% of transaction fees is “currently approximately 210 ZEC per year”?
I understand where you’re coming from, however, this poll contains a lot of information for the 200 ZCAP members to review if we want them to make thoughtful and informed decisions. Most participants do not follow Zcash as closely as we do, so breaking this into smaller, more focused polls would make it easier for them to fully consider each topic. Also, this poll is happening during the holiday season when many people will likely be traveling or spending time with friends and family.
…it is important to get feedback relatively soon, so that the set of ZIPs that will need to be integrated and audited can be nailed down. It ideally would have already been decided by now.
I believe ECC may poll ZAC members in January, so postponing the ZCAP poll would allow for both polls to be conducted around the same time. While I’m sure you agree, ZCAP should not be the only deciding factor for what gets included in NU7.
The second part of the question should be deleted as ZIP 233 does not include ZEC being reissued into future block rewards. You might be able to rephrase it as “…with the intention for ZEC to be reissued as part of future block rewards.”
This is inaccurate: ZIP 233: Network Sustainability Mechanism: Burning says:
burn_amount does not result in an output being produced in any chain value pool, and therefore from the point at which the transaction is applied to the global chain state,
burn_amount
is subtracted from the issued supply. It is unavailable for circulation on the network at least through to the end of the block in which the transaction is mined. ZIP 234 specifies a potential mechanism by which the burned funds would again become available.
This is part of the problem with referring to the action of ZIP 233
as “burning”. It needs to be clear to users who make use of this mechanism whether it is possible for the “burned” funds to be reissued in the future. The current wording of this section clearly suggests that such reissuance is a possibility, and that ZIP 234
merely specifies one mechanism by which it might happen.
(I raise this point because I, along with other ZIP Editors, specifically objected to the use of “burning” as the term for this operation because in all other blockchain contexts I’m aware of, “burning” refers to an action that permanently reduces the supply.)
I’m not sure I understand what part of my quote you believe is “inaccurate”. If ZIP 233 were implemented without ZIP 234 or a similar mechanism, any ZEC that was burned would be permanent, reducing the supply. On its own, ZEC burned through ZIP 233 is just as “burned” as Ethereum coins burned through EIP 1559.
With regard to how to phrase the question in the poll, what Dodger and I agreed on seems appropriate: “ZIP 233 (Network Sustainability Mechanism: Burning) will allow the voluntary burning of ZEC to remove it from circulation, with the goal of reissuing the burned ZEC as part of future block rewards.”
We can clarify the second part of the question to ensure people understand reissuance is dependent on ZIP 234 or a similar mechanism.
This is part of the problem with referring to the action of
ZIP 233
as “burning”. It needs to be clear to users who make use of this mechanism whether it is possible for the “burned” funds to be reissued in the future. The current wording of this section clearly suggests that such reissuance is a possibility, and thatZIP 234
merely specifies one mechanism by which it might happen.
I understand your point. Perhaps instead of saying “burned coins get reissued in the future,” it might be clearer to say, “coins are burned with the intention of issuing more coins in the future, while adhering to the 21 million coin cap.” The subtlety here is that it’s not the specific coins that are being burned that are reissued, but rather, we are issuing new coins in a systematic manner based on what has been burned, up to the 21 million coin cap.
I understand your point. Perhaps instead of saying “burned coins get reissued in the future,” it might be clearer to say, “coins are burned with the intention of issuing more coins in the future, while adhering to the 21 million coin cap.” The subtlety here is that it’s not the specific coins that are being burned that are reissued, but rather, we are issuing new coins in a systematic manner based on what has been burned, up to the 21 million coin cap.
Right: it’s important that it be clear whether burning permanently reduces the supply to be below the 21M cap, or not. Another way to think about this is that if it’s possible to reintroduce the burned value, then the cap remains 21M coins; otherwise the cap itself is reduced.
Maybe the easiest way to adjust the ZIP to make this clear is to state it as: “Value burned in accordance with this ZIP does not permanently reduce the supply cap; this value may be reissued in the future.” But rewording in this fashion makes it more obvious how awkward the use of the term “burning” is for what’s happening. “Retraction” might be a better choice.
“Value burned in accordance with this ZIP does not permanently reduce the supply cap; this value may be reissued in the future.”
Thanks for suggesting revised language. I want to take a couple of days to think about it more, discuss it with the team, and refine the wording. After that, we’ll update the ZIP to make it clearer.