4

I understand one can have two commitments P and Q, and show the world that P - Q = 0 - communicating the commitment to only the recipient. In fact, it can be done with many input commitments P1 ... Pn. However, how do the other commitments remain hidden?

The user can take P1 ... Pn, when he really only knows the commitment key for P1, and then generate output Q1 ... Qn with sum(P) = sum(Q). However, doesn't that invalidate the random P2 ... Pn he was trying to mixin with? They still need to be able to spend their commitments using the private keys they know for the old Ps.

I just don't really understand how Pedersen Commitments integrate with mixins.

Bounty:

Under the original scheme, We have the following:

  1. Take N input transactions that hold the same amount of Monero
  2. Prove I have the private key for one of them using Ring Signatures
  3. Provide a keyImage that's never been used before, and prove that it is equal to privateKey * Hash(PublicKey) for one of the N transactions. This is done without revealing which privateKey was used.
  4. Provide M output transactions, signed to prove that you approve of them, such that the sum of the output amounts is equal to the common amount used in the input transactions.

The total state changes resulting from steps 1-4 is that One KeyImage is stored and cannot be used again, and M output transactions are stored for later usage.

(Of course, the proofs are stored too but are never used ever again except for new nodes downloading the blockchain. Thus, I do not include them in "state changes")

Now, my final question: How does this work with Pedersen Commitments? What exactly is the input->output relation for a transaction under RingCT, along with state changes? I want to be able to read it in a format equivalent to the step-by-step format I gave for pre-RingCT transactions. Bounty for whoever does this :)

I ask this because, if each Pedersen Commitment holds a different value, how could it ever be so that the Pedersen Commitment remains secret? Isn't it obvious which one I used? If I consumed several commitments, then what happens to them if I didn't own them? I just don't understand. I would like a more explicit explanation.

UPDATE

Everything written under "Bounty" can be ignored. Back to the original question, regarding mixins. I understand most of it now, due to "Can someone walk me through a simple example to explain how RingCT works?". However, this explanation does not discuss how the Pedersen Commitment proved is not used twice. I understand it's possible to introduce a second key image to prevent double usage of the pedersen commitment, but is this the most space-efficient method? What does Monero use? (Bounty is redesignated for the answerer of this question.)

Update 2

Using a key image on Pedersen wouldn't solve the problem, because I could use a pedersen from someone else's transaction since I know the pedersen key for any transactions I send out. I could then steal their pedersen commitment. However, the realization is simple. I left it in a comment to "Can someone walk me through a simple example to explain how RingCT works?"

Nicholas Pipitone
  • 101
  • 6

2 Answers2

3

A commitment is published publicly for every output created in a transaction, and thus every input in a transaction also has a known commitment.

Commitments are public. It's only the amount and blinding factor that are kept private between the creator of the output (sender) and the output's recipient.

The MLSAG ring signature proves that there is a set of inputs and outputs such that P - Q = zG where zG is the commitment to zero, and only someone that knows all the blinding factors can prove knowledge of z (and the signature proves that without disclosing the value of z publicly).

knaccc
  • 8,518
  • 17
  • 23
0

For the original question:

Say you have a transaction T with commitment P. You generate a new commitment P_2, and then prove you know z s.t. P - P_2 = zG. Thus, the amounts of P and P_2 are equivalent, or else P - P_2 would be equal to yG + (amount1 - amount2)H = zG. Discrete log between G and H prevents you proving that you know that z. Then, you use P_2 as your input commitment and create an output commitment O where everyone can verify that O - P_2 = 0.

You can then use a key image for which pedersen commitment you used, to prevent using the same pedersen commitment twice.

The Pedersen Commitment must be from the same private key that your key image came from, by the nature of the borromean ring signature (Read more here: Can someone walk me through a simple example to explain how RingCT works?).

Nicholas Pipitone
  • 101
  • 6