07:25:58 <r4v3r23[m]> is there an ETA on polyseed support?
14:51:45 <selsta> r4v3r23[m]: currently no ETA
18:10:15 <selsta> if someone wants to help test testnet, please do a couple transactions and check if you can reproduce https://github.com/monero-project/monero/issues/8347
18:12:35 <rbrunner> Looks like a tx with quite a lot of inputs?
18:23:23 <selsta> I don't get smarter from these logs
18:28:15 <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.
18:28:42 <rbrunner> Like that I went through maybe 30 tries, letting it prepare txs with around 30 inputs, without any problem so far
18:29:06 <rbrunner> It's of course very fast if you merely prepare, but not send
18:29:47 <rbrunner> I also did maybe 30 or 40 txs over the last few days, also without that bug
18:30:31 <selsta> garth: ^
18:31:00 <selsta> do you have any more specific info? can you consistently reproduce it?
18:31:06 <rbrunner> Well, if it's a edge case, good luck hunting :)
18:35:52 <selsta> would sharing the seed help?
18:36:58 <moneromooo> Good point. It might.
18:37:14 <moneromooo> Easier to add logs without having to post log patches.
18:38:13 <selsta> >maybe this is because these tXMR are from 2017. So some older tx version
18:39:01 <selsta> i asked him for the seed
19:06:11 <garth> Hello
19:06:27 <garth> It was restored with a view/spend key pur
19:06:30 <garth> Pair 
19:06:48 <garth> I wish I wouldn’t have sent the outputs in other tests…. They’ve now been spent
19:07:10 <garth> I’ll pm them to you mooow
19:07:14 <garth> Mooo
19:09:25 <garth> <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
19:10:12 <garth> 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)
19:10:55 <garth> I ended up sending the 100 tXMR and now I can’t reproduce the bug
19:24:47 <rbrunner> :(
19:25:14 <rbrunner> I also spend coins that I did not want that way about half an hour ago :)
19:31:22 <garth> Haha nice. Mooo reminded me that you can just pop blocks up to that height to reproduce the erorr
19:33:50 <rbrunner> Plus running offline?
19:34:13 <rbrunner> Good idea
19:34:26 <garth> Apparently
19:36:32 <rbrunner> 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
20:02:34 <spirobel[m]> 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
20:02:34 <spirobel[m]> command line argument. btw i collect the scripts here:  https://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. 
20:04:57 <plowsof[m]> use --offline 
20:08:50 <spirobel[m]> plowsof[m]: tried but still "setting daemon to http://localhost:38081" I will research more.
20:11:08 <spirobel[m]> ...maybe it is just a bad idea. 
20:12:38 <plowsof[m]> generate-from-json is also nice 
20:12:46 <moneromooo> The wallet will try to connect and refresh before listening.
20:19:43 <spirobel[m]> <moneromooo> "The wallet will try to connect..." <- why does it behave like this?
20:21:28 <moneromooo> It does not have to be like this.
20:21:53 <spirobel[m]> 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. 
20:23:01 <spirobel[m]> moneromooo: what are the preferred command line options to make it behave nice? which ones do you use usually?
20:24:29 <moneromooo> By "behave nice", you mean listening before connecting ?
20:26:35 <spirobel[m]> 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. 
20:28:07 <moneromooo> I'd have thought setting -d would do that, but if I read you correctly, it doesn't.
20:28:42 <moneromooo> As for async RPC, there are none other than refresh IIRC.
20:31:26 <spirobel[m]> moneromooo: is this a command line option -d ? or do you mean setting a daemon?
20:32:16 <moneromooo> Wallet directory. I assumed you were using it, since you mentioned create_wallet.
20:32:30 <moneromooo> Are you using it ?
20:34:47 <spirobel[m]> 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 
20:35:10 <spirobel[m]> > <@moneromooo:libera.chat> Wallet directory. I assumed you were using it, since you mentioned create_wallet.
20:35:10 <spirobel[m]>  * 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
20:35:35 <moneromooo> I would not expect it to actually connect before create_wallet.
20:35:51 <moneromooo> Why are you not setting up a dameon on startup then ?
20:36:26 <moneromooo> If looks like you're purposefully using the wrong daemon, then complaining it's thr wrong daemon. Am I wrong ?
20:36:41 <spirobel[m]> moneromooo: if it is not done the start height will be wrong and the wallet daemon will be set to localhost
20:36:41 <moneromooo> Still, set_dameon ought to work without a wallet set.
20:36:48 <moneromooo> (as in, it shold be made to work)
20:36:59 <spirobel[m]> moneromooo: because I want the rpc to respond asap
20:37:12 <moneromooo> Too confusing/unclear, I'll stop.
20:38:00 <moneromooo> (but feel free to open a "set_daemon does not work with no wallet loaded" bug if that is inmdeed what you are seeing).
20:38:58 <plowsof[m]> 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 
20:43:17 <spirobel[m]> 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. 
20:43:21 <moneromooo> We could also be a --no-initial-refresh flag.
20:45:47 <spirobel[m]> 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.
20:46:16 <spirobel[m]> > <@moneromooo:libera.chat> We could also be a --no-initial-refresh flag.
20:46:16 <spirobel[m]>  * 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.
20:46:39 <moneromooo> Self inflicted then :)
20:49:20 <spirobel[m]> 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)
20:52:40 <moneromooo> Why could it corrupt the file ?
20:55:09 <spirobel[m]> 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.
20:56:16 <moneromooo> You can open a bug about this too. I suspect it'll be annoying though.
20:57:53 <spirobel[m]> but it seems like it is intended like this. Seems like nobody else had a problem with this before.
21:00:16 <moneromooo> Pretty sure some people did complain about refresh before listen before.
21:01:17 <spirobel[m]> who would be the one to fix it? who is the owner of the code in wallet2.cpp that is responsible for that?
21:01:40 <selsta> we don't really have owners
21:02:05 <selsta> at least for most things, i guess there are parts that one person knows best
21:02:54 <moneromooo> I think it's in wallet_rpc_server in fact.
21:02:55 <moneromooo> (not sure(
21:03:11 <spirobel[m]> so if I file the bug. what happens then? probably it is not easy to fix, right? or is it a quick fix?
21:03:40 <moneromooo> Making the initial sync optoinal is simple I tihnk. Whoever feels like fixing it would fix it.
21:03:46 <moneromooo> I might.
21:04:14 <moneromooo> Making set_daemon async will be annoying.
21:04:32 <moneromooo> As in, fucking annoying I think.
21:05:12 <moneromooo> Though I guess you could pass a custom timeout, so you could opt for a short one.
21:05:18 <spirobel[m]> but that is the root cause of the problem, right? that some parts of the wallet-rpc are synchronous
21:05:36 <spirobel[m]> moneromooo: that sounds like  possible work around
21:06:08 <moneromooo> Similar I guess. You could have async set_daemon without async other stuff.
21:06:59 <spirobel[m]> the timeout is set via a variable in the rpc call to set_daemon, right? I will take a look
21:07:36 <moneromooo> I meant one could add code to allow a custom timeout. It doesn't exist in the RPC now AFAIK.
21:08:07 <moneromooo> That'd be simple, as I think it doesn't have to be passed around a lot.
21:10:38 <spirobel[m]> 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
21:15:12 <plowsof[m]> yes wallet-dir and --offline 
21:54:22 <jeffro256[m]> Hey y'all I opened a PR concerning moving RPC SSL certs to ed25519 keys and complying with OpenSSL 3.0: https://github.com/monero-project/monero/pull/8354
21:54:25 <jeffro256[m]> Thoughts? 
21:57:00 <blackieee[m]> How can I verify if a subaddress belongs to my wallet? Thanks. 
23:38:43 <ooo123ooo1234[m]> test
23:39:06 <ooo123ooo1234[m]> hmm, ban wasn't successful
23:46:44 <plowsof[m]> unban successful 
23:47:28 <ooo123ooo1234[m]> it isn't unban. matrix rooms are still blocked; happy cencorship day