

Show HN: I implemented gmaxwell's "solvency proof scheme" - olalonde
https://github.com/olalonde/blind-solvency-proof

======
karl_gluck
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.

~~~
nullc
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.

~~~
michaelt
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.

------
jackhammons
What prevents exchanges from adding users with negative balances?

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

~~~
patio11
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.

~~~
nullc
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.

