# Leap frogging zaddr **URL:** \ **Category:** General\ **Created:** [May 20, 2020, 6:25am UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550 "2020-05-20T06:25:14Z")\ **Posts on this page:** 20\ **Page:** 11
**Author:** ![dontbeevil](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@dontbeevil](https://forum.zcashcommunity.com/u/dontbeevil)\ **Post date:** [December 20, 2020, 1:09am UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/204 "2020-12-20T01:09:23Z")
Could we ask community via poll iff they are willing to support t-address deprecation once technical hurdles & exchange support is addressed? ---
**Author:** ![dontbeevil](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@dontbeevil](https://forum.zcashcommunity.com/u/dontbeevil)\ **Post date:** [December 20, 2020, 3:23am UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/205 "2020-12-20T03:23:36Z")
> ---
**Author:** ![Autotunafish](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/autotunafish/32/7827_2.png) [@Autotunafish](https://forum.zcashcommunity.com/u/Autotunafish)\ **Post date:** [December 20, 2020, 3:53am UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/206 "2020-12-20T03:53:29Z")
@dontbeevil watch this one, its relevant here and much more recent than that post [Zero Knowledge Privacy in Regulated Financial Transactions (Part 1) - YouTube](https://youtu.be/E5NkQr_2rJ0) ---
**Author:** ![anon16456014](https://avatars.discourse-cdn.com/v4/letter/a/f0a364/32.png) [@anon16456014](https://forum.zcashcommunity.com/u/anon16456014)\ **Post date:** [December 20, 2020, 10:19am UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/207 "2020-12-20T10:19:20Z")
I don’t buy the argument that transparent addresses have any usecase within the Zcash network. The only thing they do is hurt all our users’ privacy. If someone wants to use transparent addresses, there are many chains that do it much better than Zcash. If someone has a specific rare usecase that requires fully transparent addresses, they can opt to use another chain, and that’s fine. Zcash is all about protecting users’ privacy, and the longer it takes to get rid of them, the more we are knowingly hurting our users’ privacy. ---
**Author:** ![anon16456014](https://avatars.discourse-cdn.com/v4/letter/a/f0a364/32.png) [@anon16456014](https://forum.zcashcommunity.com/u/anon16456014)\ **Post date:** [December 20, 2020, 10:37am UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/208 "2020-12-20T10:37:13Z")
And don’t get me wrong. I’m not saying that we are ready to abandon transparent address today but we are definitely in a position to do it in a year, if we put our focus on it. There are missing pieces like shielded support for hardware wallets, shielded multisig and a few others, but it’s possible to have all those (and many others) in the next 6 months, if we actually focus in doing that. ---
**Author:** ![bolbo](https://avatars.discourse-cdn.com/v4/letter/b/f07891/32.png) [@bolbo](https://forum.zcashcommunity.com/u/bolbo)\ **Post date:** [December 20, 2020, 2:19pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/209 "2020-12-20T14:19:54Z")
> [@anon16456014](#): > > we are definitely in a position to do it in a year, if we put our focus on it. I disagree. It is more important for us to get rid of Sprout first before talking about transparent address. We _can_ make it harder to use t-addr but it would make a very bad UX for the majority of users. > [@anon16456014](#): > > support for hardware wallets, shielded multisig Also, do you really think that both of these will be solved within a year? From my understanding, removing Sprout will actually make development easier compared to removing t-addr. Depecrating Sprout is more important at the moment. ---
**Author:** ![Shawn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shawn/32/187_2.png) [@Shawn](https://forum.zcashcommunity.com/u/Shawn)\ **Post date:** [December 20, 2020, 2:38pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/210 "2020-12-20T14:38:42Z")
> [@dontbeevil](#): > > Could we ask community via poll iff they are willing to support t-address deprecation We can do a poll, but I think everyone already knows the answer that will come out of such a poll: T-addresses need to be depreciated. However, the main disagreement I have seen is regarding timing: most arguments so far fall into two camps: 1. We need to depreciate T-addresses **now** , to heck with the tradeoffs. 2. We need to depreciate T-addresses ASAP, when X and X and X for Z-addresses is available. It seems to me that the most productive way to move forward is to have a hard look at _precisely_ what changes/sacrifices we want/need to make to get there. But to prove my point, here is a quick poll: > ---
**Author:** ![nathan-at-least](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/nathan-at-least/32/8_2.png) [@nathan-at-least](https://forum.zcashcommunity.com/u/nathan-at-least)\ **Post date:** [December 20, 2020, 2:53pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/211 "2020-12-20T14:53:31Z")
> [@dontbeevil](#): > > So sunset of t-addr can happen when top 10 real volume exchanges support z-addr (one of the hypothetical rules under which it will be deprecated). This seems like one prudent requirement, but I also don’t consider that sufficient. I personally would like to see extremely robust criteria along these lines: “In _every_ key sector enough leading products/services _already_ support shielded such that X% of users in that sector are covered. Key sectors should include at least well regulated exchanges, in as many jurisdictions as possible, wallets (mobile, fullnode, hardware), custodians, apps (ex: Zbay), and vendors/services/products (ex: vpns, shwag stores, …).” That would ensure that regulatory support is already well sorted, for example. We might imagine a dial we can turn between conservative and aggressive retirement of t-addrs. If we set X% to say 95% that would be extremely conservative. If we set it to 5% that’s extremely aggressive. The risk of being too aggressive is a potential loss of support, like @mason describes, which can have a pile-on effect (more exchange delistings → fewer projects deciding to continue zcash support & harder to find ZEC → demand curve drops → repeat). OTOH, “just the right amount” of aggressive might spur upgrades. This seems like it would only work when there’s already substantial adoption momentum for ZEC and services/vendors have FOMO and don’t want to drop support. Just to repeat my thinking that leads me to use the term “leap frogging”, it goes like this: let’s aim to achieve the above criteria for X% = 95% _no matter when/how/what the plan for retiring T-Addrs is_. In other words, let’s hit X% = 95% because exchanges, regulators, wallet vendors, and users _want/need_ to use shielded and it’s easy, convenient, and safe to use rather than because a protocol change forces them to. Yes, maybe a protocol change can nudge some folks in a good direction, but at the end of the day Zcash is only successful when it provides valuable features that users need and want. ---
**Author:** ![Anton1](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Anton1](https://forum.zcashcommunity.com/u/Anton1)\ **Post date:** [December 20, 2020, 3:30pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/212 "2020-12-20T15:30:26Z")
Develop a direction with z translations and when they become really better at everything, T will go away by itself and you don’t need to try to find meaning where there is none, you don’t want to use T addresses, but for the dominance of z even further than before zcash at all used in real life every day. The fact that now there is a choice is 100% justified ---
**Author:** ![fireice\_uk](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/fireice_uk/32/16429_2.png) [@fireice\_uk](https://forum.zcashcommunity.com/u/fireice_uk)\ **Post date:** [December 20, 2020, 3:35pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/213 "2020-12-20T15:35:33Z")
I had an idea in the back of my head that would solve it. Instead of hard-depreciating t-addr, how about limiting the block size for t-transactions? This will create a fee market and z-addr adoption pressure. ---
**Author:** ![tromp](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/tromp/32/522_2.png) [@tromp](https://forum.zcashcommunity.com/u/tromp)\ **Post date:** [December 20, 2020, 4:27pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/214 "2020-12-20T16:27:57Z")
I think the simplest and least disruptive way to encourage more use of z-addresses is to introduce a linearly climbing (over time) fee rate for relay of transactions involving t-addresses, that will end in a few years in a significant amount, like 5 milli-ZEC. People who insist on using t-addresses will still be able to use them, but at a non-trivial expense, which will drive most people to migrate. ---
**Author:** ![Anton1](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Anton1](https://forum.zcashcommunity.com/u/Anton1)\ **Post date:** [December 20, 2020, 4:45pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/215 "2020-12-20T16:45:00Z")
All games with commissions can induce people to micronize not to z addresses but to other projects, who is sure that users will stay no matter what? There is no need to invent anything new, everything is invented for us, a person is looking for comfort, where it will be better there. Despite the best technical base, and all the advantages that are presented in the zcash project, it is less popular than others, and if you still deal with the complications of use, then the last several tens of thousands will simply stop using it. You need to search for how to attract more users while maintaining the existing ones and not think which is better and which is worse, let users decide what to use. ---
**Author:** ![dontbeevil](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@dontbeevil](https://forum.zcashcommunity.com/u/dontbeevil)\ **Post date:** [December 20, 2020, 6:19pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/216 "2020-12-20T18:19:19Z")
> [@nathan-at-least](#): > > let’s hit X% = 95% That’s … too high. It would take a decade or more, effectively making deprecation impossible. Question is how do we get to 95% or that X%? I know ECC/ZF worked with Gemini. Is ECC & ZF going to work towards that X%? ---
**Author:** ![dontbeevil](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@dontbeevil](https://forum.zcashcommunity.com/u/dontbeevil)\ **Post date:** [December 20, 2020, 6:21pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/217 "2020-12-20T18:21:40Z")
> [@bolbo](#): > > It is more important for us to get rid of Sprout first before talking about transparent address There is a difference. In one, funds are destroyed. In other, funds can move. ---
**Author:** ![dontbeevil](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@dontbeevil](https://forum.zcashcommunity.com/u/dontbeevil)\ **Post date:** [December 20, 2020, 6:25pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/218 "2020-12-20T18:25:56Z")
> [@nathan-at-least](#): > > That would ensure that regulatory support is already well sorted, for example. This seems to be the biggest issue. Can ECC/ZF reach out to exchanges they are connected with this question: Zcash community is interested in avoiding t-address in X time. Would you add support for z-address? If no, why? ---
**Author:** ![dontbeevil](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@dontbeevil](https://forum.zcashcommunity.com/u/dontbeevil)\ **Post date:** [December 20, 2020, 6:33pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/219 "2020-12-20T18:33:00Z")
At a minimum, we can start with t2t as part of deprecation strategy if some preconditions are met. Then go further @secparam > ---
**Author:** ![garethtdavies](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/garethtdavies/32/210_2.png) [@garethtdavies](https://forum.zcashcommunity.com/u/garethtdavies)\ **Post date:** [December 20, 2020, 7:55pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/220 "2020-12-20T19:55:52Z")
These are Sprout payment disclosures. As noted [here](https://forum.zcashcommunity.com/t/implementing-z-addr-in-bisq-dex-zcash-future-plans/37943/4) there isn’t a ZIP for Sapling payment disclosures yet. None of the block explorers support view keys do they? ---
**Author:** ![anon16456014](https://avatars.discourse-cdn.com/v4/letter/a/f0a364/32.png) [@anon16456014](https://forum.zcashcommunity.com/u/anon16456014)\ **Post date:** [December 20, 2020, 8:10pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/221 "2020-12-20T20:10:24Z")
> > > Closes #387. > > Draft progress: > \- \[x\] Payment disclosure structure > \- \[\] Payme…nt disclosure encoding / versioning > \- \[\] Creation: > - \[x\] Sapling outputs > - \[x\] Sapling inputs > - \[\] BIP 322 inputs > \- \[\] Verification > - \[x\] Sapling outputs > - \[x\] Sapling inputs > - \[\] BIP 322 inputs > \- \[\] UI / UX handling ---
**Author:** ![Shawn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shawn/32/187_2.png) [@Shawn](https://forum.zcashcommunity.com/u/Shawn)\ **Post date:** [December 20, 2020, 8:36pm UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/222 "2020-12-20T20:36:01Z")
> [@garethtdavies](#): > > These are Sprout payment disclosures. Hm, good point! ---
**Author:** ![zooko](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zooko/32/32232_2.png) [@zooko](https://forum.zcashcommunity.com/u/zooko)\ **Post date:** [December 21, 2020, 1:53am UTC](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550/223 "2020-12-21T01:53:58Z")
> [@tromp](#): > > I think the simplest and least disruptive way to encourage more use of z-addresses is to introduce a linearly climbing (over time) fee rate for relay of transactions involving t-addresses, that will end in a few years in a significant amount, like 5 milli-ZEC. People who insist on using t-addresses will still be able to use them, but at a non-trivial expense, which will drive most people to migrate. I like this kind of idea. I think this sort of proposal could get sufficiently wide support that it could activate on Zcash mainnet without the chain forking into two chains due to some people refusing to run it. I do not think that “turn off taddresses entirely” could, at least not within the next few years. Beyond a few years my crystal ball gets hazy. For a fleshed-out version of this sort of proposal, see PRINCE — “PRivacy INCEntives for ZEC” — which has some neat ideas in which people who shield their ZEC get a bonus: [https://www.reddit.com/r/zec/comments/c70fzz/privacy\_proposal\_for\_zec\_incentives/](https://www.reddit.com/r/zec/comments/c70fzz/privacy_proposal_for_zec_incentives/) And relatedly, here is my proposal that the Zcash network charge a fee to maintain old utxos and old notes: > > > Currently there is a fee for sending a transaction, but after that all full node…s are required to store your transaction outputs forever at no further cost to you. > > Utxos and shielded pools impose several kinds of negative externalities on all users of the network: > > 1. They increase storage costs that all full-nodes and miners must pay. This is clear if you think like an attacker and use it as a DoS vector: at low cost to you, you can impose a permanent increase in resource requirements on your targets (full-nodes and miners). Another way to look at this is that we need a kind of garbage collection (of obsolete read-only shielded pools and unloved utxos) in order to allow better scaling. > 2. Keeping old utxos and old shielded pools around requires maintaining — live in the current product — the protocols and source code to accept them. This increases complexity of the protocols and code, which imposes an increased risk of catastrophic security failure, which risk is borne by all users. > 3. The effort to maintain the protocols and code to handle old utxos and old notes use up development resources, thus slowing down development of new improvements and increasing the risk of security failure (additionally to the above-mentioned risk in 2). > 4. Old utxos and old shielded pools add uncertainty about the true size of the monetary base, which prevents using Zcash as a unit of account and adds uncertainty to investment decisions. Again, this cost is borne by all users. > 5. Old shielded pools induce uncertainty about whether counterfeiting occurred in the past. Counterfeiting doesn't represent an economic cost to all other users (since we have a \[policy\](https://z.cash/blog/defense-against-counterfeiting-in-shielded-pools/) against it being allowed to expand the size of the monetary base), but \_uncertainty\_ about whether an old shielded pool will turn out to have been counterfeited still imposes a substantial cost on all users by increasing FUD about Zcash's security. As the amount of ZEC in an old shielded pool goes down, the degree of FUD about it also goes down, and when the old shielded pool is completely empty then we know no counterfeiting occurred. > > I propose a minimal initial step which, while it won't solve all of these problems, gets us closer to solving them in future network upgrades. It is to institute a fee for maintenance of utxos and notes. > > The mechanism would simply be that the consensus rules require an additional amount of txfee, determined by the age of the state that is needed. > > The fee policy in Blossom would be extremely simple. The goals for Blossom are just to implement the mechanism, establish the social norms, and see how much a minimal fee motivates people to act. I propose: if the utxo or shielded pool you are spending from is less than a year old, then no additional storage fee. If it is more than a year old, then the additional storage fee is 1 zatoshi per block that the utxo or shielded pool has existed. > > In addition to the general policy that storage is free for the first year, we should grandfather-in the current shielded pool so that people have twelve months to move their notes from the current shielded pool (which is the second shielded pool — the one created by the activation of Sapling) to the \[third shielded pool\](https://github.com/zcash/zcash/issues/3667) at no charge. > > (This really underscores why I'm eager to get this change into Blossom — it is going to take years to have its effects.) > > The additional storage fee just goes to the same place that the txn fee goes (to the miner). > > Here's a related paper: > http://fc18.ifca.ai/bitcoin/papers/bitcoin18-final18.pdf > > In parallel with this ticket (implementating the mechanism and instituting the simple policy outlined here), we should ask researchers in computer security, economics, etc to analyze this system and propose a method of pricing this. But we should absolutely \*not\* delay adopting the simple first version while that research is in progress, as it is likely to take years. [Previous page](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550.md?page=10) [Next page](https://forum.zcashcommunity.com/t/leap-frogging-zaddr/36550.md?page=12)