TOR for Lightwalletd

Pitch: A One-Liner Elevator Pitch Version Of Your Proposal

Hybrid GRPC & Tor Network Connectivity for Light Wallets

Total Request (USD):

$150000.00 USD

Have You Previously Received A Grant From Zcash Community Grants (Formerly Called ZOMG) Or ZF?


Please Provide Details:

Light wallets connect to servers using GRPC. Therefore the server can gather information about their users such as IP addresses and TXIDs.

This is a proposal for using TOR to increase the privacy of light wallet users.

The title and “total requested” are wrong and will be edited


Seem like a useful improvement indeed, thanks for offering to do this.

I would like to understand a bit more the cost to deliver this, is it possible to get more details? Or are details behind the zcashgrants link that requires a login?

I put an incorrect link in the OP. The public link is Gallery View: Zcash Community Grants Program (updated in OP).


There are discussions ongoing on Light Client Working Group in terms of who would be supporting Lightwalletd since Zooko had expressed that ECC would be aiming to decentralize core development and was no longer fully committed to provide further support other than what was strictly needed for Zashi wallet.

@joshs could you clarify if this is still ECC’s vision on Go Lang implementation of ZIP-317 aka “Lightwalletd”?

Other LCWG members like @zancas and other folks from Zingo expressed their interest in implementing ZIP-307 in a different language that has larger adoption within the Zcash ecosystem like Rust Lang, and even bundling LWD to the Zebra node.

I wonder if adding Tor Support to a codebase that was circumstantially developed in GoLang and has not wide-spread consensus of that being a good thing should be expanded forward, or if maybe Lightwalletd should be implemented in a different language with better adoption within the dev community and with Tor Support in mind from scratch


Having other implementations of lwd would be also good for decentralization of the code base.
The ECC has closed PR such as Add spam filters by adityapk00 · Pull Request #413 · zcash/lightwalletd · GitHub in favor of their API GetSubTreeRoots (directly committed, no PR). It’s their code and there isn’t much to argue.

1 Like

How crazy/feasible would it be to rewrite lightwalletd in Rust in the zebra repo?

1 Like

It shouldn’t be very hard but the rust implementation of grpc is 2x slower than in Go.
I benchmarked it and found results similar to Benchmarking gRPC in Rust & Go. Some background | by Rustler | Medium


gRPC is kind of a pain? I think I’ve heard other people ruminate that moving to regular https would be easier to work with? Does gRPC provide benefits that make it a necessity?

It is better at streaming. For other pros and cons, I suggest using chatgpt or Google.

1 Like

Grpc is not bad. A lot of code is generated by protoc that you would have had to code yourself.
Streamers are efficient to transmit the nature of the data wallets consume.

It has its trade-offs. It would be interesting to revisit it in the light of the experience we’ve had these years

Hi @pacu. Assuming you meant 307 and not 317, but correct me if I am mistaken. It’s not a priority for us right now and its not actively maintained by us aside from perhaps a bug fix here and there. Love hearing that @zancas is interested in modernizing the code.

We have talked about that as a possible path for zcashd retirement where we bundle Zebrad, lightwalletd and a cli wallet.


Yes I’m referring to Light Client Protocol for Payment Detection

The ZIP seems to be really out of date, it would be important that it is updated to reflect changes from NU5

1 Like

The key word in my question was necessity - I’m just playing dumb. There are code generators for http too…

I guess you could say I’m skeptical that the performance gains are worth the hassle.

Honestly I think ECC should revisit that decision to drop maintenance of lightwalletd. It’s not like zcashd: it doesn’t require a great deal of ongoing maintenance, it’s compatible with Zebra as a Light Wallet Protocol client, and it’s written in a memory-safe language. (Even if there would have been better choices, that doesn’t justify rewriting in Rust unless someone is particularly keen on doing it.) It’s critical infrastructure for Zashi and other mobile wallets.

Continuing to maintain lightwalletd, or sharing maintenance of it with ZF, is consistent with that.


It was an intentional decision not to merge that PR because we didn’t think that it was the right way forward: important non-spam transactions were being rejected by the lightwalletd instances using it. We did document and discuss that rationale on the PR.

I don’t know why we weren’t using PRs for lightwalletd development, but we should do so from now on. Let’s set branch protection on master so that we are required to do that. It would be a software engineering and security policy improvement, as well as helping coordination with third-party developers.


This has been set now.


My point is that the ECC makes the ultimate decision. You discussed it but finally rejected it. That’s fine as your team owns the code base.

PS: I understand a spam filter can have false positives but I have yet to see a real-world case where the spam filter would work incorrectly. The case in the PR was a transaction to a member of the ECC test team. A transaction with a large number of outputs was made to give coins for testing.

1 Like

No, real-world non-test transactions were getting filtered.


Could you clarify who makes these transactions?

1 Like

ECC, and I seem to remember also some from mining pools. I can’t give you any more details than that, partly because I don’t know all the details and partly for privacy. But they were not test transactions; we just chose a test transaction to document on the PR.

1 Like