View Issue Details

IDProjectCategoryView StatusLast Update
0004751Talerexchange Postgres DB backendpublic2017-10-18 15:42
ReporterChristian GrothoffAssigned ToChristian Grothoff 
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Version0.1 
Target Version0.4Fixed in Version0.4 
Summary0004751: reserve balances and garbage collection of denomination keys
DescriptionWhen 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?
TagsNo tags attached.

Relationships

related to 0003887 closedChristian Grothoff handle "emergency" where denomination key is overdrawn (/payback) 
related to 0004956 closedChristian Grothoff implement refunds on reserve expiration 
related to 0004526 closedChristian Grothoff unclear when reserve should be expired in the wallet 

Activities

Christian Grothoff

2017-03-19 10:41

manager   ~0011952

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.

Christian Grothoff

2017-03-19 10:43

manager   ~0011953

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?

Christian Grothoff

2017-07-14 19:31

manager   ~0012336

Fixed in Git master.

Issue History

Date Modified Username Field Change
2016-10-25 16:14 Christian Grothoff New Issue
2016-10-25 16:14 Christian Grothoff Status new => assigned
2016-10-25 16:14 Christian Grothoff Assigned To => Sree Harsha Totakura
2016-10-25 16:14 Christian Grothoff Assigned To Sree Harsha Totakura =>
2016-10-25 16:14 Christian Grothoff Status assigned => acknowledged
2017-03-19 10:40 Christian Grothoff Relationship added related to 0003887
2017-03-19 10:41 Christian Grothoff Note Added: 0011952
2017-03-19 10:41 Christian Grothoff Relationship added related to 0004956
2017-03-19 10:42 Christian Grothoff Relationship added related to 0004526
2017-03-19 10:43 Christian Grothoff Note Added: 0011953
2017-04-09 00:09 Christian Grothoff Assigned To => Christian Grothoff
2017-04-09 00:09 Christian Grothoff Status acknowledged => assigned
2017-07-14 19:31 Christian Grothoff Status assigned => resolved
2017-07-14 19:31 Christian Grothoff Resolution open => fixed
2017-07-14 19:31 Christian Grothoff Fixed in Version => 0.4
2017-07-14 19:31 Christian Grothoff Note Added: 0012336
2017-07-14 19:31 Christian Grothoff Target Version 0.5 => 0.4
2017-10-18 15:42 Christian Grothoff Status resolved => closed