You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Request: GetTicketsStatus with an option for number to return (100 or something being default).
Response: List of tickets' statuses for each ticket 'owned' by the wallet (possibly in imported or base accounts). Short list of information that each status would contain: ticket price, current status (voted, expired, revoked...), ticket age if still pending, net gain/loss, txids votes/revokes, votechoices if applicable, and possibly a few more as we flush it out.
With this we should be able to construct a pretty clear picture to users about their staking information.
This call will be very similar to getstakeinfo, but will actually flush out values instead of mere total tabulation.
Obviously this could end up being extremely intensive for wallet/daemon, but with possible optimization (decred/dcrd#681) it shouldn't be too demanding. In the case of grpc would could also stream results to avoid too much strain at once.
The text was updated successfully, but these errors were encountered:
stakepool needs something like this too. We currently depend on the stakepooluserinfo RPC which is indexed/fast but it has bugs and it would be nice to remove that in favor of a more generic RPC that could be used both by the wallet and by the stakepool.
There's also a ticketsforaddress RPC that can be removed too. That was the predecessor to stakepooluserinfo.
This could be added to both rpc-json and grpc.
Request: GetTicketsStatus with an option for number to return (100 or something being default).
Response: List of tickets' statuses for each ticket 'owned' by the wallet (possibly in imported or base accounts). Short list of information that each status would contain: ticket price, current status (voted, expired, revoked...), ticket age if still pending, net gain/loss, txids votes/revokes, votechoices if applicable, and possibly a few more as we flush it out.
With this we should be able to construct a pretty clear picture to users about their staking information.
This call will be very similar to getstakeinfo, but will actually flush out values instead of mere total tabulation.
Obviously this could end up being extremely intensive for wallet/daemon, but with possible optimization (decred/dcrd#681) it shouldn't be too demanding. In the case of grpc would could also stream results to avoid too much strain at once.
The text was updated successfully, but these errors were encountered: