There are variants of schnorr proof of knowledge (DSA is a variant of schnorr) where you can prove that encrypted values are the same by combining with Elgamal. So I think you should be able to prove that the sender sent the recipient in a way decryptable by their advertised public key, an encrypted value which matches the (non-decryptable) second encryption. eg if you look at Brands is a more complicate version but there are a few survey papers showing all the common things you can easily prove using schnorr variants.
ie so prove that the plaintext under the encryption would result in the recipient knowing a value that would allow it to spend the coin. in your labelling make a schnorr-related proof that y=y' and r=r'.
I did think of this going back a few weeks in my comments on your original scheme but maybe neglected to say it.
Adam
Adam: The url is working fine in my browser but I will change it.
I need it to be decryptable because you don't know if the sender of the transaction will send the right value and random value. In your homomorphic scheme this isn't a problem because you could simply ignore the transaction but this scheme runs on top of the mini-blockchain which actually has accounts. Suppose you have an account with balance x and corresponding Pedersen commitment xG+vH. Then I send you a transaction with value y (it can even be zero) and random value r,so yG+rH, but I send to you encrypted any other values (let's say y' and r'). The two commitments will be added and your balance will be (x+y)G+(v+r)H. Now you can't open the commitment of your own balance so, you can't make transactions because you won't be able to produce the required ZK proofs. Finally I can send a message telling you to pay me z bitcoins or I won't tell you the real values.
Also, the mini-blockchain only stores transactions for a limited time (in cryptonite's case it's 7 days) so if someone receives a transaction and doesn't connect to the network in 7 days, he won't see the transaction and will no longer know its own balance.