Announcing: Nighthawk Wallet for Zcash đŸ›«

Zcash Apps
1

We’re pleased to announce the release of Nighthawk Wallet, a shielded-only wallet for Zcash!

Nighthawk Wallet is the first purely-z2z ZEC wallet and the first to be published utilizing the Electric Coin Company’s reference wallet code and SDKs.

Our first release for Android is now available, with an iOS app underway.

Download Nighthawk from the Google Play Store (or Aurora Store) or grab the source code.

What we’ve done

In our first release, we’ve made some small but important initial changes to the ECC Wallet and pushed it out into testers’ hands.

We removed the ability to deshield users’ funds by sending to T-addresses. While there are some great considerations on how to best leapfrog z2z adoption which still preserve ‘user-choice’, we felt it was time to simply force the issue, even if that means reduced functionality in the near-term.

We also removed analytics dependencies that were still being built along with the ECC Wallet and included in the APK. In a privacy-preserving project these should be checked at the door before production. Nighthawk does not and will never include analytics or trackers.

About us and our goals

Nighthawk will provide the purest Zcash experience, putting the simplest and most intuitive z2z wallet in as many hands as possible, without needing to make confusing claims to conditional privacy or allowing users to unwittingly expose themselves to correlation attacks.

No transactions made with Nighthawk wallet ought show up on Chainalysis, and to further this goal, our top project is integrating Tor support.

We’re an all-volunteer, unfunded team that came together from the Boston Zcash Meetup Group. Our intial core includes Adi, BostonZcash, and tw0po1nt. (@aiyadt and @BostonZcash are both members of the Zcash Foundation’s Community Advisory Panel.)

Mini-Roadmap

Here’s what we’ve put on our plate:

:arrow_right: Publish iOS version to App Store
:arrow_right: Support Android & iOS versions with bugfixes and device compatibility
:arrow_right: Implement Tor connections on both Android and iOS
:arrow_right: Operate our own lightwalletd infrastructure (ideally also available via a Tor-hidden service), proactively advising users of light wallet threat models
:arrow_right: Enable multiple and custom lightwalletd selection
:arrow_right: Remove dependency on proprietary libraries (like Google Play Services)
:arrow_right: Ensure compatibility with Google-free Android distributions and publish on F-Droid
:arrow_right: Obtain an Exodus rating that we’re free of trackers

And then perhaps cool stuff like Zboard!

Feedback

Your feedback, testing, (pull requests? :heart_eyes:), and critiques are much appreciated! You can reach us on Keybase, Twitter, Protonmail, or of course, z2z us.

This project would not have been undertaken if not for the amazing work by the Electric Coin Company’s wallet team. Kudos!

26 Likes
2

@joshs do you know what this is about?

1 Like
3

No, but I’ll check.

4

Could I interest you guys in adding t2z support via say auto shielding so people can fund it easily (with a serious warning on it). I think full t2t support is bad. But the t addr hotel is fine: taddrs check in, they don’t check out.

Also this thing looks awesome in terms of the colors, etc.

8 Likes
5

I’de definitely be keen to see modular auto-shielding support that could be enabled if the user wants it! I also prefer that over having both shielded and transparent balances in the wallet.

Kudos to @geffen for his awesome design work on the wallet interface! :zebra: :heart:

7 Likes
6

My understanding is that analytics for ECC’s internal use were disabled (commented out), but the dependencies for them were still being built by default. This is mentioned on the Android wallet repo here. It was expected that downstreams that do not need these dependencies would remove them. I agree they should not be built by default, though.

5 Likes
7

Calling the two analytics libraries is disabled in runtime, but I believe they are still linked in. That may be enough to trigger their (potentially nefarious) code, via initializers etc.

1 Like
8

My understanding is that we were using them to track feedback and crash analytics while ECC employees were dog fooding the wallet internally. They are commented out in the public repo and not necessary. We’ll discuss simply removing them from the published source to avoid confusion.

3 Likes
9

Awesome work and kudos to the nighthawk team!!! :tada: :night_with_stars:

4 Likes
10

This is very cool!

What’s better than a forum thread debating how to move to fully shielded? A live market place experiment to validate how feasible the fully shielded ecosystem is. If many users use Nighthawk it puts pressure on services to upgrade to shielded. If few users use it, it may indicate not enough ecosystem has upgraded to shielded.

Both benefit Zcash: the user adoption pressure and measuring viability.

BTW- it might be cool to work with paywithzcash.com to provide a “shielded support” filter on the pay / earn options there.

13 Likes
11

Do you guys fetch the memo by default? I’m told the ECC prototype does. This means the wallet server learns which transactions belong to its uses and potentially the IP (if not done over tor) Wallet App Threat Model — Zcash Documentation 5.2.0 documentation

This is a really bad idea if you take privacy seriously. The minimal fix is don’t fetch the memo default. This shouldn’t even degrade the UX by much, just means u put the memo behind a view button. That would still leak, but only for users who view the memos. We can also then fix that using e.g. private information retrieval, but thats a bit more work.

See also this issue. Practical Privacy Issues in Lite Clients

6 Likes
12

Given the way mobile apps work and the way we’ve disabled crash reporting and analytics, it is not at all likely that nefarious code can run.

@dontbeevil and others, let me provide some context because these are valid concerns:

We started this app from scratch around Thanksgiving and had our first company-wide release in early January. Given the holidays, that is an insanely fast timeline for one developer to create something like this. It’s entire purpose was to collect internal feedback so that we can improve the mobile SDKs to support a smooth user experience. Rapid, debuggable feedback was critical. If it crashed, I wanted to know, immediately, and have enough metadata to dig DEEP into the root problem. It served that purpose greatly, leading to us building an entire integration test suite to pinpoint and correct very complex issues, especially around reorgs. Who else is going to do that work? Doing it well requires data.

When we started the “ECC Wallet,” we didn’t know exactly where it would lead us. As an internal tool, I didn’t expect it to be open-sourced. I honestly figured we might just throw it away and keep the SDK / lightwalletd improvements. But people really liked it?!! . . . and then we lined up a hackathon with Gitcoin. So we pivoted toward preparing for that and our timelines become VERY compressed, as a result.

Taking an app that was designed for dogfooding and troubleshooting and then pivoting it to be the opposite of that is not a small task. To hit our hackathon deadlines, we openly made a tradeoff to disable analytics for now until we can build all the screens around giving users an option to help us test and gather feedback because that’s the intended use for this particular app. We just happened to pull back the curtain and let people see what we’ve been testing.

I think of the ECC Wallet as a test app–we refer to it as “the dogfooding app.” It is not competing for market share. There will be other apps for other purposes (I’m literally coding one right now for the hackathon) but THIS dogfooding app is still a tool with which to learn. We want someone to take it as inspiration and build cool things. If the mere presence of analytics libraries makes you nervous, no problem, it’s open-source, just remove them. Or better yet, use the Nighthawk Wallet :slight_smile: :tada: :night_with_stars:

I want to underscore what the fantastic Nighthawk team has accomplished–I could not be more excited!!! If it weren’t for COVID, I would try to fly to Boston just to meet them and hang out and build cool stuff.

10 Likes
13

Thanks for the feedback! I’ve added this as a suggested enhancement on the ECC Wallet repo and added details on the current logic for memos. Any additional feedback is welcome!

3 Likes
14

One other comment. It took me a while to figure out i had to click in the top right to get my address. I think the icon could be clearer. Or have text accross the top going qr icon ← recieve 
 send → some icon

1 Like
15

Also works with Orbot, not exactly surprising but using Tor is always nice - especially when its that easy

4 Likes
16

Is this really a fix at all? The trend seems to be that light clients want to fetch memos, and whether this is done automatically or manually doesn’t change the underlying privacy concerns; it just forwards the burden on to the person using the wallet who is in a worse place to understand what those concerns and risks actually are.

Now with a growing pool of light clients starting development (and deployment) seems to be a good time to work out exactly what the solution to this should be while still early enough in development - my biggest fear in this area being that this gets put off for long enough that we end up with a perpetual pool of light clients all with slightly different memo-driven behaviors, fracturing the anonymity enough to lose any potential benefit of a more robust mechanism.

This goes beyond the specific Nighthawk wallet, so I’ll suggest that any future discussion on this happens in the Practical Privacy Issues in Lite Clients thread.

5 Likes
17

Its the minimal fix in the context of : a shipping piece of software that 1) is going to ship no matter what and 2) screws over everyone by default 3) a utilitarian greatest privacy for the greatest number.

It’s the fix that contains the blast radius. The other option is pull the eject handle and don’t ship the wallet. I’m guessing that won’t happen (not my call either way). So do you want the bug to impact more people or less. Defaults matter. And most people don’t use memos.

I agree: the actual solution is to do something better long term, like PIR. But, lets not let the quest for a long term solution delay mitigating the harms of the current approach as much as possible

18

Are there numbers on this? In my experience running a public zcash address for Open Privacy we receive far more memos than we receive donations (nominal value greater than $1) to that address (I would estimate 10:1) - one of the primary features light wallets have been advertising is memo support. Memos are one of the key selling points of zcash, and one of the main things ecosystem projects are building on. I think it would be a mistake to treat them as second-class features regardless of their current use, but my perception is that people who currently use zcash, use memos.

delay mitigating the harms of the current approach as much as possible

My point was that making it manual explicitly doesn’t mitigate the harms, it just offsets them. Defaults do indeed matter, but nothing is more permanent than a “temporary” fix. I personally don’t think a few weeks/months of discussions on better strategies is too much to ask prior to shipping privacy preserving software, and I would hope the ecosystem community is willing to err on the side of caution given the risk model that zcash operates in.

6 Likes
19

This is not true, at least for Zecwallet users. Memos are the most popular and most used feature of the Zecwallet lite client, both on desktop and on mobile.

11 Likes
20

The problem is, its not going to be a few months for a “real” fix. It look 2 years to ship a wallet. Paralysis will happen. Trust me, I’ve been around here for a very long time. In the meantime, we’ve broken privacy by default for everyone. This isn’t acceptable.

Instead we can at least get privacy for whoever doesn’t use memos and we can tell them not to use them on mobile if they care. And for a wallet that is marketed as being especially stealthy, we kinda should at least have a way to give people the option. It is not ideal. There’s a risk it’s the only solution we build, I agree. But the alternative is worse.

Moreover, the sad reality is memo’s don’t scale and are going to have to die in their current form. You can’t scan blocks to find memo’s or detect payments scalably. And scalable anonymous communication is actually far harder than hiding onchain metadata. Its an unsolved problem in academic CS, unlike decentralized private payments which we solved in 2013/14. So we either are going to have to move to a mixnet (i’m skeptical of that ever getting off the ground given the history of minxes) or use out of band messaging to notify you of a paymet. The latter is far more likely and makes memos moot.

As you said, this isn’t the right thread for this. But I want to be clear, shipping software that by default exposes which transaction is yours to the server is not an acceptable assumption. There is no but to that.

5 Likes