Closed mschneiderwng closed 6 years ago
Hi @mschneiderwng, thanks for pointing this out (and sorry it took a couple of days to get back to you, I wasn't watching the repository, am now). You're right because Grin is only using the case where the nonce==blind the message API was assuming they'd be the same on rewind. Although Grin doesn't need it, I've changed the API to require the caller to pass in both a blinding factor and a nonce, and it's up to the caller whether they want to keep it the same. I've also added your test into ours. Thanks for pointing this out!
@yeastplume thanks for the fast response. Just curious: Do bulletproofs require both, blind and nonce to unwind? This is somewhat different from vanilla range proofs, where the message is can be revealed with the nonce only.
No problem! The bullet proof message hiding isn't 'unwinding' in quite the same way rangeproofs are, it's using some internal data to XOR the message as sort of a side-product. It basically works by seeding an RNG with the same values, then using publicly derivable values to XOR back.. the nonce + commit is used for the RNG seeding, and the blinding factor is needed to re-calculate one of the XOR values.. I have a fuller description here: https://github.com/mimblewimble/grin/issues/734
Note grin uses blind == nonce just to avoid having to store an extra value (the blinding is available to the wallet-holder). Otherwise, you can use whatever values you want (after this fix).
If I understand it correctly, then the blind and nonce can be chosen independently (even if the rust api sets nonce = blind) when creating and unwinding bulletproofs. However, if nonce != blind, then only the first 32 bytes of the message can be unwinded as in the following test which can be inserted into
perdersen.rs
.