View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004116 | Taler | specification | public | 2015-12-29 09:43 | 2024-01-12 13:03 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 0.0 | ||||
| Target Version | 0.0 | ||||
| Summary | 0004116: there should be an API to request the status of coins | ||||
| Description | Something like /coin?coin_pub=XYZ should return the amount left on the coin, as well as a list of transactions. | ||||
| Tags | No tags attached. | ||||
| I'm less and less sure that we actually want this. (1) Having such an API means the mint can be DDoSed with legal requests, as we cannot charge for processing status requests, but do have to go through our DB. (2) If the wallet uses this API, we may get linkability. Usually a coin is used once or twice (spend, refresh), and both events are strictly correlated. Here, we may use a coin's key more times. And a wallet going through all of its coins requesting status allows the mint to correlate those coins (hey, they must all be from the same wallet!). We'd have to use the API very carefully (new Tor exit, random delays, etc.) and even then it would leak information. (3) It does make it slightly safer to 'share' coins with untrusted parties, as the receiver can check if the coin was already spent. Not having that ability is a good thing, as it makes it even less save to share coins with untrusted parties. (4) All this just to pre-emptively not run into troubles on payments after 'restore from backup', and even then we cannot guarantee that those troubles won't happen due to concurrency: the status can change anytime, so we cannot rely on the API anyway! (5) The API violates "Keep it simple"! So that's 5 reasons NOT to do this. | |
| As discussed here, on the mailing list, and offline, we have decided against this (mis-)feature. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-12-29 09:43 | Florian Dold | New Issue | |
| 2015-12-29 09:43 | Florian Dold | Status | new => assigned |
| 2015-12-29 09:43 | Florian Dold | Assigned To | => Christian Grothoff |
| 2016-01-05 17:12 | Christian Grothoff | Note Added: 0010048 | |
| 2016-01-05 17:12 | Christian Grothoff | Status | assigned => acknowledged |
| 2016-01-07 20:19 | Florian Dold | Note Added: 0010053 | |
| 2016-01-07 20:19 | Florian Dold | Status | acknowledged => informing |
| 2016-01-07 20:19 | Florian Dold | Resolution | open => no change required |
| 2016-01-07 20:31 | Christian Grothoff | Status | informing => closed |
| 2016-01-07 20:31 | Christian Grothoff | Product Version | => 0.0 |
| 2016-01-07 20:31 | Christian Grothoff | Target Version | => 0.0 |
| 2016-02-18 14:44 | Christian Grothoff | Category | mint API (HTTP specification) => exchange API (HTTP specification) |
| 2024-01-12 13:03 | Christian Grothoff | Category | exchange API (HTTP specification) => specification |