aboutsummaryrefslogtreecommitdiff
path: root/contrib
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2022-01-11 12:47:35 +0100
committerChristian Grothoff <christian@grothoff.org>2022-01-11 12:47:35 +0100
commite7aeec04f4eb52caaa61b1ff9362f6fe0ffe0f2d (patch)
tree7e788144cff60c41a07e2bc136e86ddadf610274 /contrib
parentaaaaa9a103628d7694a4fb3bac6335501187cc00 (diff)
The current recoup API is broken. I guess this is another example where "trivial" API changes turn out to have (multiple!) unexpected consequences.
The current "/recoup" API does not have clear idempotency semantics, as we've discussed on the phone. This is already bad by itself, as it makes it hard to write down what the API does other than "whatever the implementation does". However, it actually breaks correctness in this (admittedly kinda contrived, but not impossible) case: Say that we have a coin A obtained via withdrawal and a coin B obtained via refreshing coin A. Now the denominations of A gets revoked.. The wallet does a recoup of A for EUR:1. Now the denomination of B also gets revoked. The wallet recoups B (incidentally also for EUR:1) and now A can be recouped again for EUR:1. But now the exchange is in a state where it will refuse a legitimate recoup request for A because the detection for an idempotent request kicks in. This is IMHO bad API design, and the exchange should simply always recoup the maximum amount. Furthermore, we usually follow the principle of "API calls that take up DB space are paid". With the current recoup API, I can do many tiny recoup requests which the exchange then has to store, right? I guess it would not be a big change to remove the "amount" value from the recoup/recoup-refresh request bodies, right? - Florian
Diffstat (limited to 'contrib')
m---------contrib/gana0
1 files changed, 0 insertions, 0 deletions
diff --git a/contrib/gana b/contrib/gana
-Subproject 9b8a787580307cea5a38359c485d521cd8ece82
+Subproject b0dd85e8187f33a1f92dd5eb31082050d333e16