Suggestion [0]: This section should contain a bullet point requiring the installation of a Tor daemon, and zcashd configuration to work with it unless the user opts out of Tor. That provides basic (but suboptimal) network-layer privacy by default.
Whenever Zcash starts to support onions (which it currently doesn’t), that should be configured by default. The node MUST support outbound connections to onions, and SHOULD configure an onion listener unless the user disables listening. (Thereby using RFC 2119 language.) I would even suggest adding an interface that helps the user opt-in to running a Tor middle node or bridge node, with secure defaults.
Suggestion [1]: This section should include a bullet point for something that the Zcash community badly needs anyway—perhaps even a subject for a separate grant: Investigating and documenting low-end hardware requirements for running an inexpensive node.
The Bitcoin community is full of such things—for only one example:
Someone (cough) should test a variety of configurations using inexpensive, widely-available hardware, report on what works/what doesn’t, and eventually develop a practical guide for easily running a low-cost node. But that costs money.
Support for a beta-development alternative node should not be a requirement. zcashd fulfills the stated purposes for which this project is proposed. Anyway, support for an alternative node is the type of thing which could be added in the future, if/when zebrad is fully mature.
Please stipulate that this should be fully and easily under the user’s control, even if it is enabled by default.
(As a separate issue, this is a general problem with zcashd: It can force you to update, unless you know how to edit code and recompile. To protect decentralization and avoid centralized authority, Bitcoin intentionally deprives Bitcoin Core developers of any ability whatsoever to twist people’s arms into changing to new versions. Except in the extremely rare event of a CVE, the only reason to install a new Bitcoin Core version is if you want to—which most people do.)
Reorgs should never require a reindex. A reorg is normal behaviour on a blockchain. A consensus node (and anything built on a consensus node) should handle reorgs gracefully and automatically.
Where have you seen a reorg require reindexing? That would be a serious bug.
I have never reindexed my zcashd due to a reorg. I have never (yet) used lightwalletd, so I cannot comment on that.
The foregoing are only some passing comments. If I have any further comments or wish to engage here, I will return to this thread.