Implement tspend policy operations APIs

matheusd commented 3 years ago

Policy choice for tspends can be set on dcrwallet for both a specific pi key (that is, approving or disapproving all tspends signed by some given key) or by individual tspend hash.

This needs to be exposed so that stakeholders can select their preference for when their vote is cast.

At a minimum, users need to be able to set and retrieve the vote choices for a given ticket.

jholdstock commented 3 years ago

Add optional params to `/payFee` request

The client is currently setting their consensus vote choices when a ticket is initially registered with the /payFee request. We should add new, optional params to also set tspendPolicy and piKeyPolicy. eg.

...
"tspendPolicy": { "first_tspend_hash": "yes", "second_tspend_hash": "no" },
"piKeyPolicy": { "first_pi_key": "yes", "second_pi_key": "no" },
...

New endpoints for updating tspendPolicy/piKeyPolicy

/api/v3/settspendpolicy
/api/v3/setpikeypolicy

Using the same request encoding specified above, and the existing mechanisms for ticket authentication and storing request history for accountability.

Additional thoughts

decred/dcrwallet#2051 needed first
Valid values for vote choices are "invalid", "abstain", "yes", "no". Reject anything else (we can probably depend on dcrwallet to validate this, and just return the wallet error if it is descriptive enough)
Ensure tspend/pikey policy are being set in all places where consensus vote choices are currently being set, ie:
- Voting wallet consistency checking
- In the background handler, when a ticket fee tx is confirmed
We don't need to bump API version here because all new fields/endpoints are optional.

davecgh commented 3 years ago

The mostly seems fine, but I don't see a way to disallow a specific pi key (for example, if it gets compromised, etc). Simply not specifying one would result in an abstain as opposed to explicitly voting no.

jholdstock commented 3 years ago

Typo - I fixed the piKeyPolicy example above

jholdstock commented 3 years ago

I've started implementing this and rather than creating new endpoints for /setspendpolicy and /settreasurypolicy, I think it makes more sense to add new optional fields to the existing /setvotechoices endpoint.

The name setvotechoices is already generic enough to cover both consensus voting and treasury spend voting. Internally to vspd, it will ease the process of recording vote choice changes. From a wider perspective, it will reduce the amount of network calls required to update choices, which in turn may reduce the amount of times accounts need to be unlocked in dcrwallet to sign requests.

jholdstock commented 3 years ago

Still waiting for a way to bulk retrieve tspend/treasury policies from dcrwallet for the purpose of consistency checking.

Also identified that tspend and treasury policies could be a DoS vector for VSP servers. If vspd accepts any hash and/or any treasury key, a malicious user could spam loads of them and fill the vspd/wallet DBs.

jholdstock commented 1 year ago

Still waiting for a way to bulk retrieve tspend/treasury policies from dcrwallet for the purpose of consistency checking.

This is still outstanding, the last thing required before this issue is closed.

Also identified that tspend and treasury policies could be a DoS vector for VSP servers. If vspd accepts any hash and/or any treasury key, a malicious user could spam loads of them and fill the vspd/wallet DBs.

This was mitigated by subjecting tspend/treasury vote changes to the same limit as agenda vote changes. The database will only keep a record of the 10 most recent changes for each ticket.

decred / vspd