Questions about Binding Signature (Sapling)

I read the sapling paper, and i have a confusion, why sapling need the binding signature?
I know the thought is borrowed from previous research like mimblewimble, or others, but, in mimblewimble, the randoms used as the spend key.
In sapling, the value commit calc process is verified in zk-proof, and the randoms is not used as the spend key, so, why not use a simpler method of verification: add all spend cv, subtract to all output cv, check the result is 0 or not ?
because others do not know the value and randoms in output, so actually he can not replay the output even when there is not binding signature.

1 Like

First, Zcash needs to support a variable number of shielded inputs and shielded outputs in a transaction. Given that circuits need to be constant-size, that’s the main reason for using value commitments at all (otherwise, we could check for balance over all inputs and outputs in a single circuit).

But why can’t we, as you say, just publically open the sum of spend cv’s minus output cv’s to zero? The reason is to do with transaction malleability. We do not want to allow any information from inputs or outputs in one transaction to replayed in another transaction. This is analogous to nonmalleability for encryption (which is equivalent to chosen-ciphertext security): if you can manipulate a ciphertext into another ciphertext that will be decrypted into a related plaintext, then you have taken advantage of a non-ideal property of the encryption. You can of course produce such a ciphertext if you knew the original plaintext, but if you didn’t, then the original ciphertext should not give you any information that helps to make a ciphertext decrypting to a related plaintext. The attack we’re trying to avoid here is the corresponding one for nonmalleability of zero knowledge proofs.

(Note: this property is independent of transaction ID nonmalleability, which is a property that we will be newly guaranteeing in NU5. The nonmalleability property I mentioned above was already met by Zerocash and by Zcash Sprout, and we did not want to have any security regressions in Zcash Sapling relative to those protocols. The approach used in Sprout was to have one “JoinSplit signature” per transaction; the Sapling binding signature should be considered as replacing that JoinSplit signature.)

How we prevent nonmalleability attacks in Sapling is that the binding signature acts as a proof of knowledge of all of the value commitment randomnesses, tied to the sighash of the transaction. Each proof is tied to a specific value commitment via its cv public input. This prevents Spend or Output proofs from being replayed. (Orchard uses a similar scheme except that the Action circuit combines a spend and an output.)

Historical note: while most of Sapling was designed with us all working in a distributed way, the binding signature design was arrived at in an in-person meetup between me, Str4d, Sean Bowe, Nathan Wilcox, and Jack Gavigan in Greenwich, London, which is where we thrashed out the remaining design issues before (roughly) finalizing the Sapling spec. It was first written up here.


Thank you very much.
But I am still confused, the spend authorization signature (Sapling) can solve the malleability problem, because the spend authorization signature is over the SIGHASH transaction hash, so, for this malleability problem alone, the binding signature and the spend authorization signature do the same thing?

if so, when check balance, can we just publically open the sum of spend cv’s minus output cv’s ,check the result is zero or not? because, the SpendAuthSig has already prevent the malleability.

The spend authorization signatures can’t solve the malleability problem on their own because (for a start) the problem also occurs in transactions with no shielded inputs. More subtly, the transaction may be generated by multiple parties of which only one is providing shielded inputs.


Thank you very much, and if there is not even a shielded input, then neither is there the spend authorization signatures, in this case, it really cannot rely on the spend authorization signatures to solve the malleability problem.
zcash is truly a subtle work of art with many beautiful details, thank you for bringing us such a wonderful cryptocurrency.
ps: I may have other questions, thanks for the answers