ECC update for March 1, Roadmap Edition

Zashi (and ECC’s mobile SDKs) does not support sending transparent ZEC directly to other addresses. To send funds to a transparent address the flow is always shielded to transparent.

If you receive transparent funds, Zashi will prompt you to shield those funds before they are considered spendable.

note: I read that text quickly and (mis)understood the same as you did and I actually knew what Zashi can or can’t do in terms of spending. Don’t feel bad about it.

3 Likes

thank you for the info.

it means that transactions from
-U 2 U will always be shielded ? like a z address?

  • U 2 T will work
    -U 2 Z will they still work?
    T 2 T from zashi will not work

and also Z to T should work but what about Z 2 U?

1 Like

A unified address can contain multiple different kinds of addresses. For example, a u-addr could contain a transparent address, sapling address, and orchard address, so “U 2 X” isn’t a well-defined concept, there’s no longer a 1:1 mapping between addresses and pools.

A wallet will have a separate balance in each of the transparent, sapling, and orchard pools. Zashi can spend balance in the sapling or orchard pools to any kind of address. But any balance in the transparent pool will need to be shielded (moved to sapling or orchard) before it can be sent anywhere.

So the user experience is that you can always spend to any kind of address, unless to do so you’d need to use some of your transparent balance. In that case, you have to shield your transparent funds first, which means you just have to click the “shield funds” button and wait for that transaction to be mined. Then you can send those funds wherever you want.

When you give someone your unified address, it will contain your orchard address, sapling address, and transparent address, and when they send you funds it will send them to orchard if it can, or to sapling if it can, or if it can’t send to sapling or orchard, then to the embedded transparent address. (Basically, whatever the latest pool is that the sender’s wallet supports, falling back to transparent only if the sender’s wallet doesn’t support sending to any kind of shielded address.)

6 Likes

Thank you for explaining.
Basically transactions from U2U means it falls under the shielded protocol by default (because the 2 peers support shielded addresses)
This means that the U2U is shielded by default and T addresses are not used in the transfer.
Otherwise ZCASH will loose its anonymous functions. You can’t send anonymous transactions with ZCASH otherwise.
I guess in case of U2U type transfer the addresses are not going to split the amount in T + Z address when transfering and recombine them to receiver single U address as 1 transactions.
This means that the transaction will not be anonymous and will be traceable by the T address involved in the transaction.
Is there a way in blockchain explorer of zcash to verify what transactions on U addresses contain?

I’m only asking because I just have a strange feeling that using the new U type addresses you will not get anonymity because you can’t choose to send it with or without anonymity. It sends a transaction using a T or Z or a mix of those and the transaction will not be anonymous. You can’t specifically say…send it shielded (anonymous) with U addresses.

2 Likes

This depends on the wallet you use. Zashi blocks any t2x transaction and given a u-addr will always use the shielded receiver.

YWallet gives you the option to choose the source and destination pools, and then will make the most shielded transaction possible given these constraints.

No shielded wallet will do a t2t transaction when given a u-addr.

This could only happen if you are using a wallet that does not support shielded transactions but still can decode u-addr. However, afaik, it does not exist.

8 Likes