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.
2 Likes
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.
5 Likes
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.
1 Like
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.
1 Like
What happened with this effort?
Hey Shawn! thanks for checking in, I committed the cardinal sin of putting a timeline on feature development here for sure. This fell behind a bit but is underway (and currently it is the primary effort of the wallet team), it slipped behind a few other efforts, including testing and community wallet support in the last couple of months. The current piece we’re working on along with a ton of help from Core (https://github.com/zcash/librustzcash/pull/307) will enable our t-address implementation which will look something like “assisted shielding”, meaning shielding transactions won’t happen without the user knowing, but will happen very easily with user consent at the click of a button. I don’t want to put out another timeline that proves to be off but we are looking to deliver this soon.
5 Likes