I dabbled with getting some existing chain analysis tools to work with this, but ran into runtime errors. If I were able to get it running, I’d love to see the results.
ECC and ZF seem uniquely suited to do such research, and receive block reward funding to further the Zcash ecosystem. Isn’t this general sort of thing why the development fund exists?
To follow up on this, if anyone on this thread has experience with getting the Zcash variant of BlockSci working with a Zcash node, I’d love to know details.
Edit: it looks like @garethtdavies got it to work (apparently with a big of finessing); my thanks for help attempting to get it running!
Gentlemen, while I agree that “we need more research about T-address usage” is tangentially related to the ECC mobile wallet, it would probably be better in another thread to focus on the subject.
Noted! Apologies for bringing this thread a bit off track.
Have you considered submitting a ZF grant proposal?
@pacu @str4d Does it get any easier if you don’t need to support T addrs beyond immediately shielding funds and sending them to your zaddr? That seems like a much smaller change, especially UX wise. All most all of that is user transparent , pun intended. . And its enough to support loading your wallet from an existing exchange.
@secparam that’s a good question and my first thought is that doing what you suggest sounds like it involves a large enough chunk of work that it’s probably not much more effort to add full t-addr support, instead. In other words, I think the difference might be measured merely in days or hours of effort.
+1 kevin
@secparam I recall that we explored that possibility and we concluded that probably the user experience of covertly auto-shielding would be confusing. I correct me if I’m wrong @gmale, but I think that that tAddr support is the most iterated feature of the wallet so far. In terms of UX and UI, it opens up a lot of frontlines: receiving funds, consolidating balances, transaction details and history, a send flow that yields in two flows (t or z) at some point. So it’s one of those things that can complicate usability if not done correctly.
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?