View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004751 | Taler | exchange | public | 2016-10-25 14:14 | 2024-01-12 13:05 |
| Reporter | Christian Grothoff | 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 | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | 0.1 | ||||
| Target Version | 0.4 | Fixed in Version | 0.4 | ||
| Summary | 0004751: reserve balances and garbage collection of denomination keys | ||||
| Description | When withdrawing from the reserve, we calculate its current balance by totaling up the existing withdrawals. However, those are tied to the respecive denomination key. So if a DK is GCed, and the reserve for which withdrawals with this DK was made still exists, then that reserve will suddenly again have money in it! (As we forget about the withdrawals!). So we either need constraints (reserve lifetime << DK expirations; DK GC only if all reserves have expired), which are awful, or we need a way to "abbreviate" reserve histories to drop ancient transactions and replace those by a summary (also ugly, as it violates the notion that all DBs are 'append-only'). Maybe fast reserve expiration is the best answer? | ||||
| Tags | No tags attached. | ||||
| related to | 0003887 | closed | Christian Grothoff | handle "emergency" where denomination key is overdrawn (/payback) |
| related to | 0004956 | closed | Christian Grothoff | implement refunds on reserve expiration |
| related to | 0004526 | closed | Christian Grothoff | unclear when reserve should be expired in the wallet |
| We also need to keep reserve data (including account info about how the reserve was initially funded) for 0003887. This imposes further constraints on when reserve information can be GC'ed. | |
| 0004526 is also interesting, as it relates to possible policies for the wallet creating "new" reserves. We'd not want the wallet to create too many reserves if we keep expensive state for them. OTOH, 0003887 requires that a change in bank account definitively means a new reserve is created. Maybe we can HKDF reserve private keys from a master secret and the bank details? | |
| Fixed in Git master. | |
| Fix committed to master branch. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-10-25 14:14 | Christian Grothoff | New Issue | |
| 2016-10-25 14:14 | Christian Grothoff | Status | new => assigned |
| 2016-10-25 14:14 | Christian Grothoff | Assigned To | => Sree Harsha Totakura |
| 2016-10-25 14:14 | Christian Grothoff | Assigned To | Sree Harsha Totakura => |
| 2016-10-25 14:14 | Christian Grothoff | Status | assigned => acknowledged |
| 2017-03-19 09:40 | Christian Grothoff | Relationship added | related to 0003887 |
| 2017-03-19 09:41 | Christian Grothoff | Note Added: 0011952 | |
| 2017-03-19 09:41 | Christian Grothoff | Relationship added | related to 0004956 |
| 2017-03-19 09:42 | Christian Grothoff | Relationship added | related to 0004526 |
| 2017-03-19 09:43 | Christian Grothoff | Note Added: 0011953 | |
| 2017-04-08 22:09 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2017-04-08 22:09 | Christian Grothoff | Status | acknowledged => assigned |
| 2017-07-14 17:31 | Christian Grothoff | Status | assigned => informing |
| 2017-07-14 17:31 | Christian Grothoff | Resolution | open => fixed |
| 2017-07-14 17:31 | Christian Grothoff | Fixed in Version | => 0.4 |
| 2017-07-14 17:31 | Christian Grothoff | Note Added: 0012336 | |
| 2017-07-14 17:31 | Christian Grothoff | Target Version | 0.5 => 0.4 |
| 2017-10-18 13:42 | Christian Grothoff | Status | informing => closed |
| 2021-09-02 16:13 | Christian Grothoff | ||
| 2021-09-02 16:14 | Christian Grothoff | Note Added: 0018293 | |
| 2024-01-12 13:05 | Christian Grothoff | Category | exchange Postgres DB backend => exchange |