UI for manual ticket registration check

[matheusd]

Offer a UI element that would allow users to check whether a given ticket is registered with the VSP.

The goal is to allow users to verify on their own whether the ticket registration process worked without relying on Decrediton or other ticket buying wallets checking this via an API and would be useful for support requests.

[ukane-philemon]

@matheusd, what information should be shown to users using manual ticket search? Full information as shown to admin or information returned by the /ticketstatus endpoint?

[matheusd]

Depends on how the check is made. If this requires an online signature from the purchasing wallet, it seems safe (from a privacy perspective) to show all info also available to the wallet (selected vote choice, time, corresponding fee tx, etc).

OTOH, if this is a completely public check (i.e. pass the ticket hash and the vsp shows the data) then I'd expect only a resgistered/not-registered response (even this might be too much).

[jholdstock]

Allowing users to lookup a ticket by providing just the ticket hash is out of the question IMO. Users must prove ownership of the ticket.

Ticket ownership is proven by signing a message with the tickets commitment address, so an interface in the vspd website to lookup ticket information would be a pretty user-unfriendly experience - users would have to sign a message with their wallet, then copy the signature + the ticket hash into a form on the vspd site. I don't see any way to implement this in a more user-friendly way.

A better approach is for wallet software to call the ticket status endpoint and display the response for the user. That way, the complexity of signing the messages and proving ownership can be abstracted away from the user.

[ukane-philemon]

@jholdstock @matheusd thanks for your feedback.Decrediton/issues#3152 should be able to provide an easy way for tickets owners to sign a message and get a signature. While this involves several back and forth data copying, a ticket owner would be able to access full information on a ticket after ownership validation, it is a plus for validated owners to use the manual search because they would be able to access full information other than the regular ticket status reponse.

[itswisdomagain]

A better approach is for wallet software to call the ticket status endpoint and display the response for the user.

This can be done but shouldn't necessarily eliminate the need/use for such feature on vspd. A page of this nature on a vspd frontend would provide users with a way to independently verify ticket purchases with vspd. I'd definitely use that feature but maybe I'm paranoid? 😆

Quoting the OP:

The goal is to allow users to verify on their own whether the ticket registration process worked without relying on Decrediton or other ticket buying wallets checking this via an API

[jholdstock]

If we come up with some encoding format, the wallet could created a message something like this...

message := "I want to check vspd ticket status"
signature := wallet.SignMessage(ticket.CommitmentAddress, message)
encoded := ticket.Hash + signature

This will allow the feature to be implemented with only a single string to be copy/pasted by the user (encoded) .

The details of the encoding don't really matter so long as wallet software is able to encode and vspd is able to decode. We could even use something like JSON, but I think choosing something which results in a shorter encoded string would be preferred.

[matheusd]

If we come up with some encoding format, the wallet could created a message something like this...

Right. Decrediton would generate an opaque string with the necessary data and signature, so a single copy+paste into the vspd front end shows the result.

The main point is deciding what data to sign. Signing a fixed message as suggested opens up a possible replay attack vector (if somehow the same commitment address ends up being used - which isn't supposed to happen, but could). This also allows one vsp to check for the status of the ticket in other vsps.

A tighter suggestion would be:

blockWindow := currentBlockHeight / blocksPerDay
vspURL := "https://my-vspd.com"
ticketHash := ticket.Hash.String()
messageToSign := fmt.Sprintf("I want to check vspd ticket status for ticket %s at vsp %s on window %d", ticket, vspURL, blockWindow)
signature := wallet.SignMessage(ticket.CommitmentAddress, messageToSign)
encoded := ticketHash + signature
// ....

The vsp fills in its own domain and current block window (or previous one up to some time after it changes). This prevents replays across vsps, tickets and time.

[jholdstock]

I just took a look at the PR suggested by @ukane-philemon and I think we should actually use the VSPs pubic key as the identifier, rather than the URL.

Pubkey is a more dependable unique identifier for a VSP, it should never change. URLs are changeable, eg, at least one VSP offers an onion URL as well as its normal one. We have seen more than one VSP rebrand and change domain in the past.

messageToSign := fmt.Sprintf("I want to check vspd ticket status for ticket %s at vsp with pubkey %s on window %d", ticket, vspPubKey, blockWindow)