How does RingCT work with / without coefficients?

Question

I was trying to get more information on how RingCT works, I found the thread I linked to below here on the stack exchange. In the other thread, the most upvoted answer explains it as a coefficient, but then others say there is no coefficient for ringCT, so how does it work if there's no coefficient there?

I quote @samsunggalaxyplayer's question which I would like the answer to as well:

"If RingCT does not use coefficients, then what does it use? Is there a noticeable difference in average reported amount of a transaction of 10 XMR and 10000 XMR?"

I appreciate your help understanding this!

Here is the link to the older thread I was referring to: ELI5: How does RingCT work?

Answer 1

The equation is rct = x*G + a*H(G) where * indicates scalar point multiplication in the ed25519 curve, x is the "mask", G is the base point of the curve (group generator), a is the actual amount, and H(...) is a function that returns a point on the curve based on the cryptographic hash of the point G. The "mask" (x) is randomly generated so there is no relationship between the amount and the rct value published (assuming a quality RNG); rct is the result of adding the real value to a random value.

The coefficient comment probably came from the x*G portion, but the masking value is not really a coefficient of the real value.

Answer 2

To supplement Lee Clagett's answer, the construction

C = x*G + a*H

(called Pedersen Commitment) is needed for the original Confidential Transactions scheme proposed by Greg Maxwell. RingCT is a way to adapt the CT scheme to Monero by combining it with ring signature.

When you construct a transaction in Monero, you're going to mix your Pedersen Commitment C to some amount a with others' commitments to different (whatever, you don't know) amounts, and you need to prove to the network that the sum of the inputs and the sum of the outputs (plus the fee) are the same. The key idea to achieve this is as follows: you generate another commitment to the same amount using a different mask:

D = y*G + a*H

The important thing here is that you know the secret key of the pubkey defined by subtracting one commitment from the other:

Q = D-C = (y-x)*G = z*G

(Note that no one is supposed to know the secret key of H, so there cannot be the secret key of a Pedersen Commitment unless the committed amount is zero.)

You then define the pubkeys for other fake commitments Ci in a similar manner as Qi = D-Ci. Now you can form a ring signature over a set of pubkeys

{Q, ..., Qi, ...}

using the secret key z. This way, each ring signature is associated with another commitment D (called pseudo output in the codebase), and the network checks if the sum of the pseudo outputs of all the input ring signatures equals the sum of all the output commitments plus the fee.

See also: Can I manually check consistency of Pedersen Commitments in RingCT?

Answer 3

The other two answers are good in that they cover the part about Pedersen commitments, and how those are used to check that the sum of the amounts in the outputs created doesn't exceed that of the sum of the real inputs consumed (the homomorphic cryptography part).

On the other hand, since the amounts involved are being taken from a finite range where modular arithmetic is being used, the sender could still use "negative" numbers to produce very large output amounts. To prevent this, range proofs are needed as well, and those too are implemented as well in ringCT's code.

I don't have a very deep knowledge of how they are implemented in Monero's code specifically, but the gist of it is this (I am writing this all from memory, so there might be some imprecisions):

The amount a being commited is broken down into its constituting digits. Imagine in base 10, each digit would be a number between 0 and 9.

Now for each digit's position, and for each of the ten digits a public key is created. The user knows the private keys corresponding to the actual digits of a in each position, and uses that to produce a ring signatures involving those 10 public keys, signing with the actual digit key in each position.

In reality there is a trade off between the number of digits used to represent a number (each requires an extra ring) and the ring sizes themselves, so that there is an optimal way to represent a. I believe that this turns out to be base 4, instead of base 10.

See Borromean ring signatures.