Transition from account-based to ticket-based system

[itswisdomagain]

The fix(es) proposed below in this issue are already implemented in #514 and #516.
This issue notes the problems/limitations observed with the current VSP account-based system and explains the rationale and logic applied in the PRs mentioned above to fix the identified issues.

Current account-based system

In order to use VSP services, users are currently required to signup on the VSP site using an email address and password. The first time a user logs in after verifying their email address, an API Token is generated for the user's account.

Purchasing tickets

Before users can purchase tickets with VSP-shared voting rights, they need to first link their wallet to their VSP account. To do this, they need to generate a pubkeyaddr from their wallet and

• login on the VSP frontend to submit the generated pubkeyaddr on the /address page
  or
• call the /api/v2/address POST endpoint, passing the generated pubkeyaddr and the API Token tied to their account.

The pubkeyaddr submitted by the user is paired with a second pubkeyaddr generated from the VSP's voting wallet to produce a 1-of-2 multisig address. This multisig address is saved to the user's account and use for all subsequent ticket purchases.

Setting voting preferences

Voting preferences are set on a user-level and applies to all tickets purchased by the user using the multisig address generated above. Users updates their voting preferences by either

• visiting the /voting page after logging in to the VSP site
  or
• calling the /api/v2/voting POST endpoint, passing the API Token tied to their account.

Problems with the current system

#274 does a pretty good job of highlighting the problems with the current system, including:

• "Email is obsolete, legacy, ancient, anti-privacy comm system".
• Because of multisig address reuse, multiple tickets can be linked to a user.

Proposed solution

The desired solution is to make email optional, allowing users to be able to use VSP services without using an email address to create an account on the VSP site.

It's also important to reduce tickets-user correlation by generating and using different voting/ticket addresses for ticket purchases. Transitioning away from a user-accounts-based system makes it possible to generate different multisig voting addresses per ticket - as there would no longer be the concept of user accounts having just one associated multisigs. Instead, there'd be different tickets associated with different multisigs.

Improving privacy by reducing/eliminating the possibility of tickets-user correlation is also discussed in decred/dcrwallet#1613 where it is proposed to use p2pkh voting addresses instead of multisig addresses. When that feature is implemented, instead of sharing address pubkeys with VSPs to create multisigs, users would derive p2pkh voting addresses off some path in their HD wallets and share individual address private keys with VSPs to enable VSPs vote on their tickets.

In order to render email optional and enable users to purchase multiple tickets with different voting addresses, the following changes are proposed to be made to VSP features that currently require user authentication and authorization. In summary, it is proposed that one such feature (the ticket address generating feature for purchasing tickets) be made open while other protected features use a ticket-level authentication and authorization.

1. Tickets purchase

In order to boost privacy and user experience, it is proposed to allow users purchase tickets with VSP-shared voting rights, without having to register or login.

It is proposed to make the /address web page and the /api/v2/address endpoint publicly open, to enable users submit a pubkeyaddr from their wallet which the VSP will then use to generate a 1-of-2 multisig for users to use when purchasing tickets.

This also helps to prevent/reduce tickets-user correlation, as users can then purchase multiple tickets from the same wallet using different multisig addresses.

This is already partly done in #515. In order to maintain backwards compatibility, #515 adds a new /purchaseticket API endpoint that behaves very similarly to the /api/v2/address endpoint. The key (perhaps only) difference between both endpoints is that, the new /purchaseticket endpoint treats each request as a new "user" and generates a new multisig address which is returned to the caller. The exception to this is when a user calls the endpoint with the a previously submitted pubkeyaddr.

2. Setting voting preferences and performing other ticket-related operations that require authentication and authorization.

#514 introduces a new authentication middleware for API requests that requires users to provide proof that they own a ticket before they can set voting preferences for the ticket or perform other protected operation on the ticket.

Tickets purchased with VSP-shared voting rights have 2 sstxcommitment outputs for receiving staking reward. One of these addresses belongs to the VSP wallet, while the other belongs to the ticket owner's wallet. We'll call this second address the UserRewardAddress. It is believed that only the ticket owner has the private key for this address.

In order to prove ownership of a ticket, a user is required to sign a message using the private key for the UserRewardAddress. The message that was signed, along with the resulting signature and the ticket hash is sent in the Authorization header for all API requests to protected resources/endpoints. The message to be signed is expected to be the unix timestamp at the time of request.

On receiving the request, the new authentication middleware carries out the authentication+authorization process in the following steps:

• extracts the ticket hash, timestamp and message signature from the Authorization header
• checks that the signature has not been used before to forestall replay attacks
• checks that the timestamp is valid and recent (not more than 60 seconds into the past or future)
• retrieves the UserRewardAddress from dcrwallet using the ticket hash
• verifies the signature using the timestamp sent in the header and the UserRewardAddress gotten above
• allows access to the requested endpoint if all the above checks out.

This new authentication middleware is also backwards compatible, allowing users to set voting preferences for their VSP account by proving ownership to any of the tickets they purchased with the multisig address given to them by the VSP.

[JoeGruffins]

I've made a couple issues in Tiny Decred
decred/tinydecred#16
decred/tinydecred#17
That should lead to prs that should lead to easy testing of these changes. Bear with me, this shouldn't take too long to get going.

[xaur]

Links to 514 and 515 at the beginning are broken (change pulls to pull).

[xaur]

In order to prove ownership of a ticket, a user is required to sign a message using the private key for the UserRewardAddress

(1) Are there any security implications of using that key, e.g. revealing it weakens security from quantum attacks? Is it a big deal?

It is proposed to make the /address web page and the /api/v2/address endpoint publicly open

(2) How spam protection will be done? (now that there is no captcha-protected web login)

(3) Will it be possible to start staking with a VSP without ever opening the browser or Decrediton? Will there be a program (or a patch to dcrwallet?) to buy VSP tickets and set voting prefs in command line?

(4) How do you see the transition path from account-based to accountless tickets? Are there (or could there) be any features to 1) smoothen and 2) stimulate the transition?

[jrick]

I take it that it wasn't a goal to begin paying the fees out-of-band yet. As proposed, this change would still enable coinshuffle++ ticket buying for vsp users, however vsp users would be in a separate anonymity set for all coinjoin ticket purchases from solo buyers due to the different amounts.

Since the fees will be fairly small amounts, and we may want to use LN for this, I think it makes sense to continue with this design since mixed ticket buying, even when in a separate anonymity set, is better than none at all.

[jrick]

On second thought, we could just solve this and the anonymity set problem at the same time and remove the VSP fees from the tickets. VSPs would receive out-of-band payment for voting after the ticket is immature. I'm not seeing a reason we need to block on LN for this.

While the VSP can't necessarily force this, for privacy setups, it makes the most sense to pay these fees out of a mixed account. Care needs to be taken in the wallet code so that a utxo is reserved for paying this fee, because if it were to be double spent by the mixed split tx, and no other utxo is suitable, the VSP fee would be unpayable.

[itswisdomagain]

Closed in favour of #574