Trying to understand how RCTTypeSimple works

Question

We cannot use MLSAG and sign all inputs at once; as all real inputs would need to share the same index.

The partial solution is to use a ring signature on each input separately.

We need to ensure that the inputs balance out the outputs.

To illustrate how I believe it works, I will use an example:

Definitions

A Pedersen commitment P is defined as P = bG + aH

• where a is the amount and b is blinding factor.
• Discrete Log is unknown with respect to both G and H.

Example

Alice wants to send 5XMR to Bob.

Alice uses two inputs:

• Input1 has amount 2XMR and the commitment C1 = xG + 2H

• Input2 has amount 3XMR and the commitment C2 = yG + 3H

Alice creates an output addressed to Bob:

• Output1 has amount 5XMR and the commitment C3 = kG + 5H

Alice creates new pseudo-commitments for each input, whereby the amount stays the same:

C'k would denote the input associated with Ck.

• C'1 = x'G + 2H
• C'2 = y'G + 3H

Alice then calculates a commitment to zero for each input:

• Commitment to Zero for input 1 would be C1 - C'1 = (x - x')G = z₁G

• Commitment to Zero for input 2 would be C2 - C'2 = (y - y')G = z₂G

The sum of all k' scalars are chosen in such a way that they cancel out the sum of the blinding factors of k.

This means that:

(x' + y') - (x + y) = 0

This would allow us to prove that the input amount equals the output amounts because:

C1 + C2 - (C'1 - C'2) = (x + y)G + 5H - (x' + y')G + 5H = 0 (fee is omitted for simplicity).

At this point, someone verifying this transaction could do the sum(Ck) - sum(C'k) = 0 for all inputs, maybe checking that Ck and C'k are different.

Question: This would not be enough because the scheme does not end here, why?

Moving on:

Since each input is signed individually, I will focus on input1 only, as it is the same for input2.

As mentioned above the Commitment to Zero for input 1 would be C1 - C'1 = (x - x')G = z₁G

*Alice is now attempting to sign input1.

She gathers a set of decoy outputs and their commitments. The one-time public key associated with each output is used as mixins.

In 5.7.2, still I mis-understand why z₁G is being used in the ring.

For a ring signature, we need a message m and signing key k and a set of public keys Pk where k=x is the public key corresponding to the signing key k. If this is correct, then what is the purpose of z₁G in this ring signature?

• I cannot seem to decouple the signing process from proving that the inputs and outputs balance out, mainly because the signing process uses zG for some reason.

Answer 1

I'm going to focus on this following part of your question as opposed to pointing out the issues in your math. The math used in Monero is covered very well, in full detail, in both Zero to Monero and MRL-0005.

But I think from this part of your question, and your other recent questions, here is your key problem:

I cannot seem to decouple the signing process from proving that the inputs and outputs balance out, mainly because the signing process uses zG for some reason.

So let's take a step back. An MLSAG signature needs be constructed with a ring of input keys and commitments (real and decoys), then signed, to prove that the spender indeed owns one of the input keys in each input ring. The network also needs to be able to verify this, but crucially, without knowing which input in the ring is the actual input being spent.

We also need a way to hide transaction amounts from the rest of the network - only the sender and receiver should be able to decode the amounts. The Pedersen commitments fulfill this task, the amounts get blinded.

Now we also need to prove the sum of the real inputs being spent minus the sum of the outputs being created is zero and that they fall within a positive range.

The commitment to zero is used for both 1) validating the sum of the real inputs being spent minus the sum of the outputs being created is zero, but also 2) proving that an input being spent from an input ring is owned by the sender, without disclosing which input is the real input.

When speaking specifically about validating the real input amounts minus the output amounts is zero, recall that verifiers have a bunch of input commitments & public keys (one real, the rest decoys) and one or more outputs that need using in the calculation. They need to know that one of the input commitments used in the calculation is real. Clearly they cannot use all of them.

Finally, proving the amounts are all positive is the job of the range proof.

Hopefully that clears up some of your confusion. Perhaps reading specifically pages 8 & 9 of MRL-0005 may also help you, along with the math.

Update

Having digested a little more of your question, another thing jumps out at me that you seem to have missed:

This would not be enough because the scheme does not end here, why?

Everything proceeding this part of your question, used the assumption (incorrectly), that there were only two inputs (the real ones). You miss the fact that if 2 inputs are being spent, there are actually 2 input rings of inputs. Each ring contains one real input being spent, the rest are decoys. Hopefully everything I detailed above helps you see why the scheme doesn't simply "end here", so to speak.

Monero uses a collection of interdependent pieces and it's well worth understanding the concepts behind these pieces and how they relate to each other before jumping head-first into the math.