4

This is a scenario I've come up with to help me understand key images.

Let's say I have Wallet 1 and Wallet 2. Wallet 1 has TXO A and TXO B. I send TXO A and TXO B as inputs to Wallet 2. TXO B was reduced to pay transaction fees. Then I send TXO A and the updated TXO B as inputs back to Wallet 1. TXO B was reduced further to pay transaction fees. What I'm left with that concerns me is TXO A.

Based on my rudimentary knowledge of key images, I know that a key image was generated as part of the first transaction (the send from Wallet 1 to Wallet 2). That key image, in layman's terms, says that Wallet 1 spent TXO A (and TXO B, of course), so it can no longer spend TXO A again.

But now TXO A is back in Wallet 1, unchanged (as far as I know) from its original glory. Will the key image be different the second time around, so that Wallet 1 is not prevented from spending TXO A again? Does the original key image have an effect on the ability of Wallet 1 to spend TXO A the second time?

(Please recall from the title that I'm interested in the ingredients - perhaps "variables" is the technical term - for how a key image is generated.)

254123179
  • 4,566
  • 4
  • 31
  • 57
scoobybejesus
  • 5,495
  • 18
  • 42

1 Answers1

4

When you send TXO A, it doesn't stay unchanged in wallet 2, it it now a new TXO A2 (with a one time address for wallet 2) that can't be linked with certainty to TXO A because of the ring signature.

According to the CryptoNote whitepaper, the key image is computed from the one-time key pair associated to the transaction output:

I = x*H(P)

where:

I is the key image
x is the one-time private key
P is the one-time public key (point P = x*G)
H is a deterministic hash function

If you try to spend TXO A a second time, the network will reject it because the key image for TXO A will already be in the known key images set. But when you spend TXO A2 (back to wallet 1), it will work fine because the key image for TXO A2 is different from the key image for TXO A (because these two TXOs are associated to different one-time key pair).

dEBRUYNE
  • 15,227
  • 17
  • 57
  • 114
glv
  • 3,334
  • 10
  • 15
  • That makes sense (well the words.. I'll need to dig into the whitepaper and the math more deeply), but I'm actually concerned with TXO A3, for sending from Wallet 1 a second time. Will x and P be the same in the key image spending TXO A3 as they were when spending TXO A, but H will be different? – scoobybejesus Oct 11 '16 at 15:13
  • You might be missing the one-time property. x and P are always different for different outputs. – Luigi Oct 11 '16 at 15:59
  • This answer is good as far as the "ingredients"; perhaps a different question would be in order for understanding them more fully, or maybe editing this question. A key image is simply an additional public key for x computed on a different base (a hash of the public key on base G). A ring signature signs for both public keys (P,I), but due to the multiple public keys (at mixin>0), it's unknown which one I belongs to. – Luigi Oct 11 '16 at 16:07
  • I did read "one-time." I don't understand how x and P have that property (I guess it means x and P are derived from my keys, but they aren't actually my keys), but I appreciate you enforcing that point, so at least now I have something specific to look further into. Thanks very much. – scoobybejesus Oct 11 '16 at 16:08
  • Ah! I was responding, and then you responded again before I hit enter. Those are more great details. If I can build upon these concepts, I may ask a new question. But this answer are your comments go a long way to answering my question. – scoobybejesus Oct 11 '16 at 16:11
  • @Luigi where did you learn that Monero's "ring signature signs for both public keys (P,I)"? This is in contrast to every ring signature scheme in literature ever used and would probably lead to an effective de-anonymising attack. – bekah Nov 25 '16 at 20:46
  • @bekah Probably just a poor use of terms on my part. It's only obvious which P I belongs to if there is only one member. – Luigi Nov 28 '16 at 16:42
  • @Luigi ohh I've understood what you're saying, P = xG and I = xH and these both look like public keys? I thought you were saying you had to submit P and I as public keys to the ring, in which case the ring signature would be irrelevant because ring I and signature I would be the same so you could just scan and find address pairs :D But that is not the case :) – bekah Nov 28 '16 at 16:46
  • 1
    No, no. You submit P and I, but P as part of a list of Ps, and I as the key image. :) They are both public keys, though. All curve points are a public key for some x and some generator (base) point. For example G is the public key for x^-1*P where P = xG. – Luigi Nov 28 '16 at 17:31