View Issue Details

IDProjectCategoryView StatusLast Update
0004379Talerwallet (WebExtensions)public2017-10-23 10:48
ReporterFlorian DoldAssigned ToFlorian Dold 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status assignedResolutionopen 
Product Version0.0 
Target Version0.9Fixed in Version 
Summary0004379: error handling: exportable proof for e.g. double spending
DescriptionWhen payments fail and it is not a transient error, the wallet needs to provide the user with a way to extract the information regarding the claim the merchant made.
TagsNo tags attached.

Activities

Florian Dold

2016-11-03 20:21

manager   ~0011423

Not clear how this should look UI-wise, and I'm also not sure what's the best way to test this.

For the UI: We could open an in-extension tab that shows a message and a way to save the proof. Should it show up anywhere in the wallet popup, or just in the history?

Does this error page provide the user with the option to refresh coins that are not double-spended? Does this happen automatically (probably makes most sense)?

Should we have some informal spec that documents these cases before we start implementing?

Florian Dold

2016-11-08 15:01

manager   ~0011451

Moved to 0.3 since we should have at least the facilities to trigger the various error paths (wallet really double-spended / merchant falsely claimed double spending).

Christian Grothoff

2016-11-08 16:11

manager   ~0011452

Eh, that would be 0.5. That's when the error path triggering is on the roadmap.

Christian Grothoff

2016-11-08 16:11

manager   ~0011453

Wrong again. 0.6.

Christian Grothoff

2017-03-19 00:06

manager   ~0011945

In terms of specification, I basically expect that for each possible proof we export a JSON file with:

* always top-level: some numeric information about the type of proof
* always top-level: some human-readable information about the type of proof

Then, type-specific key-value pairs where:

key: some string describing the value
value: some json object (or array) with structured proof data, i.e. public keys, amounts, signatures, hashes, etc., depending on what the proof is about.


We should also have some command-line tool to verify proofs, i.e. I would run:

taler-check-proof FILENAME.json

and it would:
1) open file, parse the json (make sure JSON was valid)
2) look at the type, use it to load some plugin to verify the proof and
3) output the result of the check ("valid" / "invalid")

We need to have an additional options "--extract-contract" that could be used to extract the JSON contract from the overall proof (if present), so that one can use the (generic) contract renderer (which we need to have a standalone-version of) to show the contract. I think that's about it for the overall design, the individual JSON field members for each proof should probably just be speced as the export-logic and proof-validation plugin are implemented.

Issue History

Date Modified Username Field Change
2016-04-06 23:34 Florian Dold New Issue
2016-04-06 23:34 Florian Dold Status new => assigned
2016-04-06 23:34 Florian Dold Assigned To => Florian Dold
2016-04-07 00:56 Christian Grothoff Product Version => 0.0
2016-04-07 00:56 Christian Grothoff Target Version => 0.1
2016-04-07 15:00 Florian Dold Relationship added child of 0003800
2016-04-08 00:06 Christian Grothoff Severity minor => feature
2016-04-08 00:11 Christian Grothoff Target Version 0.1 => 0.2
2016-11-03 20:21 Florian Dold Note Added: 0011423
2016-11-03 21:51 Florian Dold Status assigned => feedback
2016-11-08 15:01 Florian Dold Note Added: 0011451
2016-11-08 15:01 Florian Dold Target Version 0.2 => 0.3
2016-11-08 16:11 Christian Grothoff Target Version 0.3 => 0.5
2016-11-08 16:11 Christian Grothoff Note Added: 0011452
2016-11-08 16:11 Christian Grothoff Target Version 0.5 => 0.6
2016-11-08 16:11 Christian Grothoff Note Added: 0011453
2016-11-08 16:12 Christian Grothoff Relationship added parent of 0004454
2017-03-19 00:06 Christian Grothoff Note Added: 0011945
2017-03-19 00:06 Christian Grothoff Status feedback => assigned
2017-03-20 11:42 Christian Grothoff Target Version 0.6 => 0.9
2017-10-23 10:48 Christian Grothoff Relationship deleted child of 0003800
2018-03-27 17:31 Christian Grothoff Relationship deleted parent of 0004454