I’m happy to announce that zec-qt-wallet is building a companion app for Android mobile phones. It allows users that run a zec-qt-wallet node on their desktop to connect to it from their Android phones, and send/receive sapling transactions from their Android phone.
I’m looking for a few beta testers to test out the android app before the public release in the next couple of weeks. If you have a zec-qt-wallet node running and an Android phone, please read on.
What it is
Zec-Qt Wallet Android is a mobile app that connects to your desktop zec-qt-wallet using end-to-end encryption, and serves as a front-end on your Android phone. It lets you send and receive shielded and transparent transactions from your phone.
It is not a light-wallet, which is a separate protocol being developer. Your wallet and private keys are still held on the desktop. The Android app merely connects to your desktop and allows you to send/receive transactions from there.
What features are available
Simply scan a QR code displayed on your desktop to connect your phone. No username/password or any other config. Automatic end-to-end encryption from your phone to desktop
View list of recent transactions, and view transaction details including memos
Send a Sapling Tx. All Tx types are supported (zaddr → taddr, zaddr->zaddr, taddr->taddr, taddr->zaddr) and include a memo field as well.
Watch unconfirmed transactions and wait for confirmation.
What are the limitations
The Android phone needs a direct connection to your desktop. If you are on the same Wifi network, this will work seamlessly. (Support for connecting over the internet, without messing with firewalls/port forwarding etc… is coming soon!)
Old-style sprout addresses are not supported
Want to beta-test the Android App?
If you are interested in beta testing the android app, please comment below or send me a message. You’ll need:
A fully synced zec-qt-wallet desktop node
An Android phone
The ability to tolereate some bugs and give me lots of feedback
Acknowledgements
I want to thank the ZCash Foundation for supporting this project! @acityinohio@sonya and everyone at the Foundation has been super supportive. I’d also like to thank the Zcash Co, especially their light wallet UX team (Zcash Reference Wallet Design - Electric Coin Company), from whom I have shamelessly copied a lot of the app’s UX.
Security seems like it would be a big deal with this app (especially since it connects to your own desktop). Is there any plan to have this reviewed by third party security experts?
Nice work! I’m glad to see the reference wallet influencing your design - that’s the whole point!
I’m curious how you plan to achieve this (it ties into the security question above). UPnP? An external helper service (like Magic Wormhole does)? A NAT-punching overlay like I2P Destinations or Tor onion services?
Yes! Since the Android phone scans a QR code displayed on the zec-qt-wallet desktop, they have a shared secret, which both desktop and android phone use to encrypt all comms.
The plan is to have an external wormhole-like service that routes the already encrypted traffic between the desktop and the mobile phone.
I would love to get the code for this audited by some external 3rd party. Do you have ideas around who might be a good fit for this?
Yep. Like Magic Wormhole, the desktop could register an identifier with the helper (so that the helper can connect the phone’s connection to the desktops), but then send the identifier to the phone through the QR code along with the shared secret.
Briar uses a similar process for secure contact setup, but involving mutual scanning of QR codes between phones in order to perform a Diffie-Hellman key exchange, thus not exposing the actual shared secret in the QR code.
There’s the obvious privacy concerns of having a helper service, particularly for a persistent connection like this would be. You’d want to document them at a minimum, and if it was a concern then it would be possible to replace the helper with an I2P Destination or Tor onion run by the desktop, that only the phone is told about (and still using a shared secret on top of that to protect against service discovery attacks).
The two that come to mind are Least Authority and Trail of Bits. They could probably point you to other potential auditors as well.
Yes! The UI will make it clear what’s happening, and you’ll have to opt-in into the internet-routing. I’m still building all this, so it’s not ready yet, but it will be before public launch!
I’ll also reach out to the auditors. Thanks for the help!
and give me lots of feedback