02:52:00 <lza_menace[m]> howdy
02:52:22 <lza_menace[m]> i have a PR if someone can help me open it on the repo
02:52:43 <lza_menace[m]> it's small and dumb, but my first time working on c++ and monero core....im proud of it :D
02:52:45 <lza_menace[m]> https://github.com/monero-project/monero/compare/master...lalanza808:lock-loop-counter
02:59:08 <lza_menace[m]> https://github.com/lalanza808/monero/pull/1
03:01:11 <JohnLee[m]> 1
03:01:19 <selsta> hi
03:02:06 <selsta> lza_menace[m]: will open it
03:03:10 <JohnLee[m]> I am the author about https://github.com/monero-project/monero-gui/issues/3479, I'm here to ask you guys, need help, thank you
03:03:11 <selsta> lza_menace[m]: you can also message luigi to add you to the repo
03:03:24 <selsta> JohnLee[m]: did you try with subaddress-lookahead?
03:05:31 <JohnLee[m]> @sels
03:05:32 <JohnLee[m]> I will try, this --subaddress-lookahead 200:1000, must the index of these transaction addresses be within this range?
03:06:07 <selsta> no, the syntax is --subaddress-lookahead major:minor
03:06:23 <selsta> default if 50:200, if you set it to e.g. 200:1000 it will scan for more subaddresses
03:06:31 <selsta> default is*
03:09:36 <selsta> JohnLee[m]: please stay in the channel, more devs should be online in ~6h
03:10:11 <JohnLee[m]> Ok, I mean, for example, the sub-address offset of the output address of my transaction is 1000, that must be 500:2000, right?
03:11:29 <selsta> no, 1000 means that it will scan for 1000 subaddresses in advance
03:12:07 <selsta> so if you have a subaddress at offset 400, it will scan until 1400
03:12:36 <selsta> see https://monerodocs.org/interacting/monero-wallet-cli-reference/#performance
03:21:36 <JohnLee[m]> But our old version did not set --subaddress-lookahead, default is* when creating viewWallet, so all incoming transactions should be received, right?
03:24:45 <selsta> Are the missing transactions old transactions or are they all new?
03:26:23 <JohnLee[m]> All new, happened recently
03:30:00 <selsta> can you PM me a sample transaction id?
07:12:12 * tmoravec  < https://matrix.org/_matrix/media/r0/download/matrix.org/tvfTpQNiVcIfKjvIomAdiGPO/message.txt >
13:05:55 <binaryFate> GUI v0.17.2.2 is out on website
13:54:51 <gingeropolous> is there a release for CLI too?
13:54:59 <selsta> no
17:37:10 <lza_menace[m]> @selsta: is there any way to change a PR repo/branch source? I was going to edit PR 7722 based upon feedback but seems like I'd need to have you update your branch w/ my changes
17:37:33 <selsta> lza_menace[m]: just ping me once you updated it
17:37:41 <lza_menace[m]> ok
20:53:28 <woodser> `incoming_transfers` returns a global_index and a key_image. calling e.g. `frozen(ki)` with the key image calls `get_transfer_details()` which returns a number different than the global index, so the key image and global index return different results. perhaps a bug?
20:53:38 <woodser> https://github.com/monero-project/monero/blob/b1873af51931410390d5db8b4590970c0a6e9d0e/src/wallet/wallet2.cpp#L1738
20:54:33 <mj-xmr_> lza_menace[m], I have updated my comment as to the while(1) loop.
20:54:58 <lza_menace[m]> thanks. will check and update over the weekend
20:58:06 <mj-xmr_> Sorry, but I can't help with that logging style, as I've never seen that part of code.
20:58:29 <mj-xmr_> But I'm sure that any type of exception would be better than just exit(3)
20:59:59 <selsta> The wallet should save before closing.
21:02:14 <mj-xmr_> selsta, won't an exception auto-close it?
21:02:28 <mj-xmr_> *auto-save
21:02:39 <selsta> I don't know.
21:03:15 <mj-xmr_> OK. Something to check for sure.
21:03:41 <selsta> But if the wallet closes without saving it always results in bad user experience.
21:05:01 <mj-xmr_> yep
21:10:54 <MasFlam[m]> does anybody have any experience working with the monero wallet RPC? it seems port 18082 is the standard for it and the monerod process is listening on it, but there is no monero-wallet-rpc process and if I try to make a request, for example a simple get_version, curl assumes it's HTTP 0.9 and errors out saying that's "not allowed", and when i try to use wget with the -d debug flag it looks as if the response is just
21:10:54 <MasFlam[m]> completely empty
21:11:34 <selsta> MasFlam[m]: did you start monero-wallet-rpc binary?
21:12:14 <MasFlam[m]> i did not, but what's also weird is that monerod is listening on port 18082
21:13:15 <MasFlam[m]> and the docs seem to suggest that is the standard port for the wallet rpc
21:13:16 <selsta> 18082 is zmq port I think
21:13:22 <selsta> for the daemon
21:13:55 <selsta> you have to start monero-wallet-rpc binary, you can specify your own port
21:14:10 <MasFlam[m]> okay
21:14:42 <moneromooo> monerod and monero-wallet-rpc are different programs. monero-wallet-rpc does not have a default port. Run it before making wallet RPC requests.
21:15:07 <MasFlam[m]> so like, the gui wallet doesn't use the wallet rpc? because the process isn't there when it's running
21:15:13 <moneromooo> What evidence are you seeing for curl using HTTP 0.9 ?
21:15:21 <selsta> MasFlam[m]: no the gui does not use it
21:15:43 <MasFlam[m]> thanks, that clears up some confusion
21:15:47 <moneromooo> Using curl  with monero-wallet-rpc works fine for me, so it should be fairly simple to get it working for you.
21:16:28 <MasFlam[m]> i was curling whatever monerod had on port 18082, so no surprise i didn't get a response from it
21:19:34 <woodser> how should list<set<uint64_t>> be serialized over rpc for returning input indices on transfer and transfer_split?
21:23:52 <moneromooo> How about a vector<vector<uint64_t>> ?
21:24:30 <moneromooo> Smaller, can be serialized as a vector<blob>, and preserves ordering.
21:24:49 <moneromooo> Then again, set also does since it's ordered, nvm.
21:29:40 <woodser> std::vector<std::vector<uint64_t>> has a compile error at keyvalue_serialization_overloads.h lines 175 and 180: no member named 'store' in 'std::__1::vector<unsigned long long>' (same error with list and set)
21:30:05 <moneromooo> You need a struct, see various other RPC.
21:30:25 <moneromooo> ie, vector<foo_t> and struct foo_t { vector<uint64_t> i; };
21:30:43 <moneromooo> Or work out how to tell serialization.h to handle it :)
21:33:05 <moneromooo> And the inner can't be as blob since it's not a binary call :/ Oh well.
21:33:58 <moneromooo> Can you give your code for the freeze bug ?
21:34:04 <woodser> sure
21:58:00 <woodser> well I added rpc calls for freeze, thaw, and frozen which I can PR: https://github.com/woodser/monero/commit/ce870803cc9c1d24a2eca1e0de81bda63a9661ac
21:58:34 <woodser> then used client code to freeze an output by index, frozen(index) returns true as expected, but frozen(key_image) returns false: https://github.com/woodser/monero/commit/ce870803cc9c1d24a2eca1e0de81bda63a9661ac
22:00:19 <woodser> sorry, second link should be: https://github.com/monero-ecosystem/monero-java/blob/8484ea8a4b394433e0c546b9d745387074052f09/src/test/java/test/TestMoneroWalletCommon.java#L2588
22:01:46 <moneromooo> You call freeze/thaw with output_index, it's expecting the index in transfer_details.
22:07:14 <woodser> output.getIndex() in the client code comes incoming_transfers global_index, which is the only index assigned to transfer_details in that rpc call
22:07:26 <woodser> comes *from
22:31:32 <woodser> can clients get the index returned from `size_t wallet2::get_transfer_details(const crypto::key_image &ki)`?  if not maybe rpc should only handle freezing by key image?