Yes! I would propose the name CommitmentData for the larger structure containing the commitment and auxiliary data (whether it be randomness, previously computed values, or anything else). This also makes it less likely to be thought of as an actual "commitment on steroids", which I could see happening with ExtendedCommitment.

As discussed with @autquis and @Antonio95 , an alternative approach would be to turn the rands into an aux_data structure, and have commit return a tuple of (commitment, aux_data). This has the advantage of being less likely to mis-use and accidentally pass the ExtendedCommitment to the verifier.

Sounds like a good idea to have commit output the commitment and an additional "commitment state" (I presume that this is used in opening?). If so, a descriptive name would could be CommitterState?

Correct, that would be used in open.

Hm then perhaps CommitmentOpeningData would be slightly better? (Because if I call commit in a sequence it's not like I'll be passing the state from one call to the next)

Sure, we can start with that and see how the name feels once it's implemented :)

Would you want all schemes in the repo to have the hiding property?

In #134 , we have added PCCommitmentState along with PCRandomness. Ideally, we should merge these two in one. One way to do so is to remove the methods from PCRandomness. This implies that we are not enforcing hiding property on the schemes of the repo. If a scheme is hiding, it implements these methods for its Randomness. However, if a scheme is not hiding, implementing these methods is unnecessary (e.g., #131 and #132).

We can merge PCCommitmentState and PCRandomness, I think, and put the methods from PCRandomness into PCCommitmentState. For schemes where we haven't implemented hiding, these methods can be no-ops.