View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005114 | Taler | documentation | public | 2017-07-20 01:37 | 2017-10-18 13:42 |
| 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 | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.4 | Fixed in Version | 0.4 | ||
| Summary | 0005114: clarity semantics of "timetamp" field in deposit request | ||||
| Description | It's not clear from the documentation [1] how the "timestamp" field of the deposit request is interpreted by the exchange. In particular: - what happens if a value is provided is too far in the past / in the future - what happens if the timestamp matches the coin_sig but different DepositRequests for the same h_proposal_data have the same h_contract_terms? [1] https://docs.taler.net/api/api-exchange.html#deposit | ||||
| Tags | No tags attached. | ||||
| Time is messy ;-(. The first answer should be "the request is rejected with error code X". I do not understand your second question. | |
| Documented and implemented. | |
| Clarifying the second question: The documentation for "timestamp" says "timestamp when the contract was finalized". Of course the exchange can't verify that the timestamp in the proposal data matches. The only thing it could verify is that for one transaction, every coin has the same timestamp. But I assume it doesn't do that, and I also don't see why it should. | |
| Ah, I see. The idea of the timestamp is that it should allow the *state* to reasonably establish when the contract was executed for tax purposes. So the exchange merely checks that it is plausible, right now I put in +/- 1 month (!). So the tolerance is very high, as the goal is just to prevent a business operation from 2017 to be backdated to 2010. And yes, the exchange cannot check that it is the precise date, and this is not expected. It also does not check across coins. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-07-20 01:37 | Florian Dold | New Issue | |
| 2017-07-20 01:37 | Florian Dold | Status | new => assigned |
| 2017-07-20 01:37 | Florian Dold | Assigned To | => Christian Grothoff |
| 2017-07-20 07:05 | Christian Grothoff | Note Added: 0012353 | |
| 2017-07-20 08:02 | Christian Grothoff | Status | assigned => informing |
| 2017-07-20 08:02 | Christian Grothoff | Resolution | open => fixed |
| 2017-07-20 08:02 | Christian Grothoff | Fixed in Version | => 0.4 |
| 2017-07-20 08:02 | Christian Grothoff | Note Added: 0012355 | |
| 2017-07-20 08:02 | Christian Grothoff | Product Version | => git (master) |
| 2017-07-20 08:02 | Christian Grothoff | Target Version | => 0.4 |
| 2017-07-20 10:30 | Florian Dold | Note Added: 0012358 | |
| 2017-07-20 10:47 | Christian Grothoff | Note Added: 0012359 | |
| 2017-10-18 13:42 | Christian Grothoff | Status | informing => closed |