Operators can specify a Zcash donation address #506
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
emersonian
force-pushed
the
donations
branch
from
38c2919 to
d126548
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch allows light wallet operators to specify a donation address. Anyone can help reimburse their hosting costs by periodically donating directly to operators to support a healthy network.
Pull requests are inbound to Hosh, Zingolib, and Zaino to support this field as well. Wallets may optionally support it.
This address will be how Zec.rocks knows where to reimburse participants in our workshop for their first six months of hosting expenses.
It would be nice if the address validated to be a real Zcash address. It would also be nice if the UA were validated to be orchard only with no T-address embedded to protect node operators' privacy. I am not aware of a golang library for this nor FFI bindings to another library at this time. These validation features are trivial in the Zaino implementation and will be implemented in the pull request there.
Yes, lightwalletd is heading towards deprecation. Until then we need to maintain feature parity between projects, and to continue a lightwalletd release cadence (can we please get an official release soon?)
Related PRs: