Revised Nym for ZCash Network-level Privacy

Also, there may be some questions about how feasible a mixnet is in terms of timing. That’s what we are working on next for the larger threat model blog post, but to get a feel for the current scrappy code, sending a tx with z_sendmany just took 40 seconds, and getting the op status on the returned op-id with z_getoperationstatus took 17 seconds.

5 Likes

Harry are you still targeting end of November this year for wallet integration?

@joshs @zancas can you guys share any timelines when a working beta wallet will be available for the public?

Thank you

2 Likes

We haven’t been significantly engaged. Based on what we know, we’re assuming we can explore NYM integration in October.

5 Likes

I will post something on the forum by this Friday (ping me if it’s Thursday and you’ve not heard from me).

4 Likes

Yes, we are still planning on November. We have syncing working with our rust code and a local lightwalletd instance: we were able to sync a solid few days of block headers (125 batches of block headers). We plan to engage the Zashi team though once we get things a bit more stable, getting gRPC off the ground has been more work than expected. Sorry for the slow response, was at the PETS conference!

7 Likes

Hello ZCash community!

Nym is excited to share an update on the progress of the Nym-ZCash Network-Level Privacy grant.

Specifically, we’ve been working on creating an HTTPS Connect Proxy for Nym, enabling Nym to integrate with gRPC.

You can find the latest developments here: Nym-ZCash gRPC Demo.

In addition, we’re pleased to present a paper by the Nym Research Team, led by Ania Piotrowska, titled “Addressing Network-Level Threats in Zcash Using the Nym Network.”

We invite the ZCash community to review and comment on the research document, and the Nym Research team will address any feedback.

We’re thrilled with the progress so far and look forward to continuing our collaboration with the ZCash to provide privacy for everyone.

5 Likes

We’ve also prepared a demo showcasing the interaction with a Lightwalletd instance over the Nym mixnet using the Zingo CLI wallet.

You can watch the demo here: YouTube Demo.

3 Likes

If anyone has any technical questions about the update work and the code, feel free to @ me in here as well

2 Likes

That’s an excellent and very thorough threat model!

I made a couple comments in the doc that I’ll copy here since they’re important to the bigger picture of light wallet privacy (beyond what plugging in Nym can help with):

Another thing wallets do that is privacy-related is update the witnesses for their notes. This should probably be noted in this threat model since it’s a bit different from the problem of fetching transactions / blocks (Identify options for transaction discovery that do not require Θ(#transactions * #wallets) effort. · Issue #6756 · zcash/zcash · GitHub).

and:

There’s a caveat to this which should be noted in this threat model:

Most Zcash light wallets support receiving funds at a transparent address, so they need to continually check their transparent balance. They do that by providing their transparent address to lightwalletd at regular intervals, and lightwalletd replies with an updated balance or transaction list.

This means that even when all requests are anonymized through Nym, lightwalletd is still aware of all the transparent addresses of currently-active wallets. The requests won’t be linkable to an IP address, but lightwalletd can still be very confident about information leaks of the form, “I have this list of 100 transparent addresses of recently-active wallets, and it’s very likely that this shielded transaction I just received, or this shielded transaction retrieval request I just got, was created by one of those 100 wallets.”

In other words, it will still be possible for lightwalletd to construct a rough approximation of the shielded transaction graph, where instead of actions being linkable to an IP address, they are linkable to the set of currently active wallets (identified by their transparent addresses).

Fixing these leaks will probably require some deeper changes to the wallet protocol, some options are to remove transparent address support, use PIR for transparent transaction lookup, perform transparent-address-related operations through a separate non-colluding server, etc.

Great work on the threat model, it demonstrates a clear understanding of the privacy issues in Zcash light wallets and how Nym will make things better. :slight_smile:

7 Likes

Hello folks. Zingo Labs has been hacking away on Nym-and-related integrations.

@idky137 has been architecting, implementing, and testing solutions that include Nym support as a first class component of the new Indexer solution that we hope to build for the community.

As the diagrams on our soon-to-be updated grant proposal will show the Indexer is the correct place for integration with network privacy technologies. To be clear these diagrams represent substantial completed work, particularly around Nym integrations that @idky137 in collaboration with @med (and I think maybe @mxx) has done.

If you believe that @harryhalpin and company’s Nym work is the best solution for network privacy, and therefore necessary as a core component of zcash infrastructure please consider supporting the Zingo Labs bid to build that infrastructure.

5 Likes

@zancas look forward to seeing the diagrams and integration!

Hi everyone: we’re just waiting on the final QA checks for a big update on the Nym Zcash integration work, expect a big update in the next few days

11 Likes

Hi everyone - this is mxx but since I’m a new user then I was rate limited to 3 consecutive posts, which I didn’t realise was a limitation, so I made a new account to share the update with you all. I have also had to make a few links into pseudo links due to the maximum of 2 links per post for new users.

Thanks for your patience when we’ve been getting this ready to show you all. I’m happy to annouce that the code for the Nym TCP Proxies - the code from the RPC and gRPC demos - is now part of the Rust SDK. This code involves a pair of components, a ProxyClient and ProxyServer which expose a localhost TCP port that applications up and downstream of the proxies can interact with without having to worry about the message-based nature of the Mixnet.

These components have also been exposed to Go via FFI(github[dot]com/nymtech/nym/tree/nym-binaries-v2024.12-aero/sdk/ffi/go) and I have created a pair of standalone proxy binaries which are used in a similar way to the previous demos, but might be fun / easier for people to initially play around with, and also might prove useful for server setups where several components are being run via init scripts, and the addition of a separate process is acceptable.

There is documentation for this code here(github[dot]com/nymtech/nym/blob/max/new-docs-framework/documentation/docs/pages/developers/rust/tcpproxy/architecture.mdx) for the moment, as we are also working on a v2 of the Nym docs which will be deployed soon, the developers section of which is almost completely revamped. The linked documentation includes some diagrams of the traffic flow and what exactly these abstractions are doing; message ordering and session management under the hood in order to account for the fact that the Mixnet guarentees delivery but not ordering, as well as framing messages either side of the Mixnet.

If you have questions about any of this new work, please let me know. Thanks

9 Likes

Thanks, I’ll have a look at those soon!

@moderators can you bump up @mxx’s forum access please?

1 Like

My access was already kindly bumped by @Shawn :slight_smile:

2 Likes

Hi all, just a quick update - there are now new docs for the TcpProxy module and the Go FFI which can be used to send zcash traffic through the Mixnet:

6 Likes

Hi harry,

Is the above still true? Was hoping to run nodes but … :smiley:

2 Likes

Hi there, sorry for the late reply, I’ve been doing some events recently and this slipped through.

I think there’s two points to make here, one concerning the sudo requirement, and one more general point about the connection between the mixnet / this integration work and the NymVPN product.

sudo requirements
Can you provide more information re: which version of the NymVPN application you’re using? None of the beta app versions listed on this page which we have open for public testing right now require sudo as far as I am aware (I run the Arch build every day).

I think some older versions however might have done - could you be running one of these?

Mixnet integration vs NymVPN
This is really just a clarificatory point regarding the relationship between the NymVPN product and the Mixnet more generally: the NymVPN application is the first ‘product’ to be being built to use the Mixnet infrastructure (the full mixnet for anon mode + entry and exit gateways for speedy mode). The integration work referred to above / by me does not overlap with this product, and is solely work to allow for embedded Nym clients (in the form of the TcpProxy client + server) to be used by ZCash wallets + infrastructure via our Rust SDK and FFI code.

Running a Nym client in any of the examples I have linked above does not require any sudo privileges.

Hope this clears up any concerns!

2 Likes

This is still true as far as I am aware, yes.

1 Like

Ah sorry, I realise a mistake in my last message due to how I install / update the linux app and post-travel headfog. I believe this is related to the daemon.

If running the daemon in the background like this is an issue I can check in with the people working on the ios app to see if there is a non-sudo way of doing it.

Also just to reiterate what I said above, this is a product built using the Mixnet infrastructure, but this does not have crossover with the work referred to in this grant. So its very possible to interact with the Mixnet without using the NymVPN application.

4 Likes