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?
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
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?
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.
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.
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.
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.