-
Notifications
You must be signed in to change notification settings - Fork 222
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
Are the on-disk swap db files required for marketmaker operation? #757
Comments
they are not needed after a swap reaches the finished state, ie. a .finished file is there so the files are needed temporarily, after that they can be transferred into the DB. |
Yep, every single swap database entry has it's HTTP request/response JSON saved along with every JSON message we receive over the socket.
Yeah, I was thinking about some kind of batching, maybe just on app quit would be enough. So we definitely can't disable them all together? They are a small privacy leak. People could easily derive your address and balance from the TXIDs. Our swap DB is encrypted so none of the TXIDs we store are readable by anyone else on the system, or more importantly in the event of losing a backup drive. |
certainly a possible privacy leak if you lose your computer/drive to somebody else, but if you dont, then no leak. maybe you can ask artem to not have files in 2.0 |
Well it's a similar issue with storing private keys in plain text. Obviously that's security instead of privacy so the implications are much higher. But if your data never gets into anyone else's hands it's perfectly fine. But inevitably it will eventually, so best to protect against that. I will raise it with Artem for v2 👍 |
Does it use these files during runtime or is it purely for persistence between restarts?
If it's only for persistence, is it safe for us to remove these whenever? It's not going to cause issues with mm expecting them to be there? We have everything we need stored in our internal DB.
Alternatively, if they aren't required, it would be great if we could turn of the filesystem DB with a CLI flag.
The text was updated successfully, but these errors were encountered: