-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enforce minimum exchange rates #273
Comments
FWIW, since we now have exchange rates within the store, this might be simple to fix. We'd somehow need the STREAM receiver to send a Edit: it also looks like the JS implementation uses a similar approach, by using the |
Also, when we implement this, we need to update the STREAM sender to limit the delivered amount based on the minimum amount they set in the Prepare (the delivered amount should be the min of what the receiver claims they got, and what we told them was the minimum they should accept). After we support invoices (paying by destination amount, rather than source amount), the recipient could fulfill the packet, but lie and say they received 0, which would cause the sender to continue sending indefinitely, draining their account. JavaScript STREAM is also vulnerable... but Java is not! Woot @sappenin 🎉 (although I think it would incorrectly report the delivered amount to the application) |
@kincaidoneil can you clarify that one? Is there a bug in the Java logic? |
@kincaidoneil this has been assigned to you - I think it's worth fixing. |
Originally posted by @kincaidoneil in #256 (comment)
The text was updated successfully, but these errors were encountered: