To be clear, shielded multisignature operations are not strictly dependent on any particular FROST-specific constructions, correct? (And yes, I understand the desire to optimize communication rounds…)
1 Like
Yes that’s correct based on my understanding @sarang; FROST is a particularly optimized scheme but other approaches could work.
Right. I want to be sure that there isn’t a “we’re waiting on FROST to be able to do multisig” perception. If all you need is threshold Schnorr, that exists.
EDIT: trivial typo
It does “exist.” There are papers, blog posts etc. But are there good libraries you could use today or protocols one could sanely implement ?
1 Like
Not that I know of (which should not be taken as evidence of absence). But I’ve talked to other folks who seemed to be of the opinion that there was some Big Math Problem still unsolved in order to suddenly power shielded multisig operations.
Re-read Engineering Roadmap 2020 - zcash foundation
IIUC, Zfnd is now doing shielded multisig work in-house now? (kZen team is no longer working on this??)
1 Like
This is correct.
This sounds like outdated info. In zcashd there’s getmigrationstatus and setmigration <on/off> calls.
When Sapling activated this feature wasn’t yet shipped, and ECC decided keeping network upgrades on schedule is of paramount importance. This was somewhat unfortunate. So the idea that the tool isn’t available is probably outdated info from that era.
We shipped the migration tool as quickly as possible. We also worked with Zecwallet to ensure both implementations followed the same standard to protect privacy across implementations as best as possible.
1 Like
Are you referring to software support for making migration-type transactions using transparent addresses? I was referring to support for making such transactions without the use of transparent addresses.
(@nathan-at-least… not sure if this comment was properly marked as a reply)
1 Like
This is excellent work!
2 Likes
Hi folks, I just saw this thread. I love seeing roadmap / vision discussions like this in the community!
Here’s my attempt to summarize my current position:
In order for shielded Zcash usage to grow, shielded Zcash technology needs to be well deployed, and then users have to use it. So for me, this should be our #1 top priority without a doubt in terms of improving privacy.
I definitely want to see t-addrs retired, and privacy to be default & mandatory, so long as any user can choose on their own which information to disclose about their own behavior. But, in my way of thinking, this is totally secondary to shielded privacy deployment and adoption. So:
- If shielded tech is widely deployed and adoption rates are large, then it’s probably a great time to retire t-addrs.
- If shielded tech is widely deployed and adoption rates are large, it’s not as bad if t-addrs persist. It is still bad, but if fewer users run across it, it has less of a bad impact. By analogy, it’s still possible to run an
httpwebsite without TLShttps, but browsers warn you and it’s really really easy to runhttpsso they are pretty rare but sometimes useful. So concretely, if <5% of transactions or <1% of users were using t-addrs, I wouldn’t worry too much about their existence. - If shielded tech is not widely deployed, then retiring t-addrs is a complete red-herring, because there’s no usable alternative and retiring t-addrs would very likely decimate Zcash adoption. (We’re already close to overcoming this hump with work on mobile, hardware, and multisig.)
- If shielded tech is deployed but doesn’t have significant adoption, then the situation is more tricky because retiring t-addrs might spur existing users to switch to shielded and it might attract new users (which is great!) OR it might prompt users to turn off Zcash support because it’s too much hassle (which is bad!). It’s difficult to know if we haven’t already seen sufficient adoption.
Some people might want t-addrs. That’s a different discussion, IMO, but there is a nuance here for me: in the short term, because t-addrs are so much easier to integrate, they are very valuable for Zcash network effect as a whole (while still being bad for privacy).
So I think two likely areas for disagreement for all of us who want to retire t-addrs is:
- What is sufficient adoption for case 4?
- For case 4, will retiring t-addrs spur shielded adoption or degrade overall Zcash adoption?
But I think none of us who want to retire t-addrs would disagree with case 1. So in my book, we should all rally around deployment and adoption of shielded tech, because it’s a common goal for everyone even if they disagree about when/how to retire t-addrs.
I think we’re already pretty much doing that at Zfnd and ECC and across the community with projects like ZecWallet.
1 Like
t-addresses should die ASAP and there’s no better time to trigger the kill switch.
We now have mobile support, Ledger support (to be announced next week probably?) and the basic tooling for everyone to adopt them.
We are all aware that keeping t-addresses because of lazy exchanges is at the detriment of our own users’ privacy. Exchanges will not switch to z-addresses unless they are forced to do it. They don’t have any financial incentive to do it otherwise and they will not do it. Having a couple of exchanges actively working on it is not solving the problem either. We need all exchanges to support z-addresses.
My realistic scenario would be to add consensus rules for t-address removal right now and with a hard activation 1 year from now. This is plenty of time even for the least able dev team to switch over. The hard activation would disable sending to t-addresses altogether and only allow sending from t-addresses. In the meantime, and this would be optional, we could activate a soft punishment rule so that using t-addresses would be more expensive, thus incentivise to reduce their usage. I’m not strong on this punishment solution but it’s an option the community could discuss.
As a privacy advocate (and not a speculator), I wouldn’t care less about potential loss of network effect. I care about the privacy of all our users and this is my driving force. In keeping t-addresses alive, we are knowingly hurting our users’ privacy and this is something that opposes this community’s moral standards and mission.
9 Likes
I completely echo this!!
@nathan-at-least Most probable scenario that I see for Zcash: shielded tech deployment in production (software, tools, support, funding & resources available) in 6-12 months. But exchanges & users won’t adopt unless it is forced. We can do community voting at that point to retire t-addr.
We need to define what “adoption” means for Zcash:
- Is it total # of addresses?
- Is it total # of z-addr?
- % of z-addr
- Is it transactions/day?
- Is it z2z growth?
- Growth of % of z2z transactions/ all transactions
- Total # of users purchasing ZEC (don’t think this should be taken seriously)
etc
2 Likes
Exchange adoption of z-addr is two parts:
- Accepting deposits to exchange’s z-addr (value for exchange)
- Letting users withdraw directly to z-addr (no added value for exchange)
Reason why 1st part is useful for exchange: Why would they want world to know how much money is flowing into their exchange.
A small survey to top exchanges will help us understand this better.
- Would you start using z-addr instead t-addr?
- If not, why? (reason: dev cost, expertise, revenue concerns etc)
- If yes, how long would it take for you ?
(We can mention that this answer will be considered while deciding when t-addr is deprecated)
etc
1 Like
I think that privacy advocates should care about Zcash network effects and be hoping for the price of Zcash to increase, because there is a positive feedback loop between usage and speculation/price.
5 Likes
How much do exchanges depend on ECC help/support for their operations? I’m guessing lots…?
How about exchanges that offer (or commit to offering) zaddr services get better access, maybe a sweeter deal, taddr exchanges still get helped but at a lower priority.
I’m trying to be, unsuccessfully, on vacation today for some family time. I will come back to this next week and, if I forget, remind me. I can provide you insight into the work that happens and is happening with exchanges. If Zcash were the only asset they cared about, things would move faster. But it’s not. There are variables at play that include time, user demand, engineering (HSMs, shielded multisig, payment disclosures, etc.), banking relationships, exchange philosophy, existing engineering roadmaps, opportunity cost, etc.
5 Likes
I believe that working in a transparent and secure network is an advantage and not a disadvantage, what is the point of transferring everything to a secure network, I don’t understand, yes, I need to develop secure translations but through their convenience and general advantage, because people don’t use them for a reason, but because it’s not necessary. Networks need development, through infrastructure and unique products that work only with ZCASH, and these products take advantage of secure transfers and you’re done. Now they are simply shouting from all sides that privacy and the like, but why use zcash to achieve this if you can just not use it and nothing will change. A fully speculative asset.
I am sure that exchanges think that way. Why problems where they do not exist. There will be development and then there will be recognition and use, and while the wallets are not even ready, then there will be wallets, but why buy and store zec if it does not work, then you can pass it on without publicity, but why if there are problems again, you can take any cryptocurrency and transfer it wallet file, all secure transaction is ready, no problem. There will be cards, there will be storage facilities and a steady rate, then ATMs for easy work with cards, etc.
I love the spirit of this post.
But let me ask: are you an owner or advocate for the many fully shielded Zcash clones? Why or why not?
Are those fully shielded Zcash clones bringing privacy to more people or is Zcash or some other system?
I believe the answer is that Zcash is a leading contender for bringing privacy to the most people because we’ve been very pragmatic about network effect.
1 year might be enough time and enough of a forcing function to spur upgrades. That would be ideal. OTOH, it carries these risks:
- we might lose product/service support that lose existing users.
- we might lost future product/service support because the barrier to adoption becomes greater.
Degrading network effect means less privacy for fewer people, as @aristarchus also points out. I believe Zcash has more users than fully private Zcash clones partially because of t-addrs (but also because of many other important factors).
For me, adoption is crucial, not just the mere existence of tech, but proof that it works in the market place.
Let’s think about the complexity across the ecosystem to upgrade to shielded:
- exchanges to implement shielded support, even though they often have custom in-house tech for hot wallet, cold storage, and custodian management. Often these involve various Hardware Security Modules (HSMs), which are difficult for ECC or Zfnd engineers to develop for due to proprietary nature. Furthermore exchanges and custodians are quite unlikely to freely collaborate on their core hot wallet code’s HSM integrations without heavy NDAs and stuff. So that means it’s either them doing it on their own, or someone like ECC or Zfnd taking on a legal liability and oversite to help out.
- exchanges to pass those implementations through their legal compliance review cycles. Changes to exchange or custodian architecture (such as might be required by Zcash shielded due to differences in transparent UTXO indexing versus Viewing Key support) are much more difficult to get through this process compared to deploying similar architectures for different coins.
- enough of the 12 wallets listed under transparent only address support need to upgrade. They use different platforms and underlying tech. I’m not sure how many Zcash users each supports. Upgrading isn’t just a matter of replacing a transaction library under the hood (which is already fairly involved) but it also requires modifications to UX. For multi-currency wallets, this means special case UX for Zcash whereas t-addr support can crib from Bitcoin. So it’s not merely a matter of replacing a transaction library, but a full-fledged product modification. (Again, I’m not saying t-addr support and UX is not a hazard, but it is a much lower cost way to integrate Zcash.)
- what about services that let you spend Zcash at retail like Flexa’s SPEDN wallet? Not only do they need “standard” send/receive/balance functionality, but they’ll very likely need new UX flow, for example support for Payment Disclosure flow in the user-facing interface that works for both spender and merchant. The same goes for “Crypto ATM” products like Lamassu, or point-of-sale products. (Tangent: I saw an Anypay video that demos shielded Point-of-Sale support already! If that truly works, that’s excellent progress.)
- Existing multisig users, such as custodians or API services like Bitgo would need to either deploy a new service that doesn’t use multisig (a core feature of Bitgo) or they need to upgrade to a new cryptographic threshold scheme Zfnd engineers and other cryptographic researchers have developed. The new protocol is a great improvement, but it’s unique and different from what Bitgo currently does, so they’ll need to add more special case code, infrastructure, and UX components for their product.
- If we have Ledger support, but not Trezor or other hardware wallets, how many users are supported versus left in the cold? What if a Trezor user stores other cryptocurrencies on their Trezor that aren’t yet supported by Ledger? Is it worth it for them to migrate and manage two hardware wallets, or will they just deposit their cold storage onto an exchange to avoid the headache? In this example, even though “apparent on-chain privacy” has increased, actual privacy decreases because more exchanges control more ZEC.
- Block explorers probably will need UX upgrades. For example, Blockchair.com already implemented a Payment Disclosure UX for Zcash Sprout. This is the only end-user payment disclosure feature I’m aware of.
- We need to be careful of degrading or losing mining support. We want to make sure pool operators are able to do mine-to-shielded and shielded payouts on time, otherwise we risk decimating the hashrate.
- Existing cross-chain protocols which we may not be aware of might have to upgrade and doing so may be very difficult. For example, I just learned of Ren Project’s mainnet which supports a ZEC <-> ETH bridge. I know very little about it, but I am willing to bet 1 ZEC that it relies on t-addrs, and another 1 ZEC that altering their decentralized protocol to support shielded might be a very difficult cryptographic protocol research project.
- Plus, there’s the likelihood of dozens of applications, protocols, and services none of us are aware of with some numbers of users.
Finally, that’s all only about the complexity of deploying the upgrades. What about the incentive? If an exchange can do 5 engineer days of work to integrate Zcash t-addr and then one week of legal compliance work, they’ll do that so long as expected revenue from ZEC trading is high enough. But now, if they are forced to do a lot of heavy lifting in a one year timeframe, if I were them I would look very closely at that substantial cost stacked against ZEC trading revenue. Other factors like strategic factors probably matter, but the bottom line calculation is very important.
I also think people are getting too focused on exchanges compared to all of these other cases I described. The same calculation is true of any multi-currency wallet. How much is Zcash support worth to them versus the effort. If it’s easy to deploy t-addrs because it’s mostly cut’n’paste from Bitcoin, the low cost can be worth the effort even without a large revenue/adoption/traction increase. But now, if they are forced to do a significant amount of work, they will again need to balance their bottom line vs strategic priorities.
Finally, losing network effect doesn’t just mean losing users, and probably a declining price (which slows on-chain development funding), but it can also mean wittling down alternatives and thus centralizing control over parts of the Zcash ecosystem. For example, if only one hardware wallet makes the upgrade on time, users options are reduced, and there’s less competition to improve user options. (Hopefully because Zcash is open and permissionless, the competition can grow back.)
And finally: all of the concerns I lay out in this post are just the downside risk of the equation. As I said, it may be that a forcing function spurs adoption. Maybe if we lost a third of the services or products in each category, but all of the “core categories” retain enough traction, then the benefits of fully shielded will lead to better growth longer term.
One way to think of it: if Zcash commits to going fully shielded in 12 months, how long will it take the growth rate to surpass the existing trajectory? If it takes 6 months, 12 months, or 48 months, does that change our thinking about when/how to go fully shielded? For me personally if I’m fairly confident it’s ≤ 6 months, I’d be totally for it. I’m not confident in that yet.
What would give me confidence is seeing users adopt shielded products and services. For me “Ledger support” isn’t nearly as important as “the number of Ledger users using shielded Zcash is growing by 5% per month for the past three months”. Shielded mobile “support” isn’t nearly as important as “the number of shielded mobile users and/or txns is growing by 5% per month”.
BTW- I’m starting to hear some really promising adoption rate numbers through the grapevine for shielded services. So if we keep the momentum going, with any luck in 3-12 months this thread will be moot because the downside risks I mention here will be fairly obviously mitigated already before needing to apply a forcing function.
8 Likes
For t-addr support they depend on us very little! Because they already know Bitcoin and it’s almost a cut’n’paste job in both engineering, UX, and product.
For z-addr support a lot because currently the main libraries for shielded transaction creation/signing/detection I’m aware of are developed by ECC + Zfnd engineers. Plus, a viewing key vs UTXO-indexing architecture change is another technical hurdle.
4 Likes
Let me ask this, are we currently seeing growth in taddr & transparent transactions?
Can you expand more? Due to all the constraints & complexity involved: z-addr adoption from these players may not happen.
2 Likes