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?"

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).

  • But wouldn't the blinding factors be unknown for mixins? I'm not understanding the mixin part of it. What does "Proves that there is a set" mean? Does that mean "Proves there exists at least one subset"? I'm not even sure what the exact inputs and outputs are of a transaction using ringCT, which is also causing confusion. I understand vanilla mixin, but not the commitments part. – Nicholas Pipitone Nov 12 '18 at 22:56
  • @NicholasPipitone Only the creator and recipient of an output will know the blinding factor for that particular output on the blockchain. That applies whether we're talking about the real input being spent or a decoy/mixin input. – knaccc Nov 12 '18 at 22:59
  • Is the recipient also given z? Ive mostly seen (P - Q) = 0 and this zG is starting to make more sense. I was wondering, "Well, can't I clearly see which difference is equal to 0?" – Nicholas Pipitone Nov 12 '18 at 23:02
  • @NicholasPipitone z is the sum of input blinding factors minus the sum of output blinding factors. Since the sender of a transaction owns the inputs and so knows the input blinding factors, and knows the output blinding factors because the sender is deciding those blinding factors, the sender can easily calculate z. – knaccc Nov 12 '18 at 23:05
  • 1
    The sender doesn't need to know all of the blinding factors. The sender only needs to know the blinding factors of the real inputs being spent in order to form a valid MLSAG signature. You should read more into MLSAG to find out more. – knaccc Nov 12 '18 at 23:07
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?).

  • Actually, what's the point of the key image protecting the public key of the transaction anymore? You can just use the commitment in the key image. You dont actually care if you double spend the public key, you only care if you double spend the commitment. Whoops I think I solved it. – Nicholas Pipitone Nov 16 '18 at 2:01
  • Wait nvm, the sender also knows the pedersen private key so it would be bad if the sender clould kill the image after spending the coin. I still don't know how it works – Nicholas Pipitone Nov 16 '18 at 2:11
  • "The Pedersen Commitment must be from the same private key that your key image came from". This is not correct, the private key of an output is not related to the blinding factor of any Pedersen Commitment. – knaccc Nov 23 '18 at 13:26
  • @knaccc Yes, ik, that's not what I meant. I was referring to the note that the Pedersen Commitment must be associated with the private key that you used to generate the signature. In the original CryptoNote algorithm, you check the sum of the "c" values against the hash, so the private key you signed with and the key image you gave could be totally different. Before ringCT, all input amounts were the same, so no one cared. However, with the new algo of hash of i gives a seed for i+1, it means the key image of i cannot be combined with the pedersen commitment of j because it'll break the loop. – Nicholas Pipitone Nov 23 '18 at 23:54

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.