Your requirement that a balance of zero not be included in the hash violates the last two properties. The third property is violated because an input can be constructed from another input that has the same hash, simply by appending an account with a balance of zero. The final property is most trivially violated; any time a new (zero) balance is added, the hash is unchanged. I'll ignore these for the purpose of discussion, but I consider them alone a valid proof of the nonexistence of a cryptographic hash function, and claim the bounty.
I specified that the hash must be cryptographically secure, so yes, a cryptographic hash function of fixed length, except for GETTHEBLOCK_2 which may be of arbitrary length.
Appending an account with a balance of zero does not change the distribution of funds, and thus does not change the input, so there is no violation. If this is impossible to do and remain cryptographically secure, that merely needs to be proven. This requirement alone (cryptographically secure or not) can be done as follows: hash(private key
1)×balance
1 + hash(private key
2)×balance
2 + ... + hash(private key
n)×balance
n (where "+" denotes addition and/or XOR). But again, this may not be cryptographically secure.
Even if it were cryptographically secure (such that the private keys are unrecoverable), it does not meet the requirement that a change in funds from one person to another must cause a predictable change in the hash (specifically, the algorithm must offer a way to prove the total amount of funds in all the accounts is the same before and after the transfer).