Show HN: I implemented gmaxwell's "solvency proof scheme" | Hacker News Reader

Show HN: I implemented gmaxwell's "solvency proof scheme"

github.com

29 pointsolalonde9 comments

It is important to know that this scheme is NOT foolproof without further evidence.

If one or more depositors are collaborating with the exchange owner, the owner can simply not include their balance in the "proof", but make an agreement that they would be paid first from the exchange's pool.

The exchange can still be insolvent without proof of all of the total deposits made in all accounts at the exchange. If depositors collaborate to hide their balance, this is very difficult.

This can be seen as a variation of the general risk that goes like: Site proves balances, a moment later site takes backing funds to vegas. The proof shows funds, but it doesn't show what they'll do a moment later.

It's still a massive step forward from the current conditions, but doesn't mean that people shouldn't avoid putting their funds in third party hands.

Presumably the exchange reports the bitcoin addresses for their wallets alongside the proof, so you can look at the blockchain and confirm the balances match. So you know your bitcoins haven't been taken to vegas yet.

Of course, this doesn't provide any security for deposits in conventional currencies, and doesn't stop the exchange just taking the money and running.

What prevents exchanges from adding users with negative balances?

Others mention that it will be visible to other users, but I can be more clear in what that means:

At first glance, it seems you could use a negative-balance user to hide fractional reserve.

Say the sum of all deposits is 2000. You only have 1000 BTC that you can sign on the exchange. If you were to generate a proof tree for that 2000 and add a branch with -1000 BTC balance at the top of the tree, everyone on the other branch would have to be provided that balance in their chain in order to get to the 1000-valued root. Any of them could clearly see that the balance was being manipulated.

So that won't work. If you move the negative-balance hash down the tree, it is still visible to any user who intersects the branch on the way up.

If the balance is negative enough to subtract from any real users balance it will be visible to at least that user.

I pre-compute two trees T1 and T2, which sum to my claimed total. T1 has a fake user with a negative balance who is visible to @nullc. T2 has a fake user with a negative balance who is visible to @legit_user.

If I show @nullc T2 and @legit_user T1, you will both perceive my books as balancing, unless you collude with each other. I can greatly reduce the odds of you successfully colluding by choosing @legit_user to be someone who, e.g., has not logged in in a year, or who hasn't ever bothered to open this verification page.

This is why you must present the root via a broadcast channel, and quantize the timing (E.g. just daily). Otherwise it has the same problems as certificate transparency). People should really go read the original discussion.

One fun way to address the root commitment is to just commit to it in the coins being proven in the balance.

Other users will see it.

Reply on news.ycombinator.com