As I (roughly) understand it, every tx output has a public amount Pedersen commitment and also the real amount (along with a blinding factor) is encrypted such that only the recipient can know it.

My question is twofold:

  1. What prevents the party creating the output from putting the wrong amount into the secret such that recipient is unable to generate the correct commitment when trying to spend it?

  2. If nothing prevents this, then how does the code handle this case once the receiving party receives it? This utxo would seem to be unspendable unless the recipient can somehow obtain or guess the true amount.

2 Answers 2


Just to avoid confusion: regarding the amount, the payee receives:

  1. A Pedersen commitment of the amount hidden with a blinding factor
  2. An encrypted representation of the amount

both the blinding factor and 2) are calculated via a diffie-hellman-like "secret" (aka both payer and payee -and only them- can calculate the "secret" and hence the unencrypted, actual amount and the blinding factor)

So the payee decrypting 2) can check the value is the right one for their deal, then having calculated also the blinding factor can check the Pedersen commitment binds to the same value (which is important because it's via the commitment that inputs and outputs balance are checked by the network ... but that's another topic...)

Perhaps it can help you (disclaimer: it's mine): https://www.getmonero.org/library/RctCheatsheet20210604.pdf

  • thx. I had a read of your infographic and I find this statement: "the payee verifies that output amount and C express the same value a (binding the payer/payee exchanged value to the one validated by the network), thanks to the -already documented- way by which amount and b are defined". So if I understand correctly, it is possible for the sender to create a different secret amount than committed amount. Thus, the recipient must check. What happens if the check fails?
    – danda
    Aug 15, 2021 at 6:23
  • I haven't checked Monero wallet reference code, but my strong believe (in the next few lines I'll try to explain why it's enough for me) is that the payee will refuse the tx, meaning it will not consider it a valid revenue for his service (?) sold to the payer. Given the commitments chain is where consensus and input/output balance is enforced, let's say that's the most important part. The payee cannot verify the amount from the pedersen commitment, even if it can calculate the binding factor: "aJ = C - bG" but he cannot get "a" from "aJ" because of DLP.
    – baro77
    Aug 15, 2021 at 10:04
  • So without a correct encrypted amount (giving an "a" matching "aJ = C - bG") the payee wallet DEFINITELY CANNOT know how many moneroj it has received so it cannot include them in its UTXOs. Wrong TX, full stop. From payer perspective he has burnt moneroj because key images will flag the input UTXO of the bad TX as already spent. I think that's why jtgrassie spoke about lack of incentive to do that, it's just a lose-lose opportunity
    – baro77
    Aug 15, 2021 at 10:10
  • your comment to jtgrassie answer push me to add something: my reduction to DLP could be a too strong argument because of "a" domain (8 bytes) and/or in case of an educated-guess of its value due to reasonable assumption. I guess a payee could try a brute force, maybe with the help of rainbow tables. However in general you don't know how difficult it would be for him... so why make his life so hard? When you speak about a side channel to postpone spendability, I wonder if you are thinking to something as a per-payee-vault. However this wouldn't work imho, because...
    – baro77
    Aug 15, 2021 at 16:20
  • ...we have said brute force could be effective sometimes, and when it did the vault would be broken (aka the payee could spend those moneroj before the payer reveals him the right amount).. That's not bad luck, it's just a consequence of how Pedersen commitments work, because their hiding property relies on the secrecy of both commited value (the amount) and of the blinding factor. I think mixed cases cannot be used to derive arguments, whichever the chosen direction would be. BTW thanks to have made me think about this stuff
    – baro77
    Aug 15, 2021 at 16:30
  1. A spender cannot use a different amount in the output commitment than is attached to the tx as the recipient would fail to decode and thus it wont be added to the wallet balance.

  2. It is prevented per the above point (there's no incentive to do this). Furthermore, note the mask and amount encoding/decoding is deterministic, so any attempt to tamper is futile.

  • ok, so "recipient would fail to decode" does not seem to prevent sender from doing it if desired. So does this mean that a sender can make the secret amount different from the committed amount, but that effectively burns the committed amount? In such a case, mIght it be possible for recipient to guess the committed amount (eg brute force) or perhaps sender tells them out-of-band, and then it can become spendable again? (perhaps I didn't grasp the significance of the mask, encoding, deterministic... )
    – danda
    Aug 15, 2021 at 6:34
  • The attached encrypted amount (not the Pedersen commitment) could indeed be forced to not decode, which means the wallet won't match the commitment (per my ref link) and the wallet will ignore. You cannot really say it's "burnt" as the sender could have the information to later pass to the recipient (shared out-of-band, as you mention).
    – jtgrassie
    Aug 15, 2021 at 16:36
  • The significance of the mask and amount encoding being deterministic is merely to point out the correlation to the shared secret.
    – jtgrassie
    Aug 15, 2021 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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