is there an ETA on polyseed support?

r4v3r23[m]: currently no ETA

if someone wants to help test testnet, please do a couple transactions and check if you can reproduce monero-project/monero #8347

Looks like a tx with quite a lot of inputs?

I don't get smarter from these logs

I think it should be possible to try to provoke that by letting the CLI merely prepare the tx, but then not ok'ing the sending.

Like that I went through maybe 30 tries, letting it prepare txs with around 30 inputs, without any problem so far

It's of course very fast if you merely prepare, but not send

I also did maybe 30 or 40 txs over the last few days, also without that bug

garth: ^

do you have any more specific info? can you consistently reproduce it?

Well, if it's a edge case, good luck hunting :)

would sharing the seed help?

Good point. It might.

Easier to add logs without having to post log patches.

>maybe this is because these tXMR are from 2017. So some older tx version

i asked him for the seed

Hello

It was restored with a view/spend key pur

Pair

I wish I wouldn’t have sent the outputs in other tests…. They’ve now been spent

I’ll pm them to you mooow

Mooo

<rbrunner> I think it should be possible to try to provoke that by letting the CLI merely prepare the tx, but then not ok'ing the sending. <—- this is exactly what is true

I got the error simply by mistake preparing a tx because the exact same balance could be spent at a higher amount (100 tXMR instead of 50)

I ended up sending the 100 tXMR and now I can’t reproduce the bug

:(

I also spend coins that I did not want that way about half an hour ago :)

Haha nice. Mooo reminded me that you can just pop blocks up to that height to reproduce the erorr

Plus running offline?

Good idea

Apparently

I can't reproduce with my wallets. I also have one going back to 2017, and I let it prepare several transfers that spanned a freaking 7 txs, without problems

is it actually a good idea to start the wallet-rpc without a daemon connection set? I ran into some catch 22 when doing it like this: without a wallet file the set_daemon rpc call does not work, so when I do create_wallet it will try to set the daemon to localhost by itself and then the daemon connection does not work and start height will be set wrong. I want wallet-rpc to respond asap, thats why I dont want to set the daemon via the

command line argument. btw i collect the scripts here: github.com/spirobel/monero-playground maybe it is helpful for others too. It seems like to build something with monero it is important to get a feel for wallet-rpc.

use --offline

plowsof[m]: tried but still "setting daemon to localhost:38081" I will research more.

...maybe it is just a bad idea.

generate-from-json is also nice

The wallet will try to connect and refresh before listening.

<moneromooo> "The wallet will try to connect..." <- why does it behave like this?

It does not have to be like this.

It would be nice to only deal with errors the rpc tells us. and it would also be nice if the rpc was responsive under all circumstances.

moneromooo: what are the preferred command line options to make it behave nice? which ones do you use usually?

By "behave nice", you mean listening before connecting ?

moneromooo: yes. But I also recognize there are other circumstances where the rpc becomes unresponsive. For example when set_daemon is called. It will try to connect and it happened that it wont respond to other commands and I had to kill it.

I'd have thought setting -d would do that, but if I read you correctly, it doesn't.

As for async RPC, there are none other than refresh IIRC.

moneromooo: is this a command line option -d ? or do you mean setting a daemon?

Wallet directory. I assumed you were using it, since you mentioned create_wallet.

Are you using it ?

moneromooo: yes. I tried using it before. But when I do it without setting a daemon on startup I cant use set_daemon because there is no wallet file. so I need to do create_wallet or open_wallet which leads to another kind of mess, because it well set daemon to localhost

> <@moneromooo:libera.chat> Wallet directory. I assumed you were using it, since you mentioned create_wallet.

* yes. I tried using it before. But when I do it without setting a daemon on startup I cant use set\_daemon because there is no wallet file. so I need to do create\_wallet or open\_wallet which leads to another kind of mess, because it will set daemon to localhost and start height will be wrong

I would not expect it to actually connect before create_wallet.

Why are you not setting up a dameon on startup then ?

If looks like you're purposefully using the wrong daemon, then complaining it's thr wrong daemon. Am I wrong ?

moneromooo: if it is not done the start height will be wrong and the wallet daemon will be set to localhost

Still, set_dameon ought to work without a wallet set.

(as in, it shold be made to work)

moneromooo: because I want the rpc to respond asap

Too confusing/unclear, I'll stop.

(but feel free to open a "set_daemon does not work with no wallet loaded" bug if that is inmdeed what you are seeing).

i used --offline when i wanted my json rpc calls to 'work quicker' - i always have a blocking loop to make sure it truly is 'online' after starting the rpc wallet

plowsof[m]: did you specify a wallet file together with it? is it the waas repo? I want to have a look. I also recognized that the order of the command line arguments is important.

We could also be a --no-initial-refresh flag.

moneromooo: it also seems like the rpc will not respond for a long time when I do a set_daemon. It seems like it is not working and I get impatient. so I send a stop_wallet. And then it takes for ever until I kill the process.

> <@moneromooo:libera.chat> We could also be a --no-initial-refresh flag.

* it also seems like the rpc will not respond for a long time when I do a set\_daemon. It seems like it is not working and I get impatient. so I send a stop_wallet. And then it takes for ever until finally decide to kill the process.

Self inflicted then :)

I just want the user to be able to cancel the process when the connection to a daemon does not work, so they can try a different one. It would be nice to do this gracefully without killing the wallet process ( which might corrupt the file)

Why could it corrupt the file ?

moneromooo: I just have this feeling. If I just kill the wallet. I feel unsafe. It might be writing in this moment to the cache file or mess up something else. Also monero gui asks users to wait to safe the wallet when shutting down. There is probably a reason for that.

You can open a bug about this too. I suspect it'll be annoying though.

but it seems like it is intended like this. Seems like nobody else had a problem with this before.

Pretty sure some people did complain about refresh before listen before.

who would be the one to fix it? who is the owner of the code in wallet2.cpp that is responsible for that?

we don't really have owners

at least for most things, i guess there are parts that one person knows best

I think it's in wallet_rpc_server in fact.

(not sure(

so if I file the bug. what happens then? probably it is not easy to fix, right? or is it a quick fix?

Making the initial sync optoinal is simple I tihnk. Whoever feels like fixing it would fix it.

I might.

Making set_daemon async will be annoying.

As in, fucking annoying I think.

Though I guess you could pass a custom timeout, so you could opt for a short one.

but that is the root cause of the problem, right? that some parts of the wallet-rpc are synchronous

moneromooo: that sounds like possible work around

Similar I guess. You could have async set_daemon without async other stuff.

the timeout is set via a variable in the rpc call to set_daemon, right? I will take a look

I meant one could add code to allow a custom timeout. It doesn't exist in the RPC now AFAIK.

That'd be simple, as I think it doesn't have to be passed around a lot.

hm...I am not sure. Because the UX problem to solve is that the user might try a daemon url that does not work so he gets impatient and wants to cancel or try a different one. A timeout wouldnt really help because it is unknown before when and if he wants to cancel

yes wallet-dir and --offline

Hey y'all I opened a PR concerning moving RPC SSL certs to ed25519 keys and complying with OpenSSL 3.0: monero-project/monero #8354

Thoughts?

How can I verify if a subaddress belongs to my wallet? Thanks.

test

hmm, ban wasn't successful

unban successful

it isn't unban. matrix rooms are still blocked; happy cencorship day