Topic: [ANN] Kraken Passes Cryptographically Verifiable Proof of Reserves Audit - page 2. (Read 40018 times)

I'd settle for a multi party audit, with him being involved. Say him plus two others would suffice.

Good job Kraken 

...which means he is at least capable of understanding what is going on and also verifying that no random sh*t is being presented to him.

I would not trust some random 20-years-in-the-business auditor from PWC to do this stuff. Mabye it could be possible to develop something REALLY fool proof and let this be run by a notary (obtain code, check + note down checksums of executables, post output of tools, sign this data)?

These things are unfortunately still too "techy"/strange for someone who audits fiat holdings (they in return usually just trust bank statements by the way). Until then we'll have to deal with Bitcoiners auditing other Bitcoiners I fear.

He could have cured cancer that doesn't change the fact that he is an individual in the industry.

He is also Admin of this board here, wrote BitcoinJS and helped Bitcoin adoption a lot a few years back with the weusecoins video...

Still I agree that it is not ideal to have just someone trusted to look at these numbers instead of publishing bitcoin holdings and user balances.

+1

Why is an industry insider doing your audits? How friendly are you with this Stefan character? How do we know he does not have some ulterior motive in proving your solvency? Because he works for Ripple? Lol, come on.

That's just stupid, to insinuate Kraken would run away with user deposits, it's funded by Roger Ver for christ sake...

Can I make the audit myself using the tools given ?
Or do i need access to the database of Kraken ?

Techniques for doing that exist, but are quite a way off and probably quite a burden for exchanges today (and perhaps always).  So we settle for the best we can get in the meantime, which is: let any customer who cares to check, do so.  If they notice discrepancy they can at least make an informed decision to trade elsewhere.  While they can't provide independently verifiable evidence of what their balance was meant to be (without advanced techniques it comes down to customer's word against exchange's), I suspect if enough users got cheated they'd kick up a stink and a cheating exchange would get called out.

Ultimately, until those advanced techniques are openly available and tested, the burden lies with you, the customer, to actually:

• perform checks regularly
• protest loudly and publicly about discrepancies
• vote with your feet by moving to exchanges which offer this
• vote with your feet by ditching exchanges which implement this incorrectly

How to prove that claim 2 is true? Unless all the customers report their balance in a public poll and no fake reporting

+1

Yes, see https://github.com/olalonde/proof-of-solvency


This problem is addressed in the standard proposed here: https://github.com/olalonde/proof-of-liabilities/#leaf-node

By the way, I'm not sure I understand how Kraken users are supposed to do the verification. Are they given a tree in order to compute the root? If so, would anyone mind sharing the tree they were given so that I can make http://syskall.com/proof-of-liabilities/#verify compatible with their format (this will reveal your balance on Kraken)? Let's be realistic, most users will never verify the code if it involves writing some code.

Good to heard that!
Great job guys!

Great work guys, congratulations.

I'm afraid one piece of the puzzle seems still open to me. The audit proves that everyone's balance is represented in the Merkle tree, but not that the same bitcoins aren't backing two people's accounts at the same time. That is, there's no way to check against the following scenario:

USER1 audit page:
Submission code: 379377cd8190f9bf
Amount: 0.01500000

USER2 audit page:
Submission code: 379377cd8190f9bf
Amount: 0.01500000

Thankfully, this proof gap can be resolved without an auditor, and in an anonymous way.

I propose the following three-step scheme. (step 1) Kraken generates a 64-bit nonce for each account in the system. They publish this nonce on each user's account page, as follows:

USER1 audit:
Submission code: 379377cd8190f9bf
Nonce: fa132f44d7e35e0f
Amount: 0.01500000

(step 2) Kraken publish a signed document with the anonymized account name for each submission code:

$submission_code: sha256($nonce || ":" || $username)

For USER1 in our example, sha256("fa132f44d7e35e0f:USER1")=b7000194f1327aeb9b16f6104333fc889dd2f4c3cdba1eb3500d91ca5efc8208, so the document would contain:

379377cd8190f9bf: b7000194f1327aeb9b16f6104333fc889dd2f4c3cdba1eb3500d91ca5efc8208

(step 3) Users will verify not only that their submission code exists in the Merkle tree, but also that the submission code cannot correspond to any other account by calculating the sha256 as above and verifying that it corresponds to the submission code.

(end of scheme)

The only drawback I see is that this will make public the number of accounts in the Merkle tree, but I don't think this should be a problem.

Let me know what you think.

It would be good to involve a well-known traditional accountancy for this. There are all kinds of standards that could be useful, such as SSAE 16. Note that I'm not talking about permits here, but voluntary audits by a trusted third party.

great stuff.
always good to have transparency, best luck Kraken, here's to the future. 

thanks kraken for doing the audit with crypto-prrof.
imho much more trustworthy than with an auditor.

This is a great news, after all this bad news about exchanges going bankrupt or getting hacked...

It will be amazing if the Bitcoin Foundation or whomever with right authority creates a small team of Independent Auditors funded by the exchanges to do regular checks. This way people can at least have little bit more faith in the system. We cannot trust the exchanges to self-regulate considering what happened at MtGox.

Exchanges can get verified quarterly and the report of the audit can be made public... Just a thought...

Digressing a little bit, but there's many ways to do it. The general theme is that coins that haven't been traded for 24 hours (say) get moved to an M of N wallet. Coins in open orders, or coins that have recently been traded remain in a pooled hot wallet.