The Helios poll should gage what CAP members want to do with t-addresses. And, in my opinion, the poll should be lean and to the point. No explanations or sugar coating.
I will give a rough example, but you get the point.
Example (select only one):
Do not ever deprecate t-addreses.
Deprecate t-addresses only after 51% of total ZEC in supply is in shielded pool(s).
Deprecate t-addresses only after regulatory certainty is in place.
Deprecate t-addresses only after hardware wallet support is in place.
Deprecate t-addresses right now.
In my opinion, the poll result should be binding. As a CAP member, Iām happy to accept anything the CAP votes, no matter how much I may disagree with the result.
The thing is, the Zcash Community Advisory Panel canāt force anyone to stop using taddresses. Nor can the Zcash Foundation, nor can the Electric Coin Co, nor can anybody on the planet!
Zcashers can keep using taddresses, and they can keep using software that supports taddresses and keep using a blockchain that supports taddresses if they want to. If thereās a group that wants to declare the existence of a chain-fork that excludes taddresses, that could be interesting! I canāt stop you, and I wouldnāt try, any more than I could have or would have stopped the Ycash chain-fork. I would be happy to use that new zaddress-only chain-fork (in addition to continuing to use the t-addresses-and-zaddresses chain-fork).
But you shouldnāt imagine that you can stop others from using a chain-fork that keeps supporting taddresses. They might! Or they might not. That would be up to them.
Then how can ZCAP decide to fund for Zcash development? Whatās the point of ZCAP? Whatās point of all of this discussion, why were you silent? You couldāve shared your opinion or stance much earlier, so we couldāve discussed a different subject. What do you mean ZCAP canāt enforce? how is anything going to be enforced? Who is going to decide HALO 2 deployment? who is going to make a call on old shielded pool deprecation.
Sure, ECC could make a software change that eliminates t-addresses. So could anybody! So could the Zcash Foundation. So could anyone else with even a little bit of software development skill. In fact, anyone who wants to do that could probably just use that software change that one of the Zcash-clones has done. I think itās called āARR Chainā? There are one or more Zcash clones out there that have already made this software change.
What ECC canāt do ā and what literally nobody on this planet can do ā is force people to download and run that software and put their money into it.
I would be interested in doing an official zcap poll (or bundling such a question into the next time we convene zcap) to the extent weād use it to pick ZF roadmap and priorities. Maybe ECC would agree to follow the outcome of it too.
Iām personally most interested in plans that discourage t addr use without prohibiting them altogether
There are many Zcash forks that are z-addrs only and they too have abysmal usage rates. If there was more of a community around the Zcash forks and blockchains using Zcashās core tech (zk-SNARKs) then it can help gauge realistic goals for increasing shielded pool usage + any ideas/research from those communities.
Anyone who does not want to be constrained by the 16 week End-of-Support halt for their use of zcashd, can make a very simple change to the code (far easier than any of the code or chain forks) and then compile the code. The only constraint here is that ECC doesnāt support versions that have reached ECCās EoS halt, so those users would need to either support themselves, or find support elsewhere. Yes ācompile the codeā is a barrier to some users, but anyone could provide that support, if there were users who wanted it. Someone could literally fork zcash/zcash and all they do is patch the EoS halt, build binaries, and distribute them to users. In doing so, they would be taking responsibility for supporting those users, and could offer whatever support policy they want.
Forcing users to always use ECCās zcashd would look like zcashd having an auto-update feature, so the default is that anyone choosing to install ECCās software once and then forgetting about it will automatically follow everything ECC subsequently decides. Thatās something ECC has strongly opposed since the beginning, preferring that users make a conscious choice about the software they run.
