zcash-qt-wallet is a UI wallet frontend for zcashd that fully supports shielded addresses (and t-Addresses as well). You can send & receive shielded transactions from the UI. Github page: GitHub - ZcashFoundation/zecwallet: A z-address first full node and UI wallet for zcash
I’m also working on adding sapling support, which should hopefully be ready before sapling activates on mainnet.
It works on linux and has been tested with zcashd 2.0.1. Please check it out and let me know what you think!
Looking forward to trying this but it requires Qt 5 to run and it’s crazy slow to install. Without it, extracting the binaries and running results in:
./zcash-qt-wallet-v.0.1.5/zcash-qt-wallet: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.11’ not found (required by ./zcash-qt-wallet-v.0.1.5/zcash-qt-wallet)
What extra does this involve? I’d imagine most things just work with the obvious exception being z_getnewaddress. Have you seen the summary of RPC updates regarding Sapling here as it’s a really useful summary? Network Upgrade Guide — Zcash Documentation 5.2.0 documentation
Thanks a ton for the feedback
I did a new release with a statically linked Qt, so you won’t have to install it to just try it out.
For sapling, I also want to make a one-click migration from sprout → sapling. The “turnstile” thing is confusing to people, so I wanted to add a special one-click way of doing it. Otherwise, the RPC APIs are all working correctly 
Thanks for taking the time to check it out.
Secondly, great! I love people thinking about UX 
Firstly, there are a bunch of privacy considerations you need to take into account:
z_sendmany (because users will most likely think “oh, I’m sending between two shielded addresses, I’m protected”), forcing users to do so manually via a transparent address (making it obvious that value is revealed).Add RPC for migrating funds from Sprout to Sapling · Issue #3268 · zcash/zcash · GitHub is the issue where we are going to be planning how to implement this migration safely for zcashd users. It will very likely involve adding a new RPC API specifically for creating these turnstile transactions carefully, and possibly some extra management code, both of which you may be able to leverage. Please do hop in there and keep us updated on your progress 
How about a toolbar tickbox/option that moves a random amount through the turnstile after a random number of blocks?
Call it each time the wallet is opened & eventually all funds are shielded.
Privacy vs UX is a fun tradeoff, especially for ZCash
I’ve been trying to hold myself to “1-click migration” while trying out different ideas for how to preserve privacy. I’ve been kicking around a bunch of ideas, some doable, some silly and some others out there
At the end of the day though, I’m trying to bias towards making it easy to use. I’ve tried to get lots of people interested in using ZCash (and Monero, for that matter), but they are put off by how complicated it is to use.
Thanks for that change - much simpler to try it 
I really like this, great work - it’s a simple and clean interface and I tried on testnet with a few shielded transactions (including Sapling).
A bit of feedback. When it sends a shielded tx it displays the operation id but then when it completes it would be nice to display the txid so this can be looked up on a block explorer so not id but result->txid in the z_getoperationstatus / z_getoperationresult call.
When it is syncing it returns the # of blocks but unless you know the latest block that isn’t particularly helpful. The # of blocks plus sync % would be much more informative (available via getblockchaininfo and verificationprogress).
It’s clear you’ve given a lot of thought to UX and I really liked the red for unconfirmed transactions. The transactions tab is interesting in this regard as it’s unintuitive that zcashd doesn’t store outgoing shielded transactions (so despite multiple sends I don’t see anything here). Not sure if/how this can be made clearer?
And now the feature requests begin 
I’m running on testnet maybe you could pick the port as 18232 by default if it detects testnet=1 in zcash.conf as I had to manually edit that and/or look for rpcport if set (I didn’t test if it already does)? Also, the ability to import/export keys would be super handy.
Looking forward to Sapling support. I created a Sapling address on the command line and it all works as expected in the wallet (sans the ability to generate this address). Sapling transactions are a real pleasure to use!
Hey, I really appreciate the detailed feedback.
When it sends a shielded tx it displays the operation id but then when it completes it would be nice to display the txid
Great idea. Will change this.
The # of blocks plus sync % would be much more informative
Yes. This is a good idea too! I’ll add it.
it’s unintuitive that zcashd doesn’t store outgoing shielded transactions
Yes, I got tripped up on this as well yesterday when I was testing it. I wasn’t sure what to do here. Maybe I should store the sent z-transactions from the UI in local storage and then splice it into the transactions table.
testnet maybe you could pick the port as 18232 by default
I added this today, will be in tomorrow’s release
ability to import/export keys
Yup, I was planning on adding this. The one thing I was worried about was that people might copy-paste the keys, exposing them into the clipboard where other snooping apps might read them. Maybe I should just save it to a file?
Once again, thanks a ton for the feedback! I’ll add all of these features in.
I believe it’s an intentional design choice of zcashd so I honestly don’t know how you should handle this. Maybe
@lindanaeunlee (Zcashco User Experience researcher) could offer some advice here?
Interesting thought but I think at the point your clipboard has been compromised you are probably screwed anyway… Curious how other wallets handle this - do they allow pasting keys?
and one last thing while you can’t see outgoing transactions incoming ones should be visible on the transactions tab (see z_listreceivedbyaddress). This reminds me that adding support for the encrypted memo field (via z_sendmany) would be a really nice addition.
It would be preferable to use bucketing, where the value shielded each time is picked from a pre-defined list (that is shared across all turnstile implementations) if possible. Early transactions will blend in with all other similar transactions on the chain, and only the final chaff transaction will be unique-looking.
@garethtdavies Thanks a ton for all the feedback yesterday. I incorporated a number of your ideas into a new release today.
I’ll get to the rest by the weekend
Awesome, I’ll give it a shot a bit later.
Edit, moved bug report to the better place of GitHub issues.
