I’m guessing 4 was small and 2 >>> 3. But it sounds like 1 was the problem? So any attempt to do it would have involved lots of brainstorming and man power?
It’s not necessarily about “easiest” in regards to t-address support. As has already been pointed out, I think correctly, there are a lot of considerations regarding existing user experience, privacy, and the convenient and intuitive onboarding of t-address users into the shielded ecosystem. An auto-shielding system had numerous UX hurdles that made it, at least at this point, less attractive than an approach that provides full t to z features and education to bring those already familiar with t-addresses into the shielded ecosystem without having to jump through a lot of hoops from their existing wallet.
With that being said we are taking a very iterative approach to these apps. They are experiments, both in the technical direction of shielded ZEC on mobile and the user experience of bringing people into the shielded ecosystem. I would expect the apps to continue to evolve and for us experiment with different ways to achieve the same goal; get shielded capability in the hands of everyone.
With all of that being said, we’ll be adding full t-address support very soon, probably by the end of July.
Nice, thank you for the update! Soon we will have open-source code for both kinds of wallet users, one for those that need/want T-addresses and one for those that do not 
I’m not sure t2t support is good. We need shielded adoption or there’s no point in zcash. The first idea was ban taddrs. But no, we’re told, that would hurt adoption. Ok, now the narrative is: let’s leapfrog and get shielded adoption by having wallets default to shielded. This is totally reasonable. As an analogy: HTTP isn’t banned on the internet, browsers just heavily encourage and nudge users use HTTPS. Will there be any such nudge in the ECC wallet against t2t ? @gmale ?
Remember, all exchanges currently are taddr only. So we need to support t2z, And similarly zt2. But t2t isn’t so clear. So if we do t2t support and don’t have any nudge, then we’ve just caused more people to store their money in taddrs and probably not move it. Instead of being a means to drive adoption of privacy preserving cryptocurrency, we’d just be building a means to pump yet another shit coin. And make no mistake, zcash without meaningful zaddr usage is a shit coin.
Everyone at ECC, ZFND, etc signed up because we didn’t want twitter for your bank account. The only substantive effect of t2t support is getting more people on twitter for your bank account. We’re better than that.
I agree with your point about not supporting T to T directly.
Why not make the wallet:
That way the wallet won’t let a user hold funds in a T-address only to send from that T-address later on. The downside is they will have to wait a bit longer for the wallet to auto-shield for them until they can send T address funds, but this could improve privacy and encourage more Z2Z because Z2Z would be faster.
To what extent might this leak information through the now-classic t-z-t cycle that has been identified as problematic in the past? If it leads to that kind of trivial tracing, it hasn’t done anything for that user’s privacy, but may provide a false sense of security.
Past research has shown that the majority of the t-z-t pass-through has occurred because mining pools have to shield every coinbase transaction by default, and they pay the majority of thier miners to T, or they send to an exchange which only accepts T deposits. The ECC mobile wallet code won’t do anything to change that behavior.
Don’t get me wrong, we absolutely need to depreciate T-addresses ASAP but I think we are barking up the wrong tree. The core protocol needs to change to depreciate T-addresses, unfortunately we are not going to change the behavior of the major players (exchanges/miners) by forcing the end-users to take more steps to begin using Z address only mobile wallets.
Which is a better new user experience?
Or would it be better
Bottom line is we need to get the ECC and ZFND to prioritize the depreciation of T-addresses in order to meaningfully move the needle on Z-address use, playing around with what mobile wallets can and can’t do isn’t going to be enough.
The people who do t-z-t transactions 1) are mostly miners 2) will do them in a world with t2t support as well and 3) we can have the wallet warn them if they do t-z-t with similar amounts.
But more generally, you can find a privacy gotcha on anything and paralyze yourself. But inaction leads to a greater privacy harm because most people won’t have private transactions. Inaction is an easier choice because it avoids causal responsibility. But the consequence of inaction is still the same. And we should be worried about consequences not responsibility.
For example, auto shielding to support t2z would leak that you used ECCs wallet ( or another using that feature). This is a small harm, especially if it only shows up for transactions from an exchange to your wallet where the exchange knows your real identity. But it is a real harm. However, is it worse than most people doing an exchange to wallet transaction and keeping it transparent? No. And that is the consequence of supporting t2t without a nudge.
I think the answer is going as far as we can to make “auto-shield in background when receiving t2t” the default behavior across all wallets, and only eliminate t2t transactions once exchange support for t2z has reached a certain critical mass.
The exchanges have a lot of leverage over the user, because users don’t have too many options for what exchange they use in a given jurisdiction. And the process for linking a bank account etc is time consuming. So if exchanges will only send to t addresses, I think you have to just accept that until you coax them to change, since disabling t to t transactions without exchange support would cut off wallets from the exchanges users already are in the habit of using. That would throw away one of Zcash’s major benefits, which is support from mainstream exchanges.
I don’t think wallet developers or even ECC have enough leverage over exchanges to force them to add t2z functionality if they currently only support t2t, just by disabling t2t transactions. I think the path here has to be that ECC and/or ZF supports several key exchanges in addressing any technical and policy blockers to supporting sending to z addresses, until there is a critical mass of exchanges that support t2z. Once there was sufficient support from exchanges you could disable t2t transactions at the protocol level. It might be a good exercise to clarify what counts as sufficient critical mass, too. I’d say “3 or 4 top exchanges including at least one of Coinbase or Gemini, and at least one instant exchange service in most countries” though I think it depends on an assessment of whether exchanges just need a nudge or whether there is significant technical or regulatory work involved.
It might make sense to set a deadline for exchanges to add this functionality after which t2t transactions will be disabled, but I think that has to be done with some sense of how far along you are in the process of convincing exchanges, because if too many simply disable Zcash support that would be a disaster. But having such a deadline could be part of the approach.
I think the “auto-shield in background” approach is what it has to be for now. Zbay does this and it seems like a pretty good user experience overall.
One way to address the problem of revealing your wallet would be to build this “auto-shield in background” functionality into zcashd and enable it by default, so that all major wallets have the same behavior. Would there be any downside to this? Should we create an issue for it?
Holmes
Pay-To-Taddrs needs friction - maybe only pay to taddrs that are pre-registered on the users whitelist? (ie: exchange addr).
Do we need to support t2t in the wallet beyond auto shielding? I agree, a wallet needs to take funds from t and pay funds to t, and as long as exchanges won’t do t2z, we need auto shielding. But why support t2t beyond that? If your using the wallet, by definition one side of that transaction supports z?
yeah, i don’t see any other need for t2t other than receiving from an exchange and autoshielding.
do exchanges themselves need t2t internally?
I’d assume they do. But they don’t use the wallet SDK for it. So there’s no valid reason to ship support for it in the wallet unless, of course, you want to encourage t2t usage. And since we aren’t a shit coin, I cannot imagine why we’d want to encourage people not to use our one defining feature.
Can we define auto-shielding precisely, because I’m personally against the idea of doing any type of transaction on the user’s behalf that could result in them being surprised or losing value by way of fees, without their knowledge.
A 1-tap shielding feature might be a step in the right direction and could be considered “auto” in that it creates, submits, and monitors a transaction for completion, all in one tap. Similarly, someone with 10 incoming t-addr transactions might prefer to shield them all in one lump and only pay fees once.
So there is probably a spectrum for assisting the process of shielding, ranging from “nothing” to “fully automatic” and it doesn’t sound like the latter is the only option. Rather, we ought to at least nudge toward shielding.
The way Zecwallet does autoshielding right now is that it shields transparent funds “lazily”. That is, at the first tx that the user does to a z address, it uses the same transaction to send all t-address funds to the users z-address as change. Since the user was doing this Tx anyway, there are no additional fees.
Zecwallet Lite does autoshield?
I think @adityapk00 has a good idea. And maybe add some flow for doing it non lazily.
But the hard and fast rule is: the wallet will not send a t2t transaction. I.e. all funds in your pending t pool get converted into z and then you can spend.
This could be relaxed to : you can send/make one t2t payment, but in the process it shields all existing funds.
But separately: I think its entirely feasible to have a special purpose load funds from an exchange flow. It does auto shielding and carries a remark: because this exchange does not value your privacy, fees are $thismuch instead of $thatmuch. This would also generate some pressure on the exchanges to adopt shielded because it costs their users money not to.
Having a UI flow specifically designed for shielding incoming funds is a cool idea! It could even incorporate single-use addresses for receiving and then shielding.
Similarly a “shield all future transactions from this source” would be a nice feature. That way, I know every time that I withdraw funds from my exchange account to my phone, they’re getting shielded in the background.
I think it’s fine to do it non-lazily too as long as there’s disclosure on the add funds screen where the t-address is displayed. This is what we do in Zbay: shielding funds immediately when people deposit to a transparent address.
It’s a bit better than lazy shielding. If for some reason they send funds to a t-address before sending to another z-address, they can be sure that it was shielded. I think there are some other benefits too. It keeps things clean. And if they’re depositing money from an exchange the transaction is probably large enough that the fee isn’t a big deal.
In user testing we found that putting the distinction between transparent and shielded addresses front-and-center confused people, which makes sense because it forces them to learn something somewhat involved about Zcash when they might barely know how cryptocurrencies work. Since exchanges pretty much only support transparent addresses, and since a Zbay user is likely to receive money by someone just sending it to their username—which will always be a shielded transaction—we thought of depositing to a shielded address as a pro-feature and put that farther down the page, but put the emphasis on seeing and copying the transparent address, since that’s what most people will have to do to add funds from an exchange. Automatically shielding deposits made to the t-address let us put the address they’re likely to need (until exchanges support z-addresses, anyway) front and center while still protecting their privacy.
Once we have an instant-purchase solution that works with shielded transactions we’ll build a flow around that and they won’t even have to worry about exchanges that only support transparent addresses.
Here’s where we’re going with this. (“Deposits are moved to a private address & stored by Zbay, on your computer.”) Note that the “private address” section in the screenshot is collapsed by default.
