Zenith doesn’t check which network the node is running on. If running a zcashd node on testnet doesn’t change the RPC calls or their output, Zenith should work.
We have some checks to verify if an address is valid, I believe the testnet addresses are different than mainnet, that would need to be adjusted to support testnet.
Edit: The address validation is specific for sending transactions, it doesn’t impact the reading of Tx from the node.
Hi @gesker !
I am a partisan advocate of Zingo because that’s where my effort is focused.
I don’t think there is a reference implementation for lightwallets.
zecwallet was unmaintained and became unusable during the NU5 upgrade last year.
zingo was code-forked from zecwallet by ZingoLabs, in part, because we recognized the critical need to provide a reliable alternative.
zecwallet code connects to a fork of the ECC lightwalletd server.
zingo connects to the ECC lightwalletd server
ZingoLabs intends to migrate our client bindings into librustzcash such that our client is built on the same protobuf specs as the ECC lightwalletd server.
A point of divergence between ECC lightwalletd and zecwallet lightwalletd is that zecwallet-lightwalletd provides a price-information service. ZingoLabs considers combining price-information with the lightwalletd services to be a serious vulnerability.
In short, as a part of our strategy to be reliably available we are client synced with the ECC lightwalletd implementation.
I haven’t attempted to use zecwallet-cli in a long time, so I don’t know its state. I know that zingo-cli is used by an active development community.
zingo-cli has a --regtest mode flag, that connects the CLI to a lightwalletd/zcashd running in the “regtest” mode originally written by the bitcoin folks.
We’ve added a suite of “integration tests” using that pattern that exercise the whole stack:
lightclient <–> ECC-lightwalletd <–> zcashd-in-regtest-mode
We’re actively extending that test framework.
Thanks again @zancas and @Autotunafish. I really do appreciate you help and the folks in the zingolabs chat were super nice, too!
Here are some notes I just shared in the zingolabs chat:
https://github.com/gesker/zcashd_config
https://github.com/gesker/zebrad_config
https://github.com/gesker/lightwalletd_config
I’m thinking that these MIGHT be useful to someone else getting started in writing applications against the zcash blockchain.
I kind of took the approach that the OS should control the life of the daemons and that really it’s the initial syncing of the chain data that is the initial limiting time factor. I also tried to use somewhat reasonable “alternate” ports.
If one follows all 3 at the end their system will have:
[zcash blockchain network] <--> 8233:[zcash mainnet]:8232 <--> [lightwalletd]:9067(Rest)&9068(gRpc) <--> wallet software
[zcash blockchain network] <--> 18233:[zcash testnet]:18232 <--> [lightwalletd]:9069(Rest)&9070(gRpc) <--> wallet software
[zcash blockchain network] <--> 8234:[zebra mainnet]:8242 <--> [lightwalletd]:9071(Rest)&9072(gRpc) <--> wallet software
[zcash blockchain network] <--> 18234:[zebra testnet]:18242 <--> [lightwalletd]:9073(Rest)&9074(gRpc) <--> wallet software
Again, I’m grateful to you both for all of your help!
Dennis