In the Sapling protocol the commitment scheme has 2 components, the NoteCommit and ValueCommit. I don’t understand why we need ValueCommit. From my understanding we need to prove 2 things to show that the note the user is using to spend corresponds to a valid commitment on the block chain
Note Commitment Integrity: the note (d,v,r,pk_d) hashes to a commitment and
Value Commitment Integrity: this commitment is a valid leaf on the public Merkle Tree
Wouldn’t the Note Commitment Integrity be enough to validate that the note’s value is equal to the commitment’s value? (because if if we change the value the commitment would change).
This is actually two separate things (per the protocol spec):
Merkle path validity: the note commitment cmu is a valid leaf on the public Merkle Tree.
Only for Spend proofs.
Value commitment integrity: the value v within the note corresponds to a value commitment cv.
Correct! The note commitment is necessary and sufficient to bind the value of the note.
The value commitment is only there for a very specific purpose: enabling the value across multiple Spends and Outputs to be privately balanced. This works because Pedersen commitments (for a value vi and blinding factor ri, cvi = gvi + hri) are homomorphically additive: if vtot = v1 + v2 then cvtot = cv1 + cv2.
When a Sapling transaction is created, the prover sets valueBalance = ∑vspends - ∑voutputs, and then uses ∑rspends - ∑routputs as a private signing key to compute bindingSig. Verifiers then compute ∑cvspends - ∑cvoutputs - gvalueBalance, which is equal to h∑rspends - ∑routputs, i.e. the public key that can be used to verify bindingSig.
It’s not a MimbleWimble implementation per-se; rather, Sapling and MimbleWimble use the same technique. From section 4.12 of the Zcash protocol spec:
Non-normative note: The technique of checking signatures using a public key derived from a sum of Pedersen commitments is also used in the Mimblewimble protocol [Jedusor2016]. The private key bsk acts as a “synthetic blinding factor”, in the sense that it is synthesized from the other blinding factors (trapdoors) rcvold1…n and rcvnew1…m; this technique is also used in Bulletproofs[Dalek-notes].
I did some searching of the issue tracker. The idea of chaining proofs together using a balanced sum of value commitments was AFAICT first documented for Zcash in January 2016 (before I joined ECC, so I was not around for any corresponding discussion):
The issue that concretely proposed instantiating the value commitments with Pedersen commitments was #2634, it being feasible at that point after Jubjub (#2230) and an efficient Pedersen hash circuit (#2234) had been designed.
The MimbleWimble note was published in July 2016 [edit by @daira: actually August 2016], and does not reference #647, so it is likely (though unverifiable) that its author(s) came up with the idea independently. I can’t find anything in the public Zcash issues mentioning MimbleWimble, so you’d have to ask @daira when ze became aware that it used the same technique (it was no later than April 2018, as that’s the URL visit date in the protocol spec reference).
Both of these were of course preceded by Confidential Transactions, but CT required the blinding factors to be carefully selected such that they cancelled out in the final sum, and (to my knowledge) did not propose using the sum of blinding factors as a signing key (the MimbleWimble note is explicit in saying that this was a modification it was making to CT).
I’am not the tech guy and reading the below posts/answers doesn’t make things more clear.
Simple question: Does sapling indeed have MimbleWimble inside?
No. MimbleWimble (at a highly simplified level) uses a combination of two techniques: the above pubkey-from-sum-of-value-commitments technique, and the one-way aggregate signatures (OWAS) technique used to combine transactions. Sapling uses the first technique, but does not use the second. So they do have some overlap, but Sapling does not contain MimbleWimble (or vice versa).
I believe that was as soon as I saw the Mimblewimble post, or maybe Andrew Poelstra’s explanation of it. That would have been August 2016 if it was the original post, or October 2016 if it was Andrew’s paper.
Note that the use of binding signatures for Sapling wasn’t decided in #647; it was decided at the Greenwich meetup to tie up loose ends in the Sapling protocol, with @str4d, @ebfull, me, and @Dodger on 23-24 January 2018. (Another highlight of that trip for me was seeing Harrison’s H1-H4 clocks at the Greenwich Observatory.) We had a problem with malleability of shielded transaction outputs that weakened the protocol, and this was one of the possible fixes. We were all aware of CT and Mimblewimble at that point, but we were just using a signature of knowledge in the obvious way given the problem at hand.
I think that maybe there’s a misimpression that using a sum of Pedersen commitments as a public key is a “big idea”. It’s not, it’s the very first thing a cryptographer would think of when faced with the problem of needing to authenticate the sum of homomorphic commitments. Maybe it had been used before Bulletproofs, Mimblewimble, and Sapling; I’m not sure. The main innovation of Mimblewimble is the observation that using this approach allows you to compress transactions (within a block).
