View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003814 | Taler | exchange | public | 2015-06-03 14:22 | 2024-01-12 14:05 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | tweak | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.0 | Fixed in Version | 0.0 | ||
| Summary | 0003814: operate over all link secrets on block, removing oldcoin_index from refresh_commit_link | ||||
| Description | We 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. | ||||
| Tags | No tags attached. | ||||
| related to | 0004483 | closed | Christian Grothoff | Optimize refresh protocol with deterministic blinding |
| child of | 0004401 | closed | Christian Grothoff | exchangedb refund, auditor and aggregator functions need testcase |
|
|
Internal discussions suggest that we might want to instead simplify the protocol to not allow refreshing multiple oldcoins at once. |
|
|
Is there really a scenario where we see n>1 old coins? Except for expiring denomination keys? |
|
|
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). |
|
|
5d2b56c..60c7d0f removes multi-coin melt from exchange. 5fc5bd3..8a7ff86 removes multi-coin melt from API specification. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-06-03 14:22 | Christian Grothoff | New Issue | |
| 2015-06-11 16:31 | Christian Grothoff | Status | new => acknowledged |
| 2015-06-11 16:31 | Christian Grothoff | Target Version | => 0.2 |
| 2015-06-21 10:43 | Christian Grothoff | Target Version | 0.2 => 0.6 |
| 2015-06-21 10:43 | Christian Grothoff | Target Version | 0.6 => 0.5 |
| 2016-02-18 15:44 | Christian Grothoff | Category | mint Postgres DB backend => exchange Postgres DB backend |
| 2016-05-04 06:48 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2016-05-04 06:48 | Christian Grothoff | Status | acknowledged => assigned |
| 2016-05-06 13:44 | Christian Grothoff | Note Added: 0010653 | |
| 2016-05-06 13:45 | Christian Grothoff | Relationship added | related to 0004483 |
| 2016-05-06 13:52 | Christian Grothoff | Priority | low => high |
| 2016-05-06 23:56 | Jeff Burdges | Note Added: 0010662 | |
| 2016-05-06 23:59 | Christian Grothoff | Note Added: 0010663 | |
| 2016-05-08 16:10 | Christian Grothoff | Relationship added | related to 0004401 |
| 2016-05-08 16:10 | Christian Grothoff | Relationship replaced | child of 0004401 |
| 2016-05-08 16:10 | Christian Grothoff | Target Version | 0.5 => 0.3 |
| 2016-05-16 11:58 | Christian Grothoff | Note Added: 0010677 | |
| 2016-05-16 11:58 | Christian Grothoff | Status | assigned => resolved |
| 2016-05-16 11:58 | Christian Grothoff | Fixed in Version | => 0.0 |
| 2016-05-16 11:58 | Christian Grothoff | Resolution | open => fixed |
| 2016-05-16 11:59 | Christian Grothoff | Status | resolved => closed |
| 2016-05-16 11:59 | Christian Grothoff | Target Version | 0.3 => 0.0 |
| 2024-01-12 14:05 | Christian Grothoff | Category | exchange Postgres DB backend => exchange |
