olalonde / proof-of-liabilities

Proof of Liabilities (PoL) is a scheme designed to let companies that accept monetary deposits from consumers (e.g. Bitcoin exchanges, gambling websites, online Bitcoin wallets, etc.) prove their total amount of deposits (their liabilities) without compromising the privacy of individual users.

Home Page:http://olalonde.github.io/proof-of-liabilities

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

exposing the neighbour amount is problematic...

tal1 opened this issue · comments

commented

exposing charlie's balance to mark.

I think this is a non-issue. Exchanges can generate an 'Accounting ID' that is unique to each user and does not reveal any personal information other than the balance.

commented

Yes thanks for the comment. I think another solution to this would be to have the sibling of actual users always be a "dummy" user with balance = 0. Will wait for more suggestions and feedback.

commented

@orweinberger one possible issue with Accounting ID idea is that a website implementing this could show the same accounting ID / tree to 2 different users and it would be hard for them to tell. If the actual username / e-mail is visible, it's easier for users to tell that their tree is really unique. I'm not sure if I'm explaining this clearly... Tired :/

@olalonde Yeah that's a pretty clear explanation.

These sort of hacks won't work for long though since a user accounting id should be unique and as soon as someone does any transactions in his account he will notice that it no longer matches what's in the solvency report.

So yeah it's possible but unlikely to happen for more than a day without users noticing.

Greetings.

Every leaf node should have a nonce. e.g. login name, value, 128 bit nonce. The node is then hashed— so there isn't a neighboring privacy leak.

I prefer this design to using a unique account ID because keeping the account ID private may be harder (e.g. if it's used elsewhere), and because then you have the problem of proving that the account ID is unique. Username is harder to have non-uniqueness concerns— though a bit is still possible.

Askmike on #bitcoin-dev was suggesting to use the users "deposit address" before I pointed out that I'd expected the leaves to be hashed... but it still might be prudent to include the last address deposited to (if any) as an additional factor along with the username to avoid multiple users being given the same node (e.g. by letting people use the same username and distinguishing by password). It doesn't replace a nonce, however, since addresses are public information (people could just try all known addresses for their neighbor).

commented

TODO: stronger nonce()