I think this fud relates to those who claims that Zcash is not private since most transactions are transparents.
5 Likes
T-address support reminds me of the web before Firesheep happened. Most websites supported only HTTP and used HTTPS selectively for payments and password input forms. Arguments were made that that HTTPS’s cryptography was to costly to implement for all connections. Most web users didn’t understand the distinction and Firesheep made it really simple to hack into other people’s accounts when they were on the same open WiFi network.
The situation is similar for Zcash. Most users don’t understand the distinction. Some of my friends have unknowingly put themselves at risk because they assumed “Zcash is private, right?” Those friends are knowledgeable security engineers, who are fully capable of understanding the protocol’s nuances. I have to assume the situation is even worse for everyone else.
Whether shielded adoption is hindered by the fact there are no libraries that make it quick, simple, and secure to set up shielded support in common platforms, or by regulatory fears, these arguments remind me of the ones that were made for only using HTTPS on password forms. We are forced to explain to users that to be secure they need to maintain a shielded balance and spend to t-addrs from there, which is reminiscent of telling people to “look for the lock” whenever they log in or enter their credit card information. Users shouldn’t have to think about it.
If Zcash adoption is contingent upon transparency—whether because of regulatory fears or poor shielded UX—that’s not real adoption. It doesn’t count. If someone is only integrating Zcash because they can re-use their existing bitcoin libraries, one of three things is probably true (a) they don’t value Zcash enough to do the work to integrate shielded, (b) they are afraid to integrate shielded, or (c) integrating shielded is simply too expensive. In cases (a) and (b), they are not really a Zcash adopter—they are not aligned with our mission. In case (c), that’s on us for not making it easy.
I don’t think the solution is to delete t-addrs from the protocol just yet, we need to first fix the usability of shielded, making it as easy to integrate shielded payments into anything as it is to integrate PayPal into anything, and then market Zcash to form a solid ecosystem of shielded adopters. Then we can delete t-addrs because nobody will be using them. IMHO, all future protocol changes should be in service of these goals. Everything else like getting rid of the trusted setup, ZSAs, PoS—while valuable—are opportunity costs we can’t afford when we need to be 100% aligned on making the technology eminently usable and establishing solid niches of adoption.
8 Likes
To continue the analogy I believe the focus need to be on wallets. The only reason the last 50% of websites moved to https was because browsers (mostly chrome if I recall) forced them to. The user experience for http became increasingly worse over time. All I was proposing in the thread was that we have a wallet that slowly (or quickly) makes the t-addrs experience worse over time.
Tbh I’m surprised at how controversial that idea is 
. I didn’t propose all wallets do it. I only proposed that we give users the option to use a wallet that does. No advanced settings users have to select or click. No ambiguity about reproducing an error. A support ticket for a T address only business would be, “you don’t support the ZECShielded wallet”. No work around recommending the users enable t addresses and close the ticket. Simple. A user installs the wallet and is guaranteed shielding.
2 Likes
Many interesting points here on the Zcash reddit channel:
I have heard the argument of “eww… transparent addresses” since I first stumbled upon Zcash. I think it’s bubbling back up because Orchard took away the favorite FUD’ing tool, the trusted setup.
All I will add is that I believe the approach of Unified Addresses is a great way of bringing more and more ZEC into the shielded pool, with Zcash wallets implementing auto-shielding. The problem of this approach is that it applies to people that use ZEC, not so much people that just want to zodl.
What will really reduce the amount of transparent ZEC is hardware wallet support for shielded ZEC, so zodlers get their ZEC, even if transparent from an exchange, and it gets shielded into their hardware wallets.
1 Like
The only way to truly increase the shielded pool is to add hardware wallet support. Until then, it’s not going to happen in the numbers that people at the ECC/ZFND/otherwise would like.
5 Likes
Add hardware wallet support is not something that anyone in the Zcash ecosystem can affect to reality. But what Zcash ecosystem can affect is to deprecate the transparent pool which would instantly drive another 12 million ZEC into the modern shielded pool.
From a pragmatists view, we should be asking what can we do and what is not under our control
Of course they can.
Deprecation of T-Addresses will not happen within the next 10 years (even if that – or if Zcash is even still around TBH).
1 Like
Let me know if I’m wrong, there are no hardware wallets owned by any of the entities that receive the block rewards, nor are there any hardware wallets owned by any of the teams-organizations with ZCG grants approved for hardware wallets?
Assuming I understand the answers to the above, that is why I suggest that nobody in the ecosystem can affect the desired outcome. (We can persuade people who can affect the outcome, this is different because they are outside of the ecosystem. Building products that can support or not support shielded zcash at their discretion. Think about how we saw the Zcash-Thorchain integration work halted at the Thorchain team’s discretion)
Ledger apps can be sideloaded on the Nano S and S+. It is not for everyone but then you are not relying on any external organization.
1 Like