View Issue Details

IDProjectCategoryView StatusLast Update
0003769Talerexchangepublic2015-06-21 12:22
ReporterSree Harsha Totakura Assigned ToChristian Grothoff  
PrioritynormalSeverityminorReproducibilityN/A
Status closedResolutionfixed 
Product Version0.0 
Target Version0.0Fixed in Version0.0 
Summary0003769: Coins should be spendable at multiple merchants
DescriptionIt 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.
TagsNo tags attached.

Activities

Christian Grothoff

2015-04-12 15:42

manager   ~0009072

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?

Christian Grothoff

2015-04-12 15:44

manager   ~0009073

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.

Sree Harsha Totakura

2015-04-12 16:34

updater   ~0009074

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).

Christian Grothoff

2015-04-12 22:26

manager   ~0009077

Ah, sure, I can see why using a 'primary key' restriction can create this kind of trouble.

Christian Grothoff

2015-06-19 11:24

manager   ~0009300

Removed primary key constraint in d39e4a1..5c2c2dd

Issue History

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