UI for manual ticket registration check #227

Activity

1. ukane-philemon commented on Jan 21, 2022

   

   ukane-philemon

   on Jan 21, 2022

   Contributor

   More actions

   @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?
2. matheusd commented on Jan 24, 2022

   

   matheusd

   on Jan 24, 2022

   MemberAuthor

   More actions

   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).
3. jholdstock commented on Jan 24, 2022

   

   jholdstock

   on Jan 24, 2022

   Member

   More actions

   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.
4. ukane-philemon commented on Jan 25, 2022

   

   ukane-philemon

   on Jan 25, 2022

   Contributor

   More actions

   @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.
5. itswisdomagain commented on Jan 25, 2022

   

   itswisdomagain

   on Jan 25, 2022

   Member

   More actions

   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
6. jholdstock commented on Jan 25, 2022

   

   jholdstock

   on Jan 25, 2022

   Member

   More actions

   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.
7. matheusd commented on Jan 25, 2022

   

   matheusd

   on Jan 25, 2022

   MemberAuthor

   More actions

   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.

   👍React with 👍2Reacted by Wisdom Arerosuoghene and Jamie Holdstock
8. jholdstock commented on Mar 15, 2022

   

   jholdstock

   on Mar 15, 2022

   Member

   More actions

   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)
   
   

   👍React with 👍1Reacted by Ukane Philemon Emumena