randomize accounts/tree structure
olalonde opened this issue · comments
I have some thoughts on this which haven't had time to crystallise quite yet, but the rough picture is: perhaps there's a way to minimise the ability of an Evil Exchange to hide negative or zeroed-dormant accounts down in the depths of trees, away from people who check. Perhaps we could use something like provably fair gambling --- have the exchange produce a hash of some entropy, produce the tree using the entropy to dictate tree position, then later produce the entropy. I haven't got as far as working through a mechanism though.
The only way to hide negative balances is by canceling them out with positive balances, and users whose positive balances have contributed towards hiding that negative balance will see the negative in their partial tree.
The biggest problem I see is if the exchange tries to hide insolvency by dynamically generating a new root tree when a user comes to check their partial tree. It would be trivial for an exchange to figure out the set of users with large account liabilities who never check their partial tree, and use those users' liabilities to hide negative balances (or not include their large positive liabilities at all when calculating total liabilities); and when they finally do come to check, the server could recompute the root with a new hiding spot.
So, the exchange should be expected to keep a root available for some long duration of time.
Yeah, and automated verifiers would also have to test historical records (it's already a push to get normal people to verify today's tree, so I think it would take serious levels of convenience to get them to check historical ones). I did have words (currently commented out) in my page about how exchanges should push proof trees and roots out unsolicited (perhaps by e-mail?), rather than provide them at login, or (worst possible) on request.
Very good points. I think we should have some guidelines/standard about how frequently operators are expected to publish proofs, how long they are expected to keep archives, etc. etc. There should be some timestamp/block height meta data associated with proofs too as @jaekwon mentioned. Also, there should be some standard about which proofs clients are expected to verify (for example: check proof of the day, check proof of last monday, check proof of first of the month). Just my random thoughts... I also like the idea of a "push" standard... this would eliminate the problem of operators being able to single out people who don't verify and would eliminate the need of using a <script> tag.
Related: olalonde/proof-of-solvency#4 olalonde/proof-of-solvency#2 olalonde/proof-of-solvency#1 olalonde/proof-of-assets#7 (meta: maybe I shouldn't have split up the project into 4 repositories, it's getting confusing haha)
Discussion about meta tags / push system can continue here: olalonde/proof-of-solvency#1