It’s a distraction, puts the ZSA schedule at risk, and its near to mid-term value is nominal at best. Let’s not continue to make the same mistakes we’ve made in the past.
There has not be a clear answer as to why this (all up) is necessary right now. It is non-trivial. There is no need to rush this to put other more important things at risk that will drive adoption.
Please do not imply that I don’t have confidence in the team.
Good to know, but when I read what you wrote, that’s how it looks to me. End of the day, we both want is best for Zcash
I don’t think this is about having confidence in the teams. It’s just the reality that as far as I can remember every single Zcash feature has been underestimated and it took longer than planned to implement. It’s a complex protocol.
I’ve voiced my reservations with the NSM previously in the forums. I just doesn’t seem a good time to implement it, with the exception of the deposit field which we should take advantage of the fact that we’ll already need a transaction format change. The rest IMO should be done later. (This kinda conflicts with my ZIP editor view that the NSM ZIPs are fine, because this is not a really precise argument against it but mainly a hunch based on all previous work on Zcash).
The main aspect that bothers me is still the smoothing out of the issuance curve. It might be a simple code change but it’s a big change for the currency; it goes against of most people’s expectation of how issuance works. (It also gets rid of halvings which seem to be popular milestones for the currency.) The main justification for it seems to be that it’s apparently the only way to do it but I’m not convinced (and I’m desperately preventing myself of being nerd-sniped looking into it because I don’t think I should be one doing that). But again, that’s a mostly vibes-based objection.
My position here is that it’s fine to implement it now, given that it doesn’t actually activate until ~two years from now. If it is not implemented in NU7, then in order for the transition from the having-based schedule to the smoothing-based schedule to be minimally disruptive, it would either require that a NU8 including this feature be deployed and activated before that scheduled activation height, or wait an additional 4 years in order to be again deployed at a point where it does not “pull forward” the issuance curve.
I would prefer that the implementation be done now, and therefore avoid the potential need to rush out an NU8.
I think that labeling this as a “distraction” underestimates the complexity of other approaches to reintroducing explicitly burned funds. We shouldn’t be considering this feature just in terms of monetary value, but in terms of the value for the protocol as a whole. We’ve previously seen a number of good arguments for “burning” funds with the understanding that those funds would be reissued in the future. Introducing the burning mechanism without the reintroduction mechanism adds technical debt, similar to what we unfortunately face with the lockbox - ideally the disbursement mechanism would have been specified at the same time as the funding mechanism, but there wasn’t time to do both. By way of contrast, there’s ample time for Shielded Labs to do both the burning and reintroduction mechanisms in the NU7 timeframe.
I’m curious about the NSM vs ZSA situation you bring up. Maybe its better to hold off on ZSA’s until teams are ready? (I’m not sure) What’s your honest take here, because as bad as I want ZSA’s, dont we need to be realistic with timelines?
Appreciate your time
This makes a lot of sense to me too.
Appreciate the feedback.
I guess where I’m at, will it ever be a good time? I’ve found sometimes you just have to push through and try. I support the dev team, and I think we can pull this off.
Engineering Echo Chamber:
This debate is sucking the little bit of oxygen out of the momentum to communicate and sell ZSA, for greater user adoption.
How is the market going to consume such changes of what is on offer in NSM. How are the story tellers able to capture the imagination of current let alone future users.
The market can only consume so much change.
Including NSM is a hypothesis towards networ sustainability. NSM proponents do not even have close to current core zcash consensus, let alone consensus of zcash users on the fence.
This energy should be directed at keeping it simple.
Keep it simple for core engineers implementing.
Keep it simple for the story makers.
The zcash community has CONsensus on ZSA.
It is my opinion that if the NSM is not implemented in NU7, it will never be.
If Zcash marketcap and ecosystem grow, people will become more and more reticent to the smallest protocol change.
I mean if we already become cold feet at 1 billion $ valuation, nobody will make me believe that we will implement radical changes at 10, 20, 50 billions marketcap.
I think definitely there will be a good time, like in NU8. I’m confident we can pull if off in NU7 though, it just might take longer than what everyone is expecting.
Nothing is “necessary” and I don’t think that anyone is suggesting so. Distributing from the lockbox in a year is not necessary, just like an upgrade to ZEC emissions or fee allocations isn’t necessary.
My opinion is based out of the realities of where these different initiatives stand today. NSM is the clearly most designed and is also generally “supported” by the community. The Hybrid PoS/PoW is equally supported, but unfortunately its nowhere close to reality on the technical side. The lockbox distribution project is still on the drawing board, very far from community consensus nor technical design finality.
I’m a bit lost on how ZSAs are being invoked here (?) aren’t those features basically ready to deploy after their zcashd deprecation dependencies get cleared (?) presumably sometime prior to NU7?
I do think NSM is necessary. Zcash security model being a clone of BTC is no bueno.
Should Bitcoin security go down in flames in the future for some reasons (miners hiding their chronic unprofitability with highly leverage plays for example), it wouldn’t take long for markets participants to realize that ZEC has the exact same model. At that point whether you have ZSA or whatever nobody will care.
At least with NSM, Zcash would be reasonably shielded from something bad happening on the BTC side.
The infamous Bitcoin mining death spiral could never happen or it could happen in 6 months, nobody knows. But is it worth it to build on sand?
The ZSA changes are consensus rule changes, so they require a network upgrade. NU7 is the next possible network upgrade. In addition, the ZSA changes require a transaction format change, which I mentioned in Network Sustainability Mechanism (NSM) - #230 by nuttycom. Transaction format changes are highly disruptive to the ecosystem, and so we want to minimize the number of such changes. Since the NSM also requires a transaction format change, it’s better to do this in one network upgrade rather than two.
A compromise alternative would be to include the burn field (ZIP 233) in the new transaction format for NU7, but not include the change to the issuance curve. However, that then runs into the timing problems I point out in Network Sustainability Mechanism (NSM) - #253 by nuttycom
As I’ve previously stated, I am open to this compromise alternative. Is this something that @conradoplg, @daira, and @str4d also support?
This is a strong reason to include ZIP 233 alongside ZSAs. However, it seems the community has not yet determined how ZSA fees should be handled. To my knowledge, there has been minimal discussion about this topic. I think it would make sense to poll the community to determine whether ZSA fees should be burned or paid to miners.
What is the process for determining what gets included in NU7? Last week, we talked about polling ZCAP and ZAC on their preferences. Is that still the plan? If so, we should work together to determine the questions to be asked and how they are phrased.
@joshs @Dodger there are 3 (and I believe only 3) possible paths forward here:
Can you please clarify which of these approaches you’re advocating for?
To be clear, the NU7 ZIP Viability Assessment does not say anything amounting to “The code has been marked trivial” for the NSM ZIPs. For ZIP 233 it says, “Trivial addition to tx format. Non-trivial change to consensus rules, but that only affects Zebra.” For ZIP 234 and ZIP 235 it makes no mention of their implementation being “trivial”.
These aren’t the only three options. All three ZIPs can be deployed in NU8. Also, I don’t necessarily agree with your view that we’d have to wait “an additional 4 years in order to be again deployed at a point where it does not “pull forward” the issuance curve.” That topic requires more discussion.
I strongly disagree here; we can’t have two transaction format changes that require parser changes across the ecosystem within that short of a time frame.
Yes, I rather dislike attempts to play us off against each other. Everything @Josh and @Taylor have said presenting a skeptical view of NSM, and everything @nuttycom has said in support of ZIP 233 and ZIP 234, are reasonable and technically defensible. The differences are essentially about what the threshold should be for a proposal to get into the protocol, given the overall complexity budget and priorities for NU7.
With my ECC R&D Engineering Manager and protocol designer hats on, I think ZIPs 233 and ZIP 234 just barely meet the threshold for sufficient usefulness, and that this is arguable either way. ZIP 235 does not meet the threshold (as a consensus rule, which is what we’re deciding on).
I appreciate you taking the time to clarify. I shot from the hip with my perception of what I read and I could have worded it better reading it this morning. I was (wrongly) under the assumption that Josh supported the NSM deployment and was caught off guard by his statement. I was ignorant and I apologize for the feather ruffling.
I do think this needs to be better hashed out, all of this.
Note: I don’t bring them up. @Milton did and I just clarify.
I don’t think there’s a need to “hold off” anything. Let’s put in less dramatic words: It’s important to choose what to prioritize because engineering resources are limited.
I assume that when a community member says "I’d like this to be implemented", that thing they refer to is expected to be safe, well implemented, sufficiently audited and security proven. That is the “Zcash Standard” for protocol implementations. Zcash users expect that as it has always been the principle that drives core development in Zcash and that’s awesome.
What engineers and community members are discussing is what amount of work can be put into NU7 considering that the “Zcash Standard” is non-negotiable.
That distinction is not trivial. When a Zcash engineer has a remark when scoping something, it’s probably coming from that angle. Don’t focus on “the negative”, think about it the other way around. They aren’t say “no” they are probably saying “we can’t guarantee that all of this work can be done appropriately as the community expects within this context/limitations/timeline/etc.”
Okay, if this is an accurate statement then we should include ZIP 233 in NU7 because it’s necessary for any future upgrade that includes the other NSM ZIPs or ZSA fee burning.