Feature Request: Use hd wallet branch as stakepool key

[matheusd]

This issue is for summarizing and tracking the status of something discussed in slack a while ago. Initial disclaimer: this is likely to be a change stretching multiple repos (at the very least, dcrwallet and stakepoold) and fundamentally changes how funded and voting wallets are integrated, so expect this to be a big changeset and to need very thorough testing and review.

One downside of the current voting pool integration is that you're required to backup the redeem script for your tickets of a given pool before at least one vote or revoke has been published for them, since it's possible (even though unlikely) that both the pool and your wallet are lost before that happens and you need to send a vote or revocation tx (which requires having access to the script).

This adds another bit of information that a conscientious user needs to back up besides their seed, and this is not very prominently advertised in our documentation and UI.

One general alternative discussed in chat is to use a separate branch of the bip32 wallet (possibly starting at a different purpose branch) to provide the source of data to share to the voting pool.

Some specific alternatives in that line are:

• Generate a single private key to send to a given pool (possibly using a pool specific index for key derivation)
• Generate an extended public key to send to a given pool (improving privacy by issuing tickets with different voting addresses)

Something along this lines has also been discussed as an alternative to backing up user's politeia identity: instead of having to back up another piece of data, have the keypair that identifies you in the politeia system come from a different branch of the wallet (either directly the secp256k1 keypair or a seed number to use for deriving the ed25519 that pi currently uses).

So it might be a good idea to consider an architectural change to provide a way to generate more general bip32 addresses/keys/data.

This obviously changes how many things are done in regards to voting pool integration and how the wallet handles the top level extended private keys. It has implications for usability (eg: requires reseeding before using the other branches) and security (handling of the new branches, hardening of sub-branches, etc), so it needs to be really thought out before being done (if at all).

[jrick]

I believe you meant providing an xpriv in the second case, as the pool will need it to vote. I think this is the better of the two solutions as it does significantly improve privacy by reducing transaction correlation.

[matheusd]

Right :)