View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003769 | Taler | exchange | public | 2015-04-12 11:05 | 2015-06-21 12:22 |
| Reporter | Sree Harsha Totakura | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.0 | ||||
| Target Version | 0.0 | Fixed in Version | 0.0 | ||
| Summary | 0003769: Coins should be spendable at multiple merchants | ||||
| Description | It is unclear as of now if a coin can be spent multiple times at different merchants. The current DB schema does not allow this. Earlier, we decided that the coin should be made spendable multiple times at the same merchant as spending the same coin at multiple merchants gives an opportunity for the mint to profile the spender. However, this cannot be supported with the current schema. | ||||
| Tags | No tags attached. | ||||
|
|
I assume this is because of the public key for /refunds? Otherwise there isn't even any real information about the merchant stored with the coin! And yes, while it lowers privacy, I think it should be OK to spend (fractions of) the same coin at different merchants, especially as /refresh may (eventually) come at some expense. While we probably won't do this initially, I don't quite see what you did to the DB schemata to even prohibit this (but I didn't look at it). Did you over-normalize by having a 'merchant' table? (Note that even the same merchant may use many public keys!). I had envisioned that during /deposit, we would simply add a new row with the amount, coin pub, merchant pub, etc. to a table. No problem with having the same coin pub and a different merchant pub again at a later point in the same table. Also note that the `struct TALER_MINDB_TransactionList` also naturally supports having many different merchant-pubs within the same coin transaction history. So what exactly is the trouble? |
|
|
Maybe relevant: Overall, we should for the DB pursue an "append-only" database strategy: virtually all operations should only INSERT a new row into one or more tables (or SELECT). Only the "garbage collector" that deletes (ancient, useless, obsolete) entries should do DELETES. Ideally, there should be no UPDATE. |
|
|
There is no big trouble; the current DB schema has a primary key over coin_pub which can be (trivially) changed to (coin_pub, merchant_pub, transaction_id). |
|
|
Ah, sure, I can see why using a 'primary key' restriction can create this kind of trouble. |
|
|
Removed primary key constraint in d39e4a1..5c2c2dd |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-04-12 11:05 | Sree Harsha Totakura | New Issue | |
| 2015-04-12 11:05 | Sree Harsha Totakura | Status | new => assigned |
| 2015-04-12 11:05 | Sree Harsha Totakura | Assigned To | => Sree Harsha Totakura |
| 2015-04-12 15:42 | Christian Grothoff | Note Added: 0009072 | |
| 2015-04-12 15:42 | Christian Grothoff | Summary | Should coins be made spendable at multiple merchants? => Coins should be spendable at multiple merchants |
| 2015-04-12 15:44 | Christian Grothoff | Note Added: 0009073 | |
| 2015-04-12 15:44 | Christian Grothoff | Product Version | => 0.0 |
| 2015-04-12 15:44 | Christian Grothoff | Target Version | => 0.0 |
| 2015-04-12 16:34 | Sree Harsha Totakura | Note Added: 0009074 | |
| 2015-04-12 22:26 | Christian Grothoff | Note Added: 0009077 | |
| 2015-04-12 23:48 | Christian Grothoff | Category | mint API => mint |
| 2015-06-19 11:24 | Christian Grothoff | Assigned To | Sree Harsha Totakura => Christian Grothoff |
| 2015-06-19 11:24 | Christian Grothoff | Note Added: 0009300 | |
| 2015-06-19 11:24 | Christian Grothoff | Status | assigned => resolved |
| 2015-06-19 11:24 | Christian Grothoff | Fixed in Version | => 0.0 |
| 2015-06-19 11:24 | Christian Grothoff | Resolution | open => fixed |
| 2015-06-21 12:22 | Christian Grothoff | Status | resolved => closed |
| 2016-02-18 15:43 | Christian Grothoff | Category | mint => exchange |
