Relative to the Zerocash paper,
- Mint and Pour operations are merged into a generalized Pour. This is possible because the generalized Pour has a public (transparent) input as well as a public output.
- A transaction at the Bitcoin-like layer is associated with a sequence of Pours, as opposed to Pours (and Mints) being encoded as script operations. Pours later in this sequence can spend coins output by Pours earlier in the same transaction (this is called a “chained Pour”), which was not previously possible.
- A security issue that would have allowed the Receive operation to receive coins that later become unspendable (we call this the Faerie Gold attack) will be fixed.
- We may switch to a memory-hard proof of work (one of the candidates under consideration is Biryukov and Khovratovich’s Asymmetric proof-of-work based on the Generalized Birthday problem, which supports memory-hard proofs with low-memory verification).
- The key-private public key encryption may be changed to crypto_box_seal [edit: actually a slightly optimized variant, still based on crypto_box] and the signature scheme may be changed to Ed25519 [much later edit: this did happen for JoinSplit signatures, not for transparent signatures which are still ECDSA].
- There may be a “memo” field associated with sent coins.
- We may change the hash function used for the Merkle tree over commitments from SHA-256-compress to a hash that is more “SNARK-friendly” (i.e. allows smaller circuit size and therefore better Pour performance and memory usage) [much later edit: we didn’t do this for launch but are doing it for Sapling].
Note that not all of these protocol changes are implemented yet in the public alpha, and there is no guarantee of all of them making it into 1.0.