dcrwallet icon indicating copy to clipboard operation
dcrwallet copied to clipboard

VSP client unnecessarily loads all live tickets on wallet restart

Open jholdstock opened this issue 4 years ago • 2 comments

When I restart my testnet ticket buying wallet, it initializes the internal VSP client with every immature/live ticket. It then proceeds to call the VSPs /payfee endpoint for every ticket, receive an error response for each, then log fee is paid, removing from client. Restarting the wallet repeats this all over.

The wallet currently has ~200 tickets, so thats ~200 unnecessary web requests every time its restarted. As far as I can tell, they're happening one at a time and with a pause between them, which mean it takes a significant amount of time (minutes). As these are signed web requests, I guess the wallet/account remains unlocked for this whole period.

Aside from just being inefficient, this is bad for both privacy and security.

A couple of suggestions:

  • Using the /ticketinfo endpoint to check the ticket status is preferable to using the /payfee endpoint.
  • Once a tickets fee transaction is broadcast and confirmed, the wallet does not need to check on it again. Tickets with confirmed fee status should not be added to the VSP client on startup.

jholdstock avatar Jun 07 '21 09:06 jholdstock

I should add that I have observed this behaviour in 1.6.3 and have not tested the behaviour of master.

jholdstock avatar Jun 07 '21 09:06 jholdstock

I had something similar on v1.6.3. I was restarting dcrwallet with --vsp.sync and noticed scheduling "reconcile payment" for some tickets logged as "confirmed" previously, but not all (huh?). Then they get gradually re-confirmed after long (minutes) randomized waits, and this repeats again after another restart.

A related issue I noticed is inefficient polling. It starts scheduling confirm payment immediately after the ticket purchase, but then all polling for 6 next blocks is wasteful because the VSP only broadcasts te fee tx after the ticket gets 6 confirmations. Then same issue after the fee tx is broadcast: the VSP has successfully sent the fee tx for ... is spammed for 6 blocks until the VSP considers the fee as paid. I think the wallet could account for these two known 6-block intervals and poll only when it can really get new information, removing a bunch of unneeded traffic.

xaur avatar Sep 02 '21 18:09 xaur