03:36:14 <m-relay> <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
03:40:08 <m-relay> <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
08:31:38 <m-relay> <m​onerobull:monero.social> hey, anyone here? i have someone with a very weird claim. probably nothing but potentially serious
08:32:58 <sech1> What claim
08:34:26 <m-relay> <m​onerobull:monero.social> their gui wallet shows an outgoing transaction worth 18446743 XMR
08:36:22 <sech1> That's suspiciously close to 2^64 atomic units
08:36:28 <sech1> must be a bug somewhere
08:36:56 <m-relay> <m​onerobull:monero.social> 18446743,66343055293
08:38:22 <m-relay> <m​onerobull:monero.social> https://old.reddit.com/r/monerosupport/comments/1ckqshc/did_not_know_i_was_that_rich/
08:38:56 <m-relay> <m​onerobull:monero.social> they gave me a confirmed transaction ID as well
08:39:07 <sech1> That's 0.410278998686 XMR less than 2^64
08:39:15 <sech1> which is a more reasonable number
08:39:40 <sech1> Somehow somewhere somethig wrapped around 2^64
08:39:46 <m-relay> <m​onerobull:monero.social> lol, and that's how you de-anon a xmr tx /s
08:41:05 <m-relay> <m​onerobull:monero.social> ive asked them to restore in featherwallet
08:44:52 <sech1> Maybe a display bug, maybe corrupt wallet file. Restoring wallet from seed will show the real amount in that transaction
08:46:02 <m-relay> <m​onerobull:monero.social> with them writing about weird node stuff, that is the most likely case, yes
08:46:18 <m-relay> <m​onerobull:monero.social> thanks for taking the time :)
17:54:29 <m-relay> <e​veroddandeven:monero.social> https://github.com/monero-project/monero/blob/release-v0.18/src/wallet/wallet2.cpp#L10498
17:56:17 <m-relay> <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)
17:58:58 <m-relay> <e​veroddandeven:monero.social> Now it is working only with primary address
18:01:00 <m-relay> <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
18:02:13 <m-relay> <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
18:02:52 <m-relay> <e​veroddandeven:monero.social> // Subaddresses aren't supported in mymonero/openmonero yet. Roll out the original scheme:
18:02:53 <m-relay> <e​veroddandeven:monero.social>   //   compute D = a*R
18:02:55 <m-relay> <e​veroddandeven:monero.social>   //   compute P = Hs(D || i)*G + B
18:02:57 <m-relay> <e​veroddandeven:monero.social>   //   compute x = Hs(D || i) + b      (and check if P==x*G)
18:02:59 <m-relay> <e​veroddandeven:monero.social>   //   compute I = x*Hp(P)
18:03:14 <m-relay> <e​veroddandeven:monero.social> This is a comment in wallet2::light_wallet_generate_key_image function
18:04:48 <m-relay> <r​ucknium:monero.social> jeffro256: wallet.cpp is so long that GitHub doesn't fully index it for searching :)
18:10:39 <m-relay> <s​yntheticbird:monero.social> The side view in vscode just crashed sometimes
18:11:01 <m-relay> <s​yntheticbird:monero.social> this file is just so beefy that's hilarious
22:16:07 <m-relay> <j​effro256:monero.social> Also IIRC that code was removed by tobtoht from the master branch anyways
22:54:31 <m-relay> <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
22:55:15 <m-relay> <j​effro256:monero.social> Instead use a map of subaddress spend pubkeys -> subaddress indices with `cryptonote::is_out_to_acc_precomp`
22:56:25 <m-relay> <j​effro256:monero.social> Well that's if you have the pubkey available on you, which you might not
22:56:59 <m-relay> <j​effro256:monero.social> Are you using this function in the context assuming you already know your owned enotes up to that point?
23:00:37 <m-relay> <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>
23:00:39 <m-relay> <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
23:03:20 <m-relay> <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
23:03:57 <m-relay> <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