View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003814Talerexchangepublic2015-06-03 12:222024-01-12 13:05
ReporterChristian Grothoff Assigned ToChristian Grothoff Resolution deadline
ImplementerReviewer 
Release signed byDeployed by 
VerifierCommunicator 
Data protection authority notification requiredNo  
CSIRT notification requiredNo  
Estimated effort (hours)Actual effort (hours)0 
Fast-trackNo
Work packagenone
PriorityhighSeveritytweakReproducibilityN/A
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Versiongit (master) 
Target Version0.0Fixed in Version0.0 
Summary0003814: operate over all link secrets on block, removing oldcoin_index from refresh_commit_link
DescriptionWe currently always do N inserts and N select operations -- given N oldcoins -- when accessing the 'refresh_commit_link' table. We can avoid this if we store all link secrets in one big byte array (at the expense of copying them after each other and somehow parsing them apart afterwards), reducing the number of SQL queries and the number of entries in the table, at least in the case that multiple coins were melted.

However, if it is true that we commonly only melt one coin, then this might give us little to nothing.
TagsNo tags attached.

Required notifications

Address or linkRemarkAdded byNotifiedActions

Relationships

related to 0004483 closedChristian Grothoff Optimize refresh protocol with deterministic blinding 
child of 0004401 closedChristian Grothoff exchangedb refund, auditor and aggregator functions need testcase 

Activities

Christian Grothoff

2016-05-06 11:44

manager   ~0010653

Internal discussions suggest that we might want to instead simplify the protocol to not allow refreshing multiple oldcoins at once.

Jeff Burdges

2016-05-06 21:56

reporter   ~0010662

Is there really a scenario where we see n>1 old coins? Except for expiring denomination keys?

Christian Grothoff

2016-05-06 21:59

manager   ~0010663

It was a missfeature: we knew how to do m:n refresh, so we implemented that. But the paper only has 1:n and there is (AFAIK) no good reason for having m:n. (Expiring denom keys are the only safe use, and that's too rare to justify having it IMO).

Christian Grothoff

2016-05-16 09:58

manager   ~0010677

5d2b56c..60c7d0f removes multi-coin melt from exchange.
5fc5bd3..8a7ff86 removes multi-coin melt from API specification.

Issue History

Date ModifiedUsernameFieldChange
2015-06-03 12:22Christian GrothoffNew Issue
2015-06-11 14:31Christian GrothoffStatusnew => acknowledged
2015-06-11 14:31Christian GrothoffTarget Version => 0.2
2015-06-21 08:43Christian GrothoffTarget Version0.2 => 0.6
2015-06-21 08:43Christian GrothoffTarget Version0.6 => 0.5
2016-02-18 14:44Christian GrothoffCategorymint Postgres DB backend => exchange Postgres DB backend
2016-05-04 04:48Christian GrothoffAssigned To => Christian Grothoff
2016-05-04 04:48Christian GrothoffStatusacknowledged => assigned
2016-05-06 11:44Christian GrothoffNote Added: 0010653
2016-05-06 11:45Christian GrothoffRelationship addedrelated to 0004483
2016-05-06 11:52Christian GrothoffPrioritylow => high
2016-05-06 21:56Jeff BurdgesNote Added: 0010662
2016-05-06 21:59Christian GrothoffNote Added: 0010663
2016-05-08 14:10Christian GrothoffRelationship addedrelated to 0004401
2016-05-08 14:10Christian GrothoffRelationship replacedchild of 0004401
2016-05-08 14:10Christian GrothoffTarget Version0.5 => 0.3
2016-05-16 09:58Christian GrothoffNote Added: 0010677
2016-05-16 09:58Christian GrothoffStatusassigned => informing
2016-05-16 09:58Christian GrothoffFixed in Version => 0.0
2016-05-16 09:58Christian GrothoffResolutionopen => fixed
2016-05-16 09:59Christian GrothoffStatusinforming => closed
2016-05-16 09:59Christian GrothoffTarget Version0.3 => 0.0
2024-01-12 13:05Christian GrothoffCategoryexchange Postgres DB backend => exchange
Powered by locust
Contact administrator for assistance
User Documentation