View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004526 | Taler | exchange | public | 2016-05-23 22:58 | 2018-04-15 18:34 |
| Reporter | Florian Dold | 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 | normal | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.0 | ||||
| Target Version | 0.5 | Fixed in Version | 0.5 | ||
| Summary | 0004526: unclear when reserve should be expired in the wallet | ||||
| Description | We currently have no notion of a reserve expiring, since we can always "top it up", and it's unclear what should happen when we don't deplete it and it expires. However, this means that the exchange has to store reserves forever. This is okay though, since the exchange already received money for this. It also means that the wallet needs to update the status of potentially ancient reserves, and consequently the wallet will get slower and slower over time. We either need to introduce the notion of a reserve expiring, or we need to have some heuristic when to stop updating them, for example after initial depletion (with further updates only when the wallet user requests it explicitly). | ||||
| Tags | No tags attached. | ||||
| related to | 0004956 | closed | Christian Grothoff | implement refunds on reserve expiration |
| related to | 0003485 | closed | Christian Grothoff | exchange garbage collection |
| related to | 0004751 | closed | Christian Grothoff | reserve balances and garbage collection of denomination keys |
| The real answer is that we need to turn this into a missing feature of the exchange: if a reserve is not depleted after say 1-3 months, we should auto-refund it by sending the money back. That way, the wallet can safely delete reserves after 3 months, and the exchange also doesn't have to keep them around forever. And customers can be assured that if something goes horribly wrong before they withdraw, they'll get the money back reasonably soon. | |
| There is some interaction with /payback now. How does the exchange handle this? We can of course still send money back after 1-3 months, but doesn't the exchange need to keep the reserve until all denominations at the last withdrawal time have expired? The same logic should be in the wallet. | |
| Sure, the exchange DB will keep the information around longer for auditing purposes, but I don't quite see why the wallet should care. To keep /reserve/status replies short and avoid accumulating excessive histories, the wallet probably ought to cycle reserve keys as often as possible, and for /payback the wallet doesn't really need to know the reserve public key either (unless you want to then immediately withdraw again). If the latter is what you are doing, then maybe keep the reserve priv around until you've spent the last coin withdrawn from that reserve. If the reserve is empty and all of its coins were spent, it is definitively safe for the wallet to forget that key. | |
| Agreed, so we might run into cases where the wallet has forgotten the reserve, but as you said in this case the user just as to wait to get the money back via via transfer. GC was implemented in the wallet in 6947e79b | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-05-23 22:58 | Florian Dold | New Issue | |
| 2016-05-24 18:43 | Christian Grothoff | Note Added: 0010734 | |
| 2016-05-24 18:43 | Christian Grothoff | Severity | minor => feature |
| 2016-05-24 18:43 | Christian Grothoff | Status | new => implementing |
| 2016-05-24 18:43 | Christian Grothoff | Category | other => exchange |
| 2016-05-24 18:43 | Christian Grothoff | Product Version | => 0.0 |
| 2016-05-24 18:43 | Christian Grothoff | Target Version | => 0.5 |
| 2016-05-24 18:44 | Christian Grothoff | Relationship added | related to 0003485 |
| 2017-03-19 09:38 | Christian Grothoff | Relationship added | related to 0004956 |
| 2017-03-19 09:42 | Christian Grothoff | Relationship added | related to 0004751 |
| 2017-11-04 17:49 | Christian Grothoff | Assigned To | => Florian Dold |
| 2017-11-04 17:49 | Christian Grothoff | Status | implementing => assigned |
| 2017-12-10 18:48 | Florian Dold | Note Added: 0012654 | |
| 2017-12-10 18:49 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2017-12-10 18:57 | Christian Grothoff | Note Added: 0012655 | |
| 2017-12-10 20:36 | Florian Dold | Note Added: 0012657 | |
| 2017-12-10 20:36 | Florian Dold | Status | assigned => informing |
| 2017-12-10 20:36 | Florian Dold | Resolution | open => fixed |
| 2017-12-14 14:39 | Christian Grothoff | Fixed in Version | => 0.5 |
| 2018-04-15 18:34 | Christian Grothoff | Status | informing => closed |