howdy

i have a PR if someone can help me open it on the repo

it's small and dumb, but my first time working on c++ and monero core....im proud of it :D

1

hi

lza_menace[m]: will open it

I am the author about monero-project/monero-gui #3479, I'm here to ask you guys, need help, thank you

lza_menace[m]: you can also message luigi to add you to the repo

JohnLee[m]: did you try with subaddress-lookahead?

@sels

I will try, this --subaddress-lookahead 200:1000, must the index of these transaction addresses be within this range?

no, the syntax is --subaddress-lookahead major:minor

default if 50:200, if you set it to e.g. 200:1000 it will scan for more subaddresses

default is*

JohnLee[m]: please stay in the channel, more devs should be online in ~6h

Ok, I mean, for example, the sub-address offset of the output address of my transaction is 1000, that must be 500:2000, right?

no, 1000 means that it will scan for 1000 subaddresses in advance

so if you have a subaddress at offset 400, it will scan until 1400

see monerodocs.org/interacting/monero-wallet-cli-reference/#performance

But our old version did not set --subaddress-lookahead, default is* when creating viewWallet, so all incoming transactions should be received, right?

Are the missing transactions old transactions or are they all new?

All new, happened recently

can you PM me a sample transaction id?

GUI v0.17.2.2 is out on website

is there a release for CLI too?

no

@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

lza_menace[m]: just ping me once you updated it

ok

`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?

lza_menace[m], I have updated my comment as to the while(1) loop.

thanks. will check and update over the weekend

Sorry, but I can't help with that logging style, as I've never seen that part of code.

But I'm sure that any type of exception would be better than just exit(3)

The wallet should save before closing.

selsta, won't an exception auto-close it?

*auto-save

I don't know.

OK. Something to check for sure.

But if the wallet closes without saving it always results in bad user experience.

yep

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

completely empty

MasFlam[m]: did you start monero-wallet-rpc binary?

i did not, but what's also weird is that monerod is listening on port 18082

and the docs seem to suggest that is the standard port for the wallet rpc

18082 is zmq port I think

for the daemon

you have to start monero-wallet-rpc binary, you can specify your own port

okay

monerod and monero-wallet-rpc are different programs. monero-wallet-rpc does not have a default port. Run it before making wallet RPC requests.

so like, the gui wallet doesn't use the wallet rpc? because the process isn't there when it's running

What evidence are you seeing for curl using HTTP 0.9 ?

MasFlam[m]: no the gui does not use it

thanks, that clears up some confusion

Using curl with monero-wallet-rpc works fine for me, so it should be fairly simple to get it working for you.

i was curling whatever monerod had on port 18082, so no surprise i didn't get a response from it

how should list<set<uint64_t>> be serialized over rpc for returning input indices on transfer and transfer_split?

How about a vector<vector<uint64_t>> ?

Smaller, can be serialized as a vector<blob>, and preserves ordering.

Then again, set also does since it's ordered, nvm.

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)

You need a struct, see various other RPC.

ie, vector<foo_t> and struct foo_t { vector<uint64_t> i; };

Or work out how to tell serialization.h to handle it :)

And the inner can't be as blob since it's not a binary call :/ Oh well.

Can you give your code for the freeze bug ?

sure

well I added rpc calls for freeze, thaw, and frozen which I can PR: woodser/monero ce87080

then used client code to freeze an output by index, frozen(index) returns true as expected, but frozen(key_image) returns false: woodser/monero ce87080

sorry, second link should be: github.com/monero-ecosystem/monero-…t/TestMoneroWalletCommon.java#L2588

You call freeze/thaw with output_index, it's expecting the index in transfer_details.

output.getIndex() in the client code comes incoming_transfers global_index, which is the only index assigned to transfer_details in that rpc call

comes *from

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?