As I understand from the whitepaper, the sender picks random r to create one-time output public key P=H(rA)G+B, and the public transaction key R=rG is attached to the transaction data. Since any amount sent to the receiver needs to be split into denominations, I thought that the sender needs to perform this P generation step n times if the receiver's amount is split into n denominations. Thus, I'd expect R appearing n times in a transaction. However, I noticed on some blockchain explorers that only one such R (which I think is referred to as "one-time public key" on those sites) is shown per transaction. Am I misunderstanding something?

Here are examples of a transaction 1bedc82fed867eb50681c134df7f4c8c3606397ec00de4306930770cd260866e on blockchain explorers by chainradar and minergate.

I tried to find the answer in the previous posts and found some relevant ones such as this and this, but still couldn't find a definitive answer.

  • Good question. I always thought that the one-time addresses were the ones in front of each the outputs' amounts, named just "keys", and I still think that is what they are, but indeed, now that you mentioned it, I can't find a field in the transaction itself that carries the values R=rG.// The "One-time public key" from the blockchain explorers are not even in the "nice part" of the JSON printout of the transaction, but is rather stuck inside a long string of numbers in the beginning (I am printing in the daemon to see if the explorers had missed anything). – user141 Oct 28 '16 at 13:20

This question was cross-posted to Reddit and was answered by dEBRUYNE_1 citing luigi1111's article:

You may have noticed that this scheme only gives Alice one output for Bob per r, but with auto-denomination Monero and other Cryptonote coins have many outputs per transaction. To get different stealth addresses for each output, Alice (and Bob) append an "output index" (an output's position in the transaction: 0, 1, 2, etc.) to D before hashing it to create the secret shared scalar f. This is a bit of a clarification to Alice's step 2 on unlinkability. That is, while the shared secret D is already unlinkable to observers, appending an output index allows "unlimited" additional unlinkable outputs to be created from one shared secret (see point 3 in the hash section).

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.