Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Bobtimus seems to not be able to handle more than one swap #91

Closed
thomaseizinger opened this issue Jan 6, 2021 · 0 comments · Fixed by #114
Closed

Bobtimus seems to not be able to handle more than one swap #91

thomaseizinger opened this issue Jan 6, 2021 · 0 comments · Fixed by #114
Labels
bug Something isn't working
Milestone
MVP

Comments

@thomaseizinger
Copy link
Contributor

Getting this error when trying to do a 2nd swap:

[2021-01-06T00:32:40Z ERROR bobtimus::http] Failed to handle create swap: failed to prove surjection
@thomaseizinger thomaseizinger mentioned this issue Jan 6, 2021
Closed
@thomaseizinger thomaseizinger added this to the MVP milestone Jan 6, 2021
@thomaseizinger thomaseizinger added the bug Something isn't working label Jan 6, 2021
luckysori added a commit that referenced this issue Jan 8, 2021
@luckysori
Stop making too many evil clones of Bob
d08b5bf 
Bobtimus holds an instance of rng initialised at start-up. Every time
we receive a request, we clone our instance of Bobtimus and therefore
the instance of rng itself. Any state changes to the rng (which happen
during usage) thereby did not affect the original prototype of
Bobtimus. As a result, any future request started with exactly the
same rng state and therefore produced the same sequence of random
numbers.

This led to conflicting blinding factors between inputs and outputs.

Fixes #91.
luckysori added a commit that referenced this issue Jan 8, 2021
@luckysori
Stop making too many evil clones of Bob
a95b821 
Bobtimus holds an instance of rng initialised at start-up. Every time
we receive a request, we clone our instance of Bobtimus and therefore
the instance of rng itself. Any state changes to the rng (which happen
during usage) thereby did not affect the original prototype of
Bobtimus. As a result, any future request started with exactly the
same rng state and therefore produced the same sequence of random
numbers.

This led to conflicting blinding factors between inputs and outputs.

Fixes #91.
luckysori added a commit that referenced this issue Jan 8, 2021
@luckysori
Stop making too many evil clones of Bob
f9ccdd8 
Bobtimus holds an instance of rng initialised at start-up. Every time
we receive a request, we clone our instance of Bobtimus and therefore
the instance of rng itself. Any state changes to the rng (which happen
during usage) thereby did not affect the original prototype of
Bobtimus. As a result, any future request started with exactly the
same rng state and therefore produced the same sequence of random
numbers.

This led to conflicting blinding factors between inputs and outputs.

Fixes #91.
@luckysori luckysori mentioned this issue Jan 8, 2021
Merged
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
MVP
Development

Successfully merging a pull request may close this issue.

Stop making too many evil clones of Bob comit-network/waves
1 participant
@thomaseizinger