Adam, I reviewed the proof and you are absolutely right. For some reason I thought that wrap-around wasn't a problem and that I could prove y=x_1+...+x_n over the integers. The thing is that Groth's proof can prove that a vector is the Hadamard product of two other vectors over the integers or prove that a value is the inner product of two vectors but only over the integers modulo n. Strangely he treats both cases as interchangeable and never mentions this critical difference.
Anyway, I need to add range proofs for all input/output amounts and then it's enough to check if Com(y)/(Com(x_1)*...*Com(x_n))=Com(0). I will probably use Berry Schoenmaker's range proof with your improvements.
Also, I have been thinking of ways to substitute the Paillier's encryption for another encryption scheme. First, I can't trust the sender of a transaction to send the value and the nonce of the transaction (how you did in your homomorphic value scheme) because if he sends the wrong value the receiver no longer can use his account. Worse, a malicious user could do that on purpose to ask for ransom or to disrupt the network.
The other suggestion (from gmaxwell) was to use elliptic curve Elgamal. I did some research and found that a 3 GHz Pentium 4 processor can do an EC addition on a NIST 256-bit prime field curve in 8.3*10^-8 seconds. Extrapolating from that, it can crack a 24 bit EC discrete log on average in 0.7 seconds. So, if I reduce the maximum amount per transaction to 2^24 units, I could use EC Elgamal instead of Paillier. As a bonus, the range proof size would be cut in half. So it may be a viable idea.
The problem with exponential Elgamal (as you've said) is that you need to brute-force the decryption. As the balances of the accounts are also encrypted, users only have two options:
1) Store a copy of the balance in theirs computers using a different encryption. Since the mini-blockchain only stores transactions for a limited time, they would need to connect to the network periodically (7 days in the case of cryptonite).
public key encryption can do that fine, and the user has key(s) to control coins or balances.
My issue wasn't with storing the balance. The problem is if a transaction is deleted before the receiver connects to the network. Then the receiver has no way of finding the transaction amount.