A vulnerability in olalonde's implementation of gmaxwell's proof-of-solvency

[charlescharles]

So we've established that we need nodeC.left.val, nodeC.left.hash, nodeC.right.val, and nodeC.right.hash to verify the integrity of nodeC.val and nodeC.hash. The same logic applies recursively to nodeC.left and nodeC.right: this is why I said that proofs of inclusion now require O(N) space. You ultimately need to know all the leaves.

[1713908949]

1713908949

[1713908949]

1713908949

[1713908949]

1713908949

[1713908949]

1713908949

[andytoshi]

You don't need to verify the integrity of nodeC.left.hash or nodeC.right.hash.

[gmaxwell]

The requirement is that if there is fraud it must be detectable by some user under some path and that they have the ability to create a transferable proof of their detection. You can't achieve stronger than that (e.g. that if there is fraud all users can detect it) under this approach.  The criteria is met if you show the unsummed values (as listed on iwilcox page) or just show the one step deep off-path preimage.