Quote from: vector76 on June 26, 2011, 09:50:55 PM

I don't think hashes will protect what you're wanting to protect. People with only the hash should be confident that the money is not being fabricated, but whoever is doing the hashing can fake it, and unless they are forced to prove that the full accounting generates the hash, there is no way to know. So you might as well just append the unencrypted total to the hash of the sorted list.

The sum of the values must be cryptographically secure, else you could tamper with the hash and say the total is different than the actual totals of the input to the hash. And it isn't enough to merely be confident that the sum isn't rapidly growing, you have to have certainty that it hasn't changed. This means if you're going to use length of the encrypted data, you must not pad it.

Quote from: vector76 on June 26, 2011, 09:50:55 PM

You could store the map in "unary", in other words { (A, 5), (B, 2) } would be stored as "AAAAABB" (lexicographically sorted before expanding)

Then encrypt with a public key.

The length serves as an indicator of total value. If you use a block cipher in counter mode then whoever has the private key could decrypt portions to prove that certain keys own certain coins, without having to divulge the entire ownership map.

This possibly meets the requirements for GETTHEBLOCK_2, though you can extract way more information than just the amount of currency from this which is sort of pushing what I asked for by a cryptographically secure hash... How do you guarantee all the keys are the same length, for instance? The keys, too, may be of arbitrary size.