View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005777||Taler||wallet (WebExtensions)||public||2019-06-26 16:11||2020-03-17 12:13|
|Reporter||Florian Dold||Assigned To||Florian Dold|
|Priority||high||Severity||minor||Reproducibility||have not tried|
|Product Version||git (master)|
|Target Version||0.7.1||Fixed in Version|
|Summary||0005777: allow recovering refreshed and partially spent coins|
|Description||We distinguish three cases:|
1. The coins is freshly withdrawn from a reserve. For that, we use the existing /payback API.
2. The coin has been partially spent. In this case, when the coin is revoked, the wallet refreshes it into a non-revoked denomination. However, the exchange currently does not allow this!
3. The coin is fresh, but was obtained via refreshing. For this case, we need a new /refresh/payback API. This API "reverses" a refresh, and credits the old coin. To prove that the revoked coin came from a refresh, the customer reveals the gamma-th transfer secret, which allows the exchange to verify the the new coin was derived from the old coin.
|Additional Information||Steps to do:|
1) Track number of coins redeemed and number of coins issued, not total value redeemed/total value issued.
2) Enable refresh on revoked denominations IF the coin was seen before the revocation. Refresh should also be enabled for "zombie" coins that regained value from (3) even if the denomination is past deposit-expiration (but not if the denomination is legal-expired).
3) Specify /refresh/payback API, including additional entry type in (old) coin history! Here, the transfer private key would be disclosed, giving value back to the old coin (similar to refund) and setting the "zombie" flag re-enabling refresh (2) even if the denomination itself is post deposit-expiration.
4) Implement /refresh/payback API
5) Test /refresh/payback API
|Tags||No tags attached.|
In step (3) we can't actually reveal the transfer private key, as this breaks unlinkability for the other outputs of the refresh operation.
Instead, we reveal the blinding factor r and new coin's public key C_p. The exchange then checks if the blinded signature stored in the exchange database matches r and C_p.
(1) is actually already implemented (somewhat inefficiently...) by the auditor (see report_emergency_by_count()).
I've added some #ifdef OPTIMIZE_5777_AUDITOR_BY_COUNT_REALTIME_DETECTION to show where we might want to modify data structures in the exchange to enable more (and efficient) "real-time" detection, but that's a performance optimization which is not crucial to 0005777 itself (and there are plenty of other auditor-related optimizations to do first before this one becomes even relevant). So we can skip (1) for now.
[Update: removed the #ifdef OPTIMIZE_5777_AUDITOR_BY_COUNT_REALTIME_DETECTION in c238b68a..fb47c680 as I don't see this complication as necessary and/or realistic anytime soon.]
||9a69fd81..19e0b66f implements first parts of step (2), but doesn't yet do the zombie check (but adds a FIXME for that).|
||(3) is a bad idea, as disclosing the transfer private key implicitly discloses the coin private key, allowing the exchange to fake deposits of that coin and thus enabling the exchange to claim that the coin was already spent.|
a497ccff..4785bcb4 adds a few notes on where to continue once we figured out what to do about 0005777:0014690.
=> Florian reminded me that the first bugnote already addresses this. Reading would help.
c94309ee..990e7ef3 expands the DB plugin with new functions to store payback information related to refreshed coins.
(a) specify coin history API: add the two new events related to refresh payback (as old coin and as new coin) [DONE]
(b) implement new coin history in exchange, including totaling up the amounts internally correctly, and generating the JSON [DONE]
(c) specify new refresh-payback API for refreshed coins (DONE)
(d) implement new refresh-payback API in exchange (DONE)
(e) Improve TALER_TESTING_cmd_refresh_melt() (DONE)
(f) implement (2) with the zombie check (DONE)
(g) update auditor to handle new coin history possibilities (DONE).
||Assigning to Florian: now a wallet issue.|
|2019-06-26 16:11||Florian Dold||New Issue|
|2019-06-26 16:11||Florian Dold||Status||new => assigned|
|2019-06-26 16:11||Florian Dold||Assigned To||=> Christian Grothoff|
|2019-06-26 16:25||Christian Grothoff||Additional Information Updated||View Revisions|
|2019-06-26 16:41||Christian Grothoff||Additional Information Updated||View Revisions|
|2019-06-26 17:01||Florian Dold||Note Added: 0014598|
|2019-06-26 19:25||Christian Grothoff||Note Added: 0014600|
|2019-06-27 00:05||Christian Grothoff||Note Added: 0014603|
|2019-06-30 17:50||Christian Grothoff||Priority||normal => high|
|2019-06-30 17:50||Christian Grothoff||Product Version||=> git (master)|
|2019-06-30 17:50||Christian Grothoff||Target Version||=> 0.7.1|
|2019-06-30 17:50||Christian Grothoff||Relationship added||has duplicate 0005445|
|2019-07-15 21:59||Christian Grothoff||Note Added: 0014690|
|2019-07-15 22:02||Christian Grothoff||Note Added: 0014691|
|2019-07-19 11:19||Christian Grothoff||Note Edited: 0014691||View Revisions|
|2019-07-21 20:20||Christian Grothoff||Note Added: 0014716|
|2019-07-22 13:30||Christian Grothoff||Note Edited: 0014716||View Revisions|
|2019-07-22 19:18||Christian Grothoff||Note Edited: 0014716||View Revisions|
|2019-07-24 00:04||Christian Grothoff||Note Edited: 0014716||View Revisions|
|2019-07-24 00:31||Christian Grothoff||Note Edited: 0014716||View Revisions|
|2019-07-24 11:58||Christian Grothoff||Note Edited: 0014716||View Revisions|
|2019-07-28 00:12||Christian Grothoff||Note Edited: 0014716||View Revisions|
|2019-07-28 00:13||Christian Grothoff||Note Added: 0014749|
|2019-07-28 00:13||Christian Grothoff||Assigned To||Christian Grothoff => Florian Dold|
|2019-08-01 12:47||Christian Grothoff||Category||exchange => wallet (WebExtensions)|
|2020-03-17 12:13||Christian Grothoff||Note Edited: 0014600||View Revisions|