# How to distinguish between the amount of the real input amount and the decoys

Since every transaction has multiple decoys from previous transactions that are connected to it (while only one is real), how does the user link the amount that is linked to the "real" transaction?

EDIT: What is the math behind discarding the unnecessary "decoy" values, when checking the Pedersen commitment (of our output and the real inputs).

Thanks.

Since every transaction has multiple decoys from previous transactions that are connected to it (while only one is real), how does the user link the amount that is linked to the "real" transaction?

Firstly, all the decoy outputs are "real", they are real outputs created by previous transactions.

Second, the whole point of the decoys is to not be able to determine which is the real output being spent. The signer is proving they own one in each set/ring, but not which.

Third, the amounts for the generated outputs are encrypted in the transaction `ecdhInfo` field. Thus to obtain the decoy encrypted amounts, you grab them from the `ecdhInfo` of the transactions that created those outputs.

EDIT: What is the math behind discarding the unnecessary "decoy" values, when checking the Pedersen commitment (of our output and the real inputs).

There is no "discarding the unnecessary "decoy" values". I suggest reading 5.4 in Zero to Monero which goes into greater detail, but to summarize: The input commitments included in the tx, are actually pseudo output commitments. These pseudo output commitments use the same original amounts but use different binding factors. As the sender knows the difference between the commitments, they can use this as the commitment to zero and sign.

Thus

``````     C = xG + aH
C' = x'G + aH
C - C' = (x - x')G
z = x - x'
``````

Where `x'` is a new binding factor, `C'` is a pseudo output commitment and `z` being the private key of our commitment to zero.

With regards to your comment of "checking the Pedersen commitment", I presume you are referring to checking the sum of inputs and outputs is zero. For this, one is checking the sum of the pseudo output commitments (the inputs) minus the sum of the tx output commitments.

Of course one also needs to ensure none of the values are negative, and this is the purpose of the range proof (see Zero to Monero 5.5).

• Thanks, buy my question was about the mechanism/math that let us to discard the decoys' encrypted values from the calculation.
– GBB
Apr 17, 2020 at 1:25
• There is no "discard the decoys' encrypted values". I have added an update based on your edit and hope that is what you are trying to understand. Apr 17, 2020 at 1:35
• Thanks again! I don't understand why the signer can know \$x-x'\$, since x is unknown and to get \$(x-x')\$ from \$(x-x')G\$ is hard as DLP
– GBB
Apr 18, 2020 at 4:54
• Each mask (binding factor) used to be (pre v2BP) stored in `ecdhInfo`. Now however, the masks are deterministically derived. Apr 18, 2020 at 6:56
• Deterministically derived: en.wikipedia.org/wiki/Deterministic_algorithm. For the pseudo output commitment `x`s, they are created / worked-out in a deterministic way. Obviously one cannot calculate `x` from `xG`, but for the purposes of the pseudo output commitments, all that's required is that anyone can create the `x`s when constructing the pseudo out commitments. As I said, these `x`s used to be attached in `ecdhInfo`, now they are deterministically derived instead, which saves tx space. Apr 18, 2020 at 20:40