search

decred / decrediton

Cross-platform GUI for Decred.
https://docs.decred.org/wallets/decrediton/decrediton-setup/
ISC License
195 stars 121 forks source link

Show additional status steps after ticket purchase #3010

Open matheusd opened 3 years ago

matheusd commented 3 years ago

Adding this as general dumping ground for improvements to the UX for the new accountless VSP mode. I don't think the following is doable for 1.6.0 and in any case we'll also get feedback from actual end users once 1.6.0 proper is released.

This is related to #2859

The new accountless vspd staking mode is much more complex and some state transitions aren't clearly communicated to the user.

Specifically, here are the steps for purchasing a ticket:

  1. Split tx is published
  2. Tickets are published
  3. Fee tx is sent to vsp (but not published locally)
  4. Split tx gets mined
  5. Ticket Tx gets mined
  6. Fee tx gets broadcast
  7. Fee tx gets mined

Steps 1-3 happen entirely inside the wallet, so any problems are reported as errors. Errors while attempting to pay the fee are clearly identified in Decrediton. So far so good.

However the next steps aren't immediately obvious to me (as an user): while I'm used to the transitions in steps 4 and 5, having a non-published tx (the fee tx) in the transaction list is pretty awkward: if I attempt to look for the tx in dcrdata, it fails to find info on it. Attempting to rebroadcast this tx also doesn't do anything. Copying the raw tx then rebroadcasting via dcrdata publishes the tx, but I have no idea whether this is picked up by the VSP.

Listing the fee status as "Fee Paid" is not entirely correct IMO: while it's true that the fee tx has been submitted to the VSP (if step 3 is fulfilled without errors), it's debatable whether the VSP fee is truly paid until the tx is actually broadcast and mined into a block, thus "binding" the corresponding VSP with the responsibility for voting a given ticket.

Additional issues (though I guess they have been touched upon in the chat before) is that there's currently no way to way to identify which VSPs a ticket has been directed to, nor to fetch a corresponding cryptographic assurance (signature, preimage or whatever) that a particular VSP has agreed to perform voting on the user's behalf or to select an additional VSP. Having a way to verify on the VSP whether it's watching a given ticket hash at any point in the future would also be helpful.

So, to try and sum up what I think can be improved upon to what we have now:

dre-tech commented 3 years ago

Great ideas above. I have a situation where two recently purchased new VSP tickets (bought at the same time) don't show up as live tickets in 'Ticket Status' only in 'History Tickets'. Would be great to have tools to figure out what didn't work out.

These tickets are marked as 'Solo' in 'History Tickets'. I would like to attach a VSP if possible, but can't find a way to do that without the ticket showing up in 'Ticket Status'.

cc @vctt94 since we were chatting about this in the Discord support the other day,

vctt94 commented 3 years ago

Is that because of restoring from seed?

dre-tech commented 3 years ago

I restored from seed to see if it would fix this issue. I'm currently running two instances of Decredition (1.6.0 rc4) restored from the same seed. Neither instance has these tickets listed in 'Ticket Status' even though the dcrdata website shows them as live. I tried to buy 2 more tickets the day after. I bought the next pair of tickets simultaneously as well. Same thing happened as far as the tickets never showing up in 'Ticket Status'. Now I have four tickets that don't show up in 'Ticket Status'. All four tickets are listed as live at dcrdata.