View Issue Details

IDProjectCategoryView StatusLast Update
0008657Talerwallet-corepublic2024-04-15 21:32
ReporterMarcS Assigned ToChristian Grothoff  
Status closedResolutionfixed 
Product Version0.10 
Target Version0.10Fixed in Version0.10 
Summary0008657: Virgin wallet: After scanning a withdraw-exchange QR code, showing data to the user takes waayyyy too long
DescriptionMost probably because wallet-core downloads and evaluates ALL keys before it can return data to the UI.
Instead it should prioritize on the keys necessary for the withdrawal (current and next week) and compute/verify the other ones asynchonously in the background.
TagsNo tags attached.


related to 0008096 closedFlorian Dold improve wallet-core task scheduling 


Christian Grothoff

2024-03-22 10:14

manager   ~0021970

We should also split this: if taler://withdraw-exchange/ is scanned, we should ONLY do the JSON parsing (zero signature verification) before showing the user the dialog with the currency and allowing them to enter an amount (and start calculating fees).

While the user is interactive, we should *in the background* verify the signatures, with *priority* of the ones in the current withdraw period -- then into the future, and probably *never* the ones from the past.

Only after the user presses "confirm", we should wait until we have the *current* withdraw period keys verified, so we are sure that the withdraw would work right now, before showing the user the wire transfer details. But we should not require the full /keys verification with signatures over the next 2 years to have completed, that can continue in the background.

If signatures are invalid for future keys, we should asynchronously show a warning, like we would (need to) do when /keys fails for a refresh or other background operation where we updated /keys and things failed unrelated to an ongoing user interaction.

Florian Dold

2024-03-26 13:11

manager   ~0021997

Can you still reproduce this with the latest wallet-core?

We now only validate signatures that we actually might need. I've also optimized some slow DB queries.


2024-04-08 16:37

developer   ~0022155

I never saw this issue myself - I opened the bug because Christian told me his students were having this problem.
Thus he needs to check at BFH whether this issue still occurs with 0.9.7 / 0.10.

Christian Grothoff

2024-04-09 19:40

manager   ~0022179

fixed. now super-fast!

Issue History

Date Modified Username Field Change
2024-03-22 10:00 MarcS New Issue
2024-03-22 10:00 MarcS Status new => assigned
2024-03-22 10:00 MarcS Assigned To => Christian Grothoff
2024-03-22 10:14 Christian Grothoff Note Added: 0021970
2024-03-22 10:14 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2024-03-23 13:06 MarcS Relationship added related to 0008096
2024-03-26 13:11 Florian Dold Assigned To Florian Dold => MarcS
2024-03-26 13:11 Florian Dold Status assigned => feedback
2024-03-26 13:11 Florian Dold Note Added: 0021997
2024-04-08 16:37 MarcS Note Added: 0022155
2024-04-08 16:37 MarcS Assigned To MarcS => Christian Grothoff
2024-04-09 19:40 Christian Grothoff Status feedback => resolved
2024-04-09 19:40 Christian Grothoff Resolution open => fixed
2024-04-09 19:40 Christian Grothoff Fixed in Version => 0.10
2024-04-09 19:40 Christian Grothoff Note Added: 0022179
2024-04-15 21:32 Christian Grothoff Status resolved => closed