Is (slightly) malleable value base a real issue?

[ghost]

As far as I can tell, there is no verification in the circuit that the given value base in a note is the hash of some asset type string. So someone could spend a note of 1 unit with value base generator P and output a note of 0.5 units with value base generator 2P (unless this is prohibited somewhere)

This may not be a real issue at all, either because 1. It’s prohibited in the circuit somewhere I don’t see) or 2. It’s allowed but not a critical flaw, because someone can’t ultimately turn that note into anything meaningful (other than the original asset type)

[cwgoes]

What about the case of creating two assets, one garbage and one real? Are we concerned about that?

[ghost]

Right. So if you were arbitrarily allowed to choose the value base of a note, then assume V is the group hash of some token type T and R is the randomness base of the pedersen commitment. Then if I have a note N^old with 1 token of T, I could create vc^old = [1]V + [r^old]R for some randomness r^old, and then create a Spend proof that the value of N^old matches the value in vc^old. We can then create two new notes N^real and N^garbage, with the characteristics: value of N^real is 2 units of token T with value commitment vc^real = [2]V + [r^real]R, and value of N^garbage is 1 unit of garbage token T' with value commitment [1]V' + [r^garbage]R.

We choose V' = [-1]V, which means the garbage token T' does not correspond to any actual asset type (and therefore N^garbage cannot be removed from the pool) but then the value balance check yields:

([1]V + [r^old]R) - ([2]V + [r^real]R + [1]V' + [r^garbage]R) = ([1]V + [r^old]R) - ([2]V + [r^real]R + [-1]V + [r^garbage]R) = ([0]V + [r^old - r^real - r^garbage]R)

which is a commitment to 0.

Since the value base V' = [-1]*V is easily computable (for JubJub, negate the x coordinate), if the group hash is not checked, then nothing verifies that the output note N^garbage doesn't have this value base.

[ghost]

I think if we add the value base to the note commitment, then we only need to compute the group hash in the Output circuit. Then every note commitment must have a valid value base that is the Blake2 image of a token type (checked in the Output circuit) in order to be added to the Merkle tree.

Then the Spend circuit only needs to be given the value base as input and not the token type, avoiding the blake2 hash in the Spend circuit. This is because the correct value base must be given in order to properly verify the note commitment.

Does this make sense?

[ghost]

More details on this in the ZIP In particular note the counterfeiting attack if the generator is malleable (basically, overflow can happen in the value field)

[cwgoes]

Then the Spend circuit only needs to be given the value base as input and not the token type, avoiding the blake2 hash in the Spend circuit. This is because the correct value base must be given in order to properly verify the note commitment.

To me, it seems like this works, since all note commitments must be initially created with a proof from the output circuit, which will check the group hash.

[ghost]

MASP checks the value base hash in the circuit.