# Zcash shielded Airdrop - WIP The state of the system of system is constituted by the root of the sapling commitment tree and the nullifer set. If you take a copy of that state at a given block height, you can have something else that is tracking it. You could add more commitments to the tree, or more nullifiers to the set. But that is entirely separate process. When you start updating the state in a different way from the standard sapling circuit, you and up into a new state which is different in nature from the one you started from. If you use the spend circuit to prove things about the state that you copied the spend circuit will prove that there is a commitment in the commitment tree and the nullifier that gets revealed is not in the nullifier set already. It proves, among other things, there exist a note in the commitment in the commitment tree which has a particular nullifier that get publicly reveald and you can check that the nullifier is in the nullifier set. Usually you want things to balance in a transaction. When you have a spend circuit proves this about the state at hand, you are going to have a value commitment for that spend circuit and the value commitment is going to be different depending on which spend circuit you use, because in this situations we are going to have two different spend circuit that you have to keep track of. Which are: * the sapling spend circuit * the MASP spend circuit The commitments used in these two circuits are incompatible, because the hash used are not the same. The pedersan hash depends on a set of elliptic curve base points, that are fixed. Say that you want to have 5 bits input into your hash, then you generate 5 different elliptic curve point and then you either add or not add a certain point depending weather the bit is $1$ or $0$. So when the pederson hash is constructed you have to choose which curve point you use. For security it's generally best to have domain separation, so they are completely different hashes for each independent application. This means that the note commitment uses different pedeson hash, but also the value commitment will use different bases as well. They are not pederson hash, but are still pederson commitments. If you don't want to allow to new sapling notes to be created then that's something you would do outside of any circuit. You would not want any sapling output circuit and you would not want any sapling note commitment to be added to the commitment tree. That would free the sate. If you do not add the new nullifiers to the nullifier set that would allow the same note commitment to be input to the spend circuit again and again. For each commitment type you want to decide what is allowed for that commitment: if do not want to allow new sapling types commitments to be created then you don't want to change the note commitment tree. The commitment tree and the nullifiers are completly public, so these constraints can be publicly enforced. If you compare how to do the integral evaluation, when you want to compute a function over time, it's more technically challenging. But if everytihng You can not recover the information just form the commitment tree and the viewing key, or any key, because it is not enough information. Because you do not know the trap door secret randomness to open the commitment. So the only thing you can do is trial decryption on separate encrypted notes. You take the viewing key and you trial decrypt and if successful you have all the information there. After you decrypt, you should have all the information needed. So you would know the decryption was successful, you need the nullifier to see if the note was already spent or not. You would have to scan the nullifier set, but if the nullifer set is sorted this should be very fast. Moreover there should be sapling tools that do exactly this. It's public key decryption with the incoming viewing key. The viewing key can do key exchange and recover the symmetric key that is used for the note. One trial decryption is one elliptic curve scalar multiplication, and maybe some other smaller operation which should be cheap. --- Users who wish to receive shielded payments in the Zcash protocol must have a shielded payment address, which is generated from a spending key. In the Zcash spec it says: "However, user-visible operations should be provided to obtain a shielded payment address, incoming viewing key, or full viewing key from a spending key or extended spending key." Notes are stored on the block chain in encrypted form, together with a representation of the note commitment cm. The note plaintext in each Output description or Action description is encrypted to the diversified payment address.