View Issue Details

IDProjectCategoryView StatusLast Update
0005114Talerdocumentationpublic2017-10-18 15:42
ReporterFlorian Dold Assigned ToChristian Grothoff  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.4Fixed in Version0.4 
Summary0005114: clarity semantics of "timetamp" field in deposit request
DescriptionIt'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
TagsNo tags attached.

Activities

Christian Grothoff

2017-07-20 09:05

manager   ~0012353

Time is messy ;-(.

The first answer should be "the request is rejected with error code X".

I do not understand your second question.

Christian Grothoff

2017-07-20 10:02

manager   ~0012355

Documented and implemented.

Florian Dold

2017-07-20 12:30

manager   ~0012358

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.

Christian Grothoff

2017-07-20 12:47

manager   ~0012359

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.

Issue History

Date Modified Username Field Change
2017-07-20 03:37 Florian Dold New Issue
2017-07-20 03:37 Florian Dold Status new => assigned
2017-07-20 03:37 Florian Dold Assigned To => Christian Grothoff
2017-07-20 09:05 Christian Grothoff Note Added: 0012353
2017-07-20 10:02 Christian Grothoff Status assigned => resolved
2017-07-20 10:02 Christian Grothoff Resolution open => fixed
2017-07-20 10:02 Christian Grothoff Fixed in Version => 0.4
2017-07-20 10:02 Christian Grothoff Note Added: 0012355
2017-07-20 10:02 Christian Grothoff Product Version => git (master)
2017-07-20 10:02 Christian Grothoff Target Version => 0.4
2017-07-20 12:30 Florian Dold Note Added: 0012358
2017-07-20 12:47 Christian Grothoff Note Added: 0012359
2017-10-18 15:42 Christian Grothoff Status resolved => closed