That part wouldn’t be difficult on the technical level actually. You can simply forbid transfers to t-addresses. I suspect the biggest hurdle is performance based.
I agree technically it would be an easy code change but it would crush the network with everyone forced to move funds to private addresses at once.
Not to mention the impact on exchanges where trading could grind to a halt, it could go very badly very fast if not done right.
Yes, totally agreed. In suspect getting the proof format finalised ( do you know if there are any plans to improve upon sapling transactions? ) will desirable. There is no point in doing this if you will want to change it again down the line.
For a similar situation have a look at Monero and plaintext account numbers (yes, someone had that bright idea). They are still trying to convince exchanges to update their code, and it has been a year now.
If this is the case, wouldn’t it make sense to do it sooner rather than later… while the network is “young” and users are less?
Zcash’s value proposition is nice for sure, but the day when every transaction is shielded by default won’t come soon
I can’t understand why there are no web/light wallets that support z- address (and maybe there aren’t exchange that send to z- address). In this way even start to think to transition to “shielded addresses only” is impossible.
Because if you want truly private transactions you need software where the phones OS, cell service providers, and backend servers can’t spy on the users actions. It’s much harder problem than any other lite client has ever done.
Good news is it’s getting closer to reality: https://z.cash/blog/the-zcash-reference-wallet-is-here/
- It would break many services like wallets, hardware wallets and exchanges. Right now the percentage of shielded transactions is low because users need a full node to use them and the majority of the transaction volume happens on exchanges.
- UX (ie no full node / ease of use) should be job one to drive private address adoption. Light wallets are key here. Next will be convincing/helping major services/wallets to use z-addresses.
- No multisig support so far. KZen is working on something but it requires implementation based on the specific requirements.
- Users should request adoption from their favorite services.
Sorry, but I don’t get it: why would it break other services?
API commands are slightly different. Glue applications that use them are usually written by junior programmers, so they break if you look at them the wrong way.
There were two main technical blockers:
- support for shielded coinbase outputs is proposed for NU3;
- shielded threshold multisig does not require a consensus change, and is planned to be implemented within the NU3 timescale.
In addition, we need to iron some kinks out of the support for shielded addresses on mobile and hardware wallets, and provide support for major exchanges to enable shielded withdrawals. My impression is that the main obstacles to the latter are technical; there are also regulatory issues but they are resolvable.
In an optimistic scenario, all of this would be in place by NU3. I still suspect that NU4 is too early for a consensus change to limit use of transparent addresses. I think that’s more likely to be proposed for NU5 (scheduled for October 2021). Note that this is my speculation and does not represent any kind of commitment.
Our plans for scaling research are only at an early stage, but are likely to involve creating a new test network that will be its own blockchain. IMHO it’s likely that network will be shielded-only – not only because that’s desirable from a privacy point of view, but because Bitcoin script is just too hard to verify in a zk-SNARK circuit.
To clarify, this would be a test network, so like the existing testnet, it would have no relation to the ZEC token. One possible way of proceeding from there would be to launch a separate mainnet which would represent the same token as ZEC, with a snapshot of the note commitment tree from the original network, and optionally some way to transfer transparent funds. zcashd and pzec (the Foundation’s implementation derived from Parity-Bitcoin code) could be programmed to switch from one network to the other automatically at a given block height, or connect to both during a transition period.
Thanks @daira for responding to this thread. I bet community is excited to hear about scaling efforts currently being pursued by the team.
Launching it as separate test and real shielded-only blockchain and token perfectly makes sense for everyone. My suggestion (when that happens) would be to re-use zcash name (like bitcoin cash) and also call it friendly-fork? (one of its kind new blockchain fork). Zcash Bonsai would be ideal (github issue) but it’s not catchy. Other ideas for names include: Zcash Compact, Zcash Mini, Zcash Next (I like this as this is ambiguous to support newer tech), Zcash Sub etc.,
Zcash Next could be litecoin of Zcash. Eventually, Zcash can and will adopt tech present in Zcash Next.
I like Bonsai! It would just be a testnet, though, based on what Daira wrote above.
Thanks for your explanation! I’ll read it more detailed
To clarify, there are no plans for a new (non-test) economic token at the moment. It’s more likely that when we are ready, we’d work out a way to continue the existing token with new technology.
I think ECC needs to clarify publicly (ideally through a blog post) about this:
In the hypothetical future, what’s going to happen when new blockchain with scalability is launched, will it be called Zcash? will there be two tokens? (most likely). will there be new dev fund on the new blockchain?
Why would we need to clarify anything? It’s a research proposal. And it’s already clear: if we use a new block chain, it will because that’s a neat technical hack to avoid certain compatibility problems. There is no proposal for a new token (except for a non-economic test token).
Thanks Daira. I only said that to avoid FUD.