View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008657 | Taler | wallet-core | public | 2024-03-22 09:00 | 2024-04-15 19:32 |
| Reporter | MarcS | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.10 | ||||
| Target Version | 0.10 | Fixed in Version | 0.10 | ||
| Summary | 0008657: Virgin wallet: After scanning a withdraw-exchange QR code, showing data to the user takes waayyyy too long | ||||
| Description | Most 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. | ||||
| Tags | No tags attached. | ||||
| related to | 0008096 | closed | Florian Dold | improve wallet-core task scheduling |
| 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. | |
| 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. | |
| 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. | |
| fixed. now super-fast! | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-03-22 09:00 | MarcS | New Issue | |
| 2024-03-22 09:00 | MarcS | Status | new => assigned |
| 2024-03-22 09:00 | MarcS | Assigned To | => Christian Grothoff |
| 2024-03-22 09:14 | Christian Grothoff | Note Added: 0021970 | |
| 2024-03-22 09:14 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-03-23 12:06 | MarcS | Relationship added | related to 0008096 |
| 2024-03-26 12:11 | Florian Dold | Assigned To | Florian Dold => MarcS |
| 2024-03-26 12:11 | Florian Dold | Status | assigned => feedback |
| 2024-03-26 12:11 | Florian Dold | Note Added: 0021997 | |
| 2024-04-08 14:37 | MarcS | Note Added: 0022155 | |
| 2024-04-08 14:37 | MarcS | Assigned To | MarcS => Christian Grothoff |
| 2024-04-09 17:40 | Christian Grothoff | Status | feedback => informing |
| 2024-04-09 17:40 | Christian Grothoff | Resolution | open => fixed |
| 2024-04-09 17:40 | Christian Grothoff | Fixed in Version | => 0.10 |
| 2024-04-09 17:40 | Christian Grothoff | Note Added: 0022179 | |
| 2024-04-15 19:32 | Christian Grothoff | Status | informing => closed |