I’m going to consolidate a few different posts regarding the ECC mobile wallet into this thread for continuing discussion.
4 Likes
9 Likes
Woo Hooo!!! Got it built & on my phone !!!
Edit: Had to jump through a few hoops to get Android Studio working, there were extra things to install via the SDK manager before I could build for my phone.
Edit: Can’t believe Shawn beat me to this, doesn’t he ever sleep??
So, some detail that might help anyone struggling. I was building on 64-bit Ubuntu so there are some extra things you need to install to make Android Studio work, all the info you need for that is here :- Install Android Studio | Android Developers
Once Android Studio was running it was not detecting my phone when I plugged in USB and there were build errors.
Switching my phone into Developer Mode and enabling USB Debugging fixed the first problem, the build errors were fixed in Android Studio by going to Tools->SDK Manager & checking the boxes for my phone version so it could fetch the missing libraries.
Restarted Android Studio & everything built & installed as expected.
13 Likes
Why doesn’t ECC want to publish mobile Wallet apps on app/play store? I feel like ECC is in best position to do that.
I think it comes down to what ECCs stance has been for years now: “We just publish open-source code on GitHub”.
If they were to offer it as a fully supported app it would involve levels of work like addressing customer service, app updates, testing on many different devices, Apple and Play store requirements, etc, etc…
If the ECC isn’t willing to take it that far I think in the future the MGRC should seriously consider hiring a team to do it.
[EDIT: That’s not to discount all the other outreach, regulatory and other work that ECC does, which is very important. Just that as far as what tools the end-user can interact with the ECC has been very hands-off that side of the equation]
3 Likes
There does seem to be a bit of a disconnect for what the ECC is publishing and what the end-user needs begin the migration to Z-addresses.
For example: I am super stoked that the ECC mobile wallet supports z2z (and it’s beautiful!) but why not also T-Z or Z-T? The Zcash user needs T-addresses to interact with 95% of the Zcash ecosystem for the foreseeable future, and it would be nice if there was something as polished as the ECC wallet code that could do it.
Is T support in the future plans for the rockstar ECC mobile wallet team?
Updated
Hang on, It looks like I’m off base on this one, you can in fact send Z-T in the ECC mobile wallet!
So that’s 50% of what I was hoping for…
5 Likes
I kinda hope not, the lack of ‘sexy wallet support’ for taddrs helps push this in the right direction, but that’s just me.
That is part of the issue, there is no lack of sexy T address support on wallets like Trust, Atomic, Jaxx, etc… but there is still a distinct lack of wallets that do T & Z nicely.
True. What I find interesting is the zECC wallet can’t send to a taddr which adds friction & nudges it in the right direction. Sort of ‘Oh, your wallet cant handle zaddrs, gotta upgrade, taddrs are so 2019…’. That sort of thing.
I get your point about there being lots of taddr wallets, you have to search for ZECwallet Lite on Google Play as its nowhere near the top of the list. Maybe next month that’ll change.
2 Likes
See my update above, I tested the ECC mobile wallet and it will let you send Z-T, but not receive to T.
2 Likes
Ughh, sorry, got my sends & receives muddled, I’ll avoid doing any big transactions today.
1 Like
(Disclaimer: I was on the ECC wallet team until around October last year, and have context prior to that point, but was not part of the subsequent product design discussions that led to the current ECC wallets.)
Two initial clarifying points:
- The ECC wallets inherently support T-to-Z (a shielded address can receive funds from both t-addresses and z-addresses). What they don’t support is receiving funds from a sender that doesn’t know how to send to a z-address (which requires either storing funds locally in the wallet in both t-addresses and z-addresses, or having a “receive-only” t-address and auto-shielding any received funds).
- As you subsequently noted, the wallets do support Z-to-T (sending funds to a t-address).
We first started work on the Android SDK in late 2018. At that point, there were plenty of mobile wallets that supported t-addresses, but nothing that supported z-addresses at all, let alone well. I recall that we discussed whether or not to have wallet t-address support, and if so, what kind (full support with parallel transparent and shielded balances, or “receive-only” with balances stored in shielded generally).
We decided that focusing on a z-address-first mobile experience made the most sense for our development resources and efforts, and the resulting work could then be integrated by other wallet developers into their existing products that already had t-address support. This carried over into the early version of the Android ECC wallet (which builds on the SDK), where we similarly wanted to start with a focus on the shielded experience, and storing shielded funds. IIRC we were more inclined at the time to work on “receive-only” t-address support, but we had enough to do just working on shielded support that this wasn’t a priority.
It looks like a few months back the wallet team started tracking work towards adding t-address support to the ECC wallets (Android, iOS). I have no idea how that work is being prioritised (there are many issues being tracked), but it’s clearly on their radar.
5 Likes
I 100% agree with this approach and I think the wallet team has delivered on this with accolades.
My questions about the future mobile development efforts stem from two lines of thought:
-
The ecosystem doesn’t support Z-addresses universally, and until it does we have to recognize that T-addresses will be around for some time. For instance; the most common way for a user to aquire ZEC is from an exchange and they (currently) will only send to a T-address. Until the code changes the ECC mobile wallet user will have to take the additional step of generating a T-address in a wallet (like ZecWallet) that can send to a Z-address before they can begin using the ECC mobile wallet.
-
Revenue for wallet providers. As Justin Smith’s talk about X-wallet from Zcon1 mentioned it’s very difficult for mobile wallet providers to be profitable since they operate on slim to no margins. Most non-custodial wallets like Jaxx and Atomic have built in exchange/swap crypo features. They do this because it’s one of the few ways they can earn a commission from providing a service to wallet users. Right now I can imagine quite a bit of work that would need to happen to get that back-end system working with Z-addresses even with the new ECC code. They too will need code that can make a T-address that can send to a Z-address and vise versa to make their system work.
Can you direct me to where you have seen these discussions on GitHub? I would like to link them to this thread.
I linked them:
3 Likes
About T-Address support:
We aimed to have T-Address support for open sourcing day on the past quarter objectives.
Supporting T-Addresses involves a lot of changes in terms of UI and functionality for Balances, Send Flow, Wallet History.
Truth is that we decided to iterate a few sprints on testing automation and integration with DarksideLightWalletd, because although we really liked the idea of open sourcing a feature packed App, we valued reliability, testability and maintainability more.
This aligns with our vision of providing tools that are useful to developers that want to build on top of Zcash. For example,
- on iOS, this meant growing the testing Lines of Code (at least on iOS) by leveraging DarksideLightWalletD by around 100%, which are no vanilla tests, but ReOrg and edge cases.
- For the whole community this meant that ANY light client developer can hook up to DarksideLightWalletD and run the pre-baked datasets to test that client reacts properly to ReOrgs
I hope this helps to clarify any doubts!
7 Likes
Thanks, as a developer, I sometimes forget about the step that’s required in order to load apps over USB since my devices always have that on.
I updated the README with links, based on your feedback, and I’m glad you were able to get it to work, fairly painlessly!
2 Likes
It’s a LOT of work because it fundamentally changes major areas of the app. As @pacu said, before heading down that road, we decided to setup a thorough test harness. With that in place, it is safer to rework the app’s “plumbing.”
Meanwhile, we’ve iterated a few times on the t-addr designs. In fact, if you build this branch on Android, you can see one of our first prototypes at UX for t-addr support. It taught us a lot. The designs looked good “on paper” but once we got them “in-hand” they felt wrong for mobile and too similar to a web page form. So we iterated and come up with something that solved the key problems and is more fitting for mobile. If you’re curious (or that old branch no longer works) here are the OLD designs:
2 Likes
I appreciate the reply @gmale and @pacu
On the other side of the coin a new “Nighthawk” wallet has removed the ability to send from Z-T at all 
As much as I like the idea of z2z only, I’m afraid it will be only useful for a small niche of Zcash users currently (which is still pretty cool) but not necessarily a good way to onboard users from the existing ecosystem.
IMHO, Less steps is better, just like user retention on a website the more hoops a user has to jump through to find what they are looking for the more likely to lose users attention.
1 Like
That being said, early research suggests that it is very easy to make poor decisions that lead to trivially traceable pool-interaction transitions. Without updated research on how common these patterns are, making it easy to interact with transparent assets introduces an unknown but likely risk to users who may think they are receiving benefits from the shielded pool.
I’ve argued elsewhere that ECC/ZF should absolutely prioritize and/or conduct updated research on unsafe shielded pool interactions to better understand these behaviors and inform users about safe use of both Zcash and “transparent Zcash” (I don’t like lumping them together).
1 Like
If you’re genuinely concerned about these risks to users, what’s stopping you from doing the research yourself? My understanding is that you are a mathematician, a cryptographer, a conductor of research and development, and have “extensive worldwide teaching and speaking experience” not only in the areas of mathematics and technology, but also applied cryptography. You are qualified to conduct such research, no?