00:00:24 <boned4ddy> ah okay that makes sense
00:00:25 <boned4ddy> thanks
00:12:29 <boned4ddy> so one thing im confused about is how to check the incoming balance of of integrated address. Im guessing you first split the integrated address, and then you have the actual address that has the funds in it. upon which you would call `GetBalance` and then filter through every sub address until you get the one you want??
00:13:11 <boned4ddy> given that when you create the integrated address you can specify the standard address, how would you know which account index to lookup whne calling `GetBalance`
00:13:37 <boned4ddy> does making an integrated address *always* use account index 0?
00:13:53 <selsta> integrated addresses always use 0,0 index
00:13:59 <selsta> account 0 address 0
00:14:02 <boned4ddy> good to know, thanks
00:15:27 <boned4ddy> so whats the point of specifying the "standard address" when creating an integrated address if it always uses 0,0 index
00:16:37 <selsta> which function are you talking about specifically?
00:17:43 <boned4ddy> https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#make_integrated_address
00:18:05 <selsta> it’s optional
00:18:39 <selsta> it can also be used to convert generic address + payment_id -> integrated address
00:26:07 <boned4ddy> okay then i think i might be encountering a bug because i can send payments to integrated addresses, and then when i do `payments <payment_id>` from monero-wallet-cli it doesnt show me any payments
00:26:38 <selsta> does the payment show up when you do show_transfers?
00:27:16 <boned4ddy> you can see it on xmrchain
00:27:16 <boned4ddy> https://testnet.xmrchain.net/search?value=5fa93c5c40e9841fe0982cecf921a1a187a89ca2e32a9d2feffb9912e5a5f174
00:27:39 <selsta> does it show up if you enter `show_transfers`?
00:29:30 <boned4ddy> yes
00:30:16 <boned4ddy> heres the output https://gist.github.com/bonedaddy/6cecad4166d5305e6687268d848f0c0a
00:30:33 <boned4ddy> output from the `payments` command that is
00:43:47 <selsta> yea could be a bug, I’m not familiar with the payments command
00:43:55 <selsta> it interprets it as a long payment ID
00:45:32 <boned4ddy> yea it shows a padded payment id so this definitely seems like a bug
00:45:41 <boned4ddy> what is the best place to file a bug report
00:46:41 <selsta> https://github.com/monero-project/monero/issues/new
12:43:22 <selsta> vtnerd_: opened an issue on the monero-lws repo, still having build issues
13:03:51 <iDunk> selsta: Does something like this happen on Mac ?  https://paste.debian.net/hidden/01ad1743/
13:11:42 <selsta> iDunk https://www.irccloud.com/pastebin/Q9nBb4ho/
13:14:50 <iDunk> I get an "Error fetching paste". Anyway, I must have built release-static. cmake configures fine after rebuilding monero. monero-lws fails linking though, with several libs involved, but I don't have time to investigate right now.
13:15:06 <iDunk> Ah, got the paste now.
13:33:03 <iDunk> It builds here after shifting some vars around  https://paste.debian.net/hidden/54860971/
13:45:40 <grydz> Hello everyone, I'm still investigating why CLSAG signature is not verified by the testnet node using a Ledger Nano. The function verRctCLSAGSimple() return false because c != c1 but no exception is raised: https://github.com/monero-project/monero/blob/master/src/ringct/rctSigs.cpp#L939
13:46:08 <grydz> Here are the logs of the CLI in debug mode: https://gist.github.com/grydz/a29dd23daca66694b8e227ca181f6e4c
13:48:52 <iDunk> selsta: does this make any difference (L9) ?  https://paste.debian.net/hidden/5dfb2a3b/
13:50:20 <selsta> iDunk: that works, thanks
13:50:26 <iDunk> Yw
13:50:33 <selsta> now it says `Could not find LIB_PATH using the following names: unbound`
13:50:39 <selsta> most likely due to it searching for vendored unbound
13:50:40 <moneromooo> Where in that paste is the relevant trace ?
13:51:17 <iDunk> I use vendored unbound. I'll try installing libunbound-dev.
13:52:26 <moneromooo> verRctCLSAGSimple shold be run in the daemon, not the wallet.
13:52:37 <moneromooo> Or are you running it in the wallet for sanity checking ?
13:53:47 <grydz> Sure but using gdb I'm able to see that the return value is false.
13:55:04 <grydz> here is the error on the daemon: verRctMGSimple/verRctCLSAGSimple failed for input 0
13:55:26 <moneromooo> And the daemon is still accepting the tx ?
13:55:42 <grydz> No: tx used wrong inputs, rejected
13:56:01 <moneromooo> Oh. Phew.
13:56:19 <moneromooo> So what's the problem then ?
13:56:33 <moneromooo> Just that you generate bad txes ?
13:56:41 <sarang> Are the correct input commitments and offsets being passed into the function as expected?
13:56:49 <sarang> If they are wrong, the function will (correctly) fail to verify
13:56:57 <sarang> If they are correct, then something else is afoot
14:00:11 <grydz> Can't figure out how it would have been verified when I was doing the hardfork manually on stagenet...
14:02:06 <sarang> Wait, so it verified before?
14:02:12 <sarang> I might be misunderstanding the exact circumstances here
14:02:49 <moneromooo> What I did before to debug that kind of thing is run verification right after generating the proof, and logging the inputs and outputs.
14:03:17 <grydz> Before testnet hardfork occured, I was working with my own daemon on stagenet with hardfork v13.
14:03:22 <moneromooo> That verification will almost certanly succeed. THen also log in the daemon, see what inputs are different.
14:07:03 <grydz> Where in the code would you do that?
14:07:13 <sarang> Yeah, if it verified before, some inputs must be different
14:07:45 <sarang> Of course, if you're running on a different chain, the inputs _will_ be different and it won't verify on another chain...
14:07:48 <sarang> if that's the situation here
14:08:00 <moneromooo> Right after: rv.p.CLSAGs[i] = proveRctCLSAGSimple...
14:08:08 <sarang> (inputs are looked up by an index)
14:15:43 <selsta> iDunk: with vendored unbound: https://paste.debian.net/hidden/4677dbac/
14:15:55 <grydz> sarang, sure but the part of the code related to HW is doing anything related to those indexes
14:16:22 <selsta> probably clang / gcc differences
14:16:30 <grydz> moneromooo, good idea!
14:19:38 <iDunk> Could be. It builds here with and without vendored unbound.
14:20:25 <grydz> (*is not doing anything related to those indexes)
14:21:33 <sarang> OK, so in that case it's probably worthwhile as moneromooo said to see what inputs to the verifier are different
14:21:44 <sarang> They must be, or else something is very wrong with the universe...
14:21:58 <sarang> If the input commitments are different (or the offsets), then that's the problem
14:22:02 <sarang> not the verifier
14:22:11 <sarang> (I would be surprised if the verifier logic were flawed at this point)
14:23:14 <grydz> I'm pretty sure it's not the verifier ;)
16:31:54 <rusty_nick> Hi, was there any attempt to port monero-cpp to rust?
16:38:45 <sarang> grydz: any news?
16:39:51 <moneromooo> Anohter trick I used is to set all the random keys to identity. Helps when comparing two implementations to see where the various steps start dirverging.
16:40:22 <moneromooo> Might not be very useful when comparing with a HW wallet though, you might not be able to get at these intermediate values...
16:41:52 <sarang> I'd think a good starting place is to see what output commitments and offsets are being passed in
16:42:10 <sarang> If it's not getting the right non-signature inputs, the verifier will fail
16:55:56 <grydz> not yet, idk why I never enter in verRctCLSAGSimple() while doing a transfer in monero-wallet-cli...
16:56:28 <grydz> It seems I need to compile again, I'm not able to put a breakpoint on my modification :(
16:57:15 <grydz> I also tried to use `sweep_single()` on different key images
16:57:17 <grydz> just in case.
16:57:43 <grydz> *sweep_single command
17:23:12 <grydz> Ok great! Adding this line:
17:23:14 <grydz> bool b = verRctCLSAGSimple(full_message, rv.p.CLSAGs[i], rv.mixRing[i], pseudoOuts[i]);
17:24:09 <grydz> after this line: https://github.com/monero-project/monero/blob/master/src/ringct/rctSigs.cpp#L1229
17:24:53 <grydz> result in returning false
17:26:44 <moneromooo> Do tests pass ?
17:28:26 <grydz> Haven't run any test yet.
17:37:29 <sarang> OK, so that confirms the verifier fails, which was expected I guess
17:37:44 <moneromooo> I did not expect it.
17:37:59 <sarang> ?
17:38:07 <sarang> grydz had already indicated the verifier was failing
17:38:34 <moneromooo> OK. Fine. I did expect the verifier to fail right after the generator :)
17:38:37 <moneromooo> not*
17:39:46 <grydz> But in my logs: ASSERT EQ OK: clsag_sign: s: 9aa5f4654c1dc2beead602ed7e790b827411e3648150ca7a2c64c1307ac15e02
17:40:28 <sarang> Oh I see what you mean
17:40:33 <sarang> It's failing _immediately_
17:41:33 <moneromooo> Maybe bad keys (or not in the main subgroup) are fed to the generator.
17:41:38 <grydz> It means at least that clsag_sign() using HW is the same as in the software implementation?
17:41:59 <moneromooo> Or unmoduloed scalars.
17:42:26 <moneromooo> I do not understand that question.
17:42:40 <grydz> https://github.com/monero-project/monero/blob/master/src/device/device_ledger.cpp#L2271
17:47:49 <grydz> I'm trying to compare values outputed by the software implementation device_default with the one in device_ledger
17:57:04 <grydz> I guess it would help to see if a scalar is unmoduled