<j​effro256:monero.social> You're going to have to be more specific as to what you want, as well as give us a link to this function since it doesn't appear to be in the core repo

<j​effro256:monero.social> The key image for a onetime address K = kG is K~ = k Hash_to_point(K), regardless of whether you use subaddresses, main addresses, or your own custom addressing scheme. So once you use your spend key to determine the private key for an owned enote, you compute the key image, then filter all the on-chain key images from the LWS and see if you encounter a key image that you previously computed

<m​onerobull:monero.social> hey, anyone here? i have someone with a very weird claim. probably nothing but potentially serious

What claim

<m​onerobull:monero.social> their gui wallet shows an outgoing transaction worth 18446743 XMR

That's suspiciously close to 2^64 atomic units

must be a bug somewhere

<m​onerobull:monero.social> 18446743,66343055293

<m​onerobull:monero.social> old.reddit.com/r/monerosupport/comm…ckqshc/did_not_know_i_was_that_rich

<m​onerobull:monero.social> they gave me a confirmed transaction ID as well

That's 0.410278998686 XMR less than 2^64

which is a more reasonable number

Somehow somewhere somethig wrapped around 2^64

<m​onerobull:monero.social> lol, and that's how you de-anon a xmr tx /s

<m​onerobull:monero.social> ive asked them to restore in featherwallet

Maybe a display bug, maybe corrupt wallet file. Restoring wallet from seed will show the real amount in that transaction

<m​onerobull:monero.social> with them writing about weird node stuff, that is the most likely case, yes

<m​onerobull:monero.social> thanks for taking the time :)

<e​veroddandeven:monero.social> github.com/monero-project/monero/bl…v0.18/src/wallet/wallet2.cpp#L10498

<e​veroddandeven:monero.social> I want to give another parameter (crypto::subadress_index) to that function and make something like this bool wallet2::light_wallet_key_image_is_ours(const crypto::key_image& key_image, const crypto::public_key& tx_public_key, uint64_t out_index, crypto::subadress_index subaddress_idx)

<e​veroddandeven:monero.social> Now it is working only with primary address

<e​veroddandeven:monero.social> I'm still not skilled with monero cryptography functions, and I do not know the right parameters to cryptonote::generate_key_image in order to generate an output key image using subaddress keys

<e​veroddandeven:monero.social> I'm still not skilled with monero cryptography functions, and I do not know the right parameters to crypto::generate\_key\_image in order to generate an output key image using subaddress keys

<e​veroddandeven:monero.social> // Subaddresses aren't supported in mymonero/openmonero yet. Roll out the original scheme:

<e​veroddandeven:monero.social> // compute D = a*R

<e​veroddandeven:monero.social> // compute P = Hs(D || i)*G + B

<e​veroddandeven:monero.social> // compute x = Hs(D || i) + b (and check if P==x*G)

<e​veroddandeven:monero.social> // compute I = x*Hp(P)

<e​veroddandeven:monero.social> This is a comment in wallet2::light_wallet_generate_key_image function

<r​ucknium:monero.social> jeffro256: wallet.cpp is so long that GitHub doesn't fully index it for searching :)

<s​yntheticbird:monero.social> The side view in vscode just crashed sometimes

<s​yntheticbird:monero.social> this file is just so beefy that's hilarious

<j​effro256:monero.social> Also IIRC that code was removed by tobtoht from the master branch anyways

<j​effro256:monero.social> everoddandeven: if you plan on using this code for production, I wouldn't recommend passing an explicit subaddress index since that would mean that you would be rederive for every single subaddress generated

<j​effro256:monero.social> Instead use a map of subaddress spend pubkeys -> subaddress indices with `cryptonote::is_out_to_acc_precomp`

<j​effro256:monero.social> Well that's if you have the pubkey available on you, which you might not

<j​effro256:monero.social> Are you using this function in the context assuming you already know your owned enotes up to that point?

<j​effro256:monero.social> When you scan with subaddresses, you basically have to know which key images you own beforehand, otherwise you would have to rederive the pubkey N times for each on-chain key image, where N is the number of subaddresses. This is because to tell which subaddress to use to find the private key of the onetime enote, you need to subtract the derivation from the onetime address. The on<clipped message>

<j​effro256:monero.social> etime address is not associated with the key image on-chain (otherwise Monero would be traceable), so if you don't already have the onetime address with you, then you have to try against every single subaddress you've generated

<j​effro256:monero.social> When you subtract the derivation from the onetime address, you get a subadress spendkey, which is looked up in a map normally which means we only have to derive the key once per owned enote. The scanning code then assumes we already calculated the key images in advance

<j​effro256:monero.social> However, if you wanted to check just against the one subaddress for learning sake, I could write a gist that would do that