03:00:18 -xmr-pr- ACK-J opened issue #8193: Monero Wallet Transaction Exporter Bugs
03:00:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8193
14:13:44 <pedro_> hello there
14:30:35 <JohnLee[m]> How do I verify the Monero address？
14:35:54 <wernervasquez[m]> <JohnLee[m]> "How do I verify the Monero..." <- Verify what about it?
14:37:11 <JohnLee[m]> wernervasquez[m]: Verify that the address format is correct, and whether there is an rpc interface to verify it?
14:37:44 <dEBRUYNE> JohnLee[m]: You could use this tool -> https://xmr.llcoins.net/addresstests.html
14:40:44 <wernervasquez[m]> John Lee: Also, if it is an address you control, you could send a trivial test amount to it and see if it arrives.
14:41:10 <JohnLee[m]> Great, I now want to verify through the rpc interface can it be done, or how can I use the code to verify?
14:41:53 <JohnLee[m]> before I send test amount to it
14:44:28 <wernervasquez[m]> John Lee: I am unfamiliar with the rpc. However, I have written code to generate monero addresses. I tested it by using the code that generates a one time address and the code that scans for one time addresses.
14:45:39 <wernervasquez[m]> John Lee: further, i checked that the private key times the basepoint equalled the public key for the view key, spend key, and one time key
14:47:51 <wernervasquez[m]> If I can generate a one time address, recognize it, and derive the spend key for it (and generate the address from my private keys)...I would think that is all the functionality you need to test.
14:49:57 <wernervasquez[m]> I would also look at the unit tests. I imagine one of the tests has to be what you are looking for. You could adapt that code to test your address instead of the test case.
14:50:48 <wernervasquez[m]> But hopefully there is something even easier that someone else here knows.
14:54:12 <moneromooo> There is a RPC for it. Did you not find it ?
14:55:42 <JohnLee[m]> which one
14:59:13 * JohnLee[m] uploaded an image: (281KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/fWyMKYhRDzsBqzNAnJlVZMhN/image.png >
14:59:57 <JohnLee[m]> validate_address
14:59:58 <JohnLee[m]> Analyzes a string to determine whether it is a valid monero wallet address and returns the result and the address specifications.
15:14:10 <jtgrassie> https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#validate_address
18:53:39 <bootlegbilly[m]> hey everyone
18:53:50 <bootlegbilly[m]> Does anyone have any advice on reduing the amount of timeouts from the monero wallet rpc
18:54:18 <bootlegbilly[m]> I've just resorted to sending calls over and over until it responds but every couple of requests there's always a timeout
18:55:55 <plowsof[m]> i just accept its broken, and launch it with the  'pid' file argument - then use the process id to close it. and restart it 😝
18:56:09 <moneromooo> Depends what RPC I guess. 
18:56:31 <bootlegbilly[m]> Damn lmao, alright ill just do that
18:56:33 <moneromooo> If you can, ask for less work (ie, if you want to check whether 10k key images are spent, call 5 times with 2k per call)
18:56:39 <bootlegbilly[m]> moneromooo: The wallet rpc, generally the daemon rpc calls go through
18:56:51 <moneromooo> Otherwise, just incresae the timeout.
18:56:53 <bootlegbilly[m]> I've just been trying to cache certain RPC calls when they work in the meantime
18:57:06 <bootlegbilly[m]> moneromooo: Is like 3.5 seconds okay?
18:57:14 <moneromooo> You might also try to disable auto refresh.
18:57:40 <moneromooo> Likely too short.
18:57:44 <bootlegbilly[m]> What does autorefresh do?
18:57:49 <bootlegbilly[m]> Alright ill bump it to 5
18:57:56 <bootlegbilly[m]> It's running locally though so i didnt expect it to take so long
18:58:22 <moneromooo> Refreshnug means asking the daemon for new blocks and processing any txes in them. That can block for a bit.
18:58:35 <bootlegbilly[m]> Ohhh
18:58:45 <bootlegbilly[m]> Just out of curiosity why wouldn't that run asynchronosly
18:58:48 <bootlegbilly[m]> Or however you spell that jaja
18:59:02 <bootlegbilly[m]> Like accepting both RPC calls while waiting for any new daemon blocks
18:59:17 <moneromooo> Easier.
18:59:28 <bootlegbilly[m]> I get that jaja
18:59:37 <moneromooo> You need to lock the outputs data structure for both (typically).
19:00:04 <bootlegbilly[m]> Just out of curiosty would there be ways of making certain wallet rpc calls by directly sending calls to the daemon?
19:00:17 <moneromooo> So it wouldn't gain much unless you start doing things really cleverly.
19:00:23 <bootlegbilly[m]> Like instead of get_balance to wallet rpc I jsut request a bunch of blocks from the daemon RPC and scan those
19:00:23 <moneromooo> Yes.
19:00:33 <moneromooo> er, not for *that*.
19:00:43 <bootlegbilly[m]> moneromooo: I'm not well versed in CPP dev, but what about a RWLock structure
19:00:51 <bootlegbilly[m]> moneromooo: Oh damn, how come?
19:00:58 <bootlegbilly[m]> Btw moneromoo I just wanna say I'm a massive fan
19:01:01 <moneromooo> That's what the wallet does, and it cashes it. Scanning the chain is *lengthy*. Like an hour.
19:01:08 <bootlegbilly[m]> Like you and the rest of the Monero dev team are geniuses imho
19:01:45 <moneromooo> A rw lock might help in some cases I guess, but the outputs structure is complex.
19:02:17 <bootlegbilly[m]> Okay I think i understand better
19:02:52 <bootlegbilly[m]> Do you have anyway you suggest of being able to asynchronouosly get dtata from the wallet RPC while still keeping it relatively up to date?
19:02:57 <moneromooo> Then again, most of the incoming blocks don't result in new outputs, so it actually would gain a fair bit. But... more work/testing.
19:03:20 <moneromooo> Rephrase that, I did not understand.
19:03:58 <bootlegbilly[m]> As in is there any way of telling the Wallet RPC to refresh while still allowing it to take RPC requests
19:04:26 <moneromooo> You can tell the wallet to refresh when you want.
19:04:33 <bootlegbilly[m]> Like are there certain wallet calls that would be easier to do by sending and receiving data directly from the daemon
19:04:35 <moneromooo> So, after you're done with a series of RPC.
19:04:53 <moneromooo> Maybe. I'd have to go through the list and think :)
19:05:08 <moneromooo> Well, an easy one: start_mining.
19:05:16 <moneromooo> That just proxies I think.
19:05:47 <bootlegbilly[m]> Sorry I don't mean to keep bugging you, but what about if I can have a large amount of RPC calls at pretty much any time (since it's a service)
19:06:04 <bootlegbilly[m]> There are some calls I've started to convert to just use the daemon
19:06:09 <moneromooo> You can do that by disabling auto refresh and refreshing manually :)
19:06:39 <moneromooo> Actually, I think a refresh request might even be async... I did not add that so I'm not sure.
19:06:58 <bootlegbilly[m]> But a lot of the important ones like get_balance and get_payments I only know how to do through the wallet
19:07:07 <bootlegbilly[m]> And yea I'll definetly start refreshing manually, thank you for that
19:07:34 <moneromooo> Those might gain from a rwlock, yes. Just needs someone to dump the time into it.
19:07:58 <moneromooo> And as it is, monerod would likely gain more than the wallet from a rwlock.
19:10:40 <bootlegbilly[m]> I'd honestly work on it myself (since it'd be super helpful for the stuff I'm working on) but I only know a ton of Rust and v little Cpp
19:10:56 <bootlegbilly[m]> Would there be any places in the codebase in particular you think would benefit from a RWLock
19:11:00 <bootlegbilly[m]> Since I could definetly try to begin work
19:13:42 <moneromooo> The blockchain lock (blockchain.cpp) is the main culprit.
19:14:04 <bootlegbilly[m]> Sweet, thank you so much for all your help moneromoo
19:14:17 <moneromooo> A few people said they'd work on it. One of them actually did, but had a patch with that and various other unrelated changes so didn't get used.
19:14:29 <bootlegbilly[m]> I'll definetly start work on it, though no guarantees I'll get it done jaja
19:14:34 <moneromooo> Thanks :)
19:14:38 <bootlegbilly[m]> Ooh is that patch linked anywher,e that would help massively
19:14:41 <bootlegbilly[m]> Ofc, thank you :)
19:14:50 <moneromooo> It should be on github as a PR IIRC.
19:15:02 <moneromooo> No idea if it was correct fwiw.
19:16:18 <bootlegbilly[m]> This is super random but would you want a PR updating the Copyright year?
19:16:23 <bootlegbilly[m]> Idk if its like too stupid to add or not
19:17:04 <moneromooo> Every year we get them. Pretty sure someone or several someones already sent one.
19:17:20 <bootlegbilly[m]> Oh alright lol I won't touch that then
19:35:23 <selsta> we didn't merge them last year
19:36:24 <bootlegbilly[m]> selsta: You mind if i ask how come?
19:37:44 <selsta> bootlegbilly[m]: https://github.com/monero-project/monero/pull/7495#issuecomment-917526097
19:38:15 <selsta> also going through hundred of files checking if the script didn't mess anything up is kinda annoying and low priority
19:39:16 <selsta> but if you want to open one for 2022 there isn't one yet
19:39:41 <bootlegbilly[m]> if i get the rwlock PR finished ever, I probably will right after
19:39:58 <bootlegbilly[m]> So if this were to get merged and everything, would it really be in the next Monero release (pending no problems ofc)
20:06:39 <UkoeHB> is there any purpose to updating the copyright year? like some legal significance?
20:12:11 <moneromooo> Copyright protections last... N years from the date of creation of the copyrighted thing). Marking the last modification date gives you extra weight in your argument that your copyright was violated, if you try to sue.
20:12:30 <moneromooo> So you should be able to get away with updating it every 10 years or so.
20:12:35 <bootlegbilly[m]> Hey moneromoooo, in blockchain.cpp on line 4959, why is everything locked and unlocked in a loop?
20:12:43 <bootlegbilly[m]> Is it just so that other processors can quickly grab a lock if needed?
20:13:00 <moneromooo> Of course, the thing that's re-copyrighted is not the whole file, just the modifications, so it's murky I guess.
20:14:17 <moneromooo> Yes. It avoids a deadlock in this case.
20:14:47 <bootlegbilly[m]> Thank you, i swer i was looking at it for a good minute wondering why the hell that would hapepn
20:15:07 <moneromooo> I think. Assuming some other thread can start a batch while having the lock.
20:15:22 <moneromooo> hyc might know more of the details.
20:15:35 <bootlegbilly[m]> Oh aren't locks seperate from the actual data they store in cpp
20:33:21 <bootlegbilly[m]> Would anyone mind explaining CRITICAL_REGION_LOCAL in blockchain.cpp
20:34:11 <bootlegbilly[m]> I see it everwhere and I'm vaguely getting it creates a lock but i never see it call unlcok
20:34:20 <bootlegbilly[m]> Does it unlock when dropped? (I'm not too familiar with CPP RAII)
20:37:44 <moneromooo> git grep CRITICAL_REGION_LOCAL
20:37:54 <moneromooo> It's unlocked when it goes out of scope.
20:40:54 <bootlegbilly[m]> Ty