00:20:11 <xmrscott[m]> Ok awesome. That answers someone's question I saw about if there's value in running a gitea backup. Thanks for the quick response you two
00:22:01 <xmrscott[m]> (Also welcome back fluffy ☻)
01:47:45 <fluffypony> tks :)
04:13:48 <jimmyt[m]> Do Monero devs feel like development is being slowed by a shortage of highly skilled mathematicians willing to contribute to the project? I‘m working on a short essay about why someone would choose to study mathematics instead of computer science, and I’m considering the argument that the world may currently need more new mathematicians than it does new CS professionals. If the argument has some truth to it, and if it applies to Monero
04:13:48 <jimmyt[m]> development, I‘d like to use it in my essay. Thoughts?
07:37:29 <zogiqa[m]> hello, I cant get monero wallet ever to connect 
11:11:04 <aksion[m]> Hello! Why not include P2Pool mining in the official Montero wallet? Obviously, solo mining has outlived its usefulness for a long time. Replace the solo mining option in the official monero wallet with P2Pool mining.
11:11:04 <aksion[m]> And also make a commission for those who connect to a remote node, so that the holders of the full node recoup the costs
11:55:49 <merope> Because you don't need to keep the wallet open just for mining (in fact, it's bad security practice)
11:56:40 <merope> Though it would be nice to have p2pool as an option for rpc-pay, rather than full-blown solo mining
11:59:28 <aksion[m]> merope: Are those for the sake of solo mining in the wallet ok to keep it open, and for the sake of P2P - bad practice?
12:18:32 <aksion[m]> If you do not introduce p2pool mining into the official Monero wallet on a par with solo mining, then people will continue to mine on simple pools, killing the decentralization of the Monero network and enriching the owners of simple pools. The p2pool miner in the Monero wallet is the only way to motivate people to keep a full node on their computers. I support that p2pool mining in general should become the main one for Monroe.
12:20:58 <DataHoarder> aksion[m]: seems you are copy pasting these messages across many channels, keep discussion focused in one spot please
12:22:27 <aksion[m]> DataHoarder: I don't copy and paste, I write thoughts. Which channel would you recommend to focus on?
12:23:20 <DataHoarder> I have seen the same messages across three channels already, typos included. Focus on -community or #monero I'd say, this channel is for dev
12:23:41 <DataHoarder> there's also p2pool specific channels :)
12:29:40 <aksion[m]> <DataHoarder> "I have seen the same messages..." <- Everyone needs P2Pool mining in their wallet to maintain the decentralization of Monero and the content of the full node. Do it and I won't write with typos
12:30:40 <DataHoarder> spamming won't help, and I'm not a dev. Keeping the discussion focused on one channel will help as the conversation is easier to follow instead of switching across many channels to see what people say
12:35:16 <Rucknium[m]> jimmyt: That question is better for #monero-research-lounge:monero.social 
12:38:48 <aksion[m]> Спасибо!
13:11:16 <fluffypony> I like the idea of p2pool for rpc-pay
13:11:27 <fluffypony> unless you have hundreds of clients connecting you aren't going to mine a block
13:17:18 <aksion[m]> To strengthen the stability of the Monroe network and eliminate the centralization of mining as a phenomenon, it is necessary to completely eliminate the possibility of mining in pools programmatically. The main way of mining for Montero is to make p2pool mining. Make a convenient p2pool mining miner on the official website of Montero
13:21:04 <aksion[m]> s/Monroe/Monero/, s/Montero/Monero/, s/Montero/Monero/
13:48:05 <aksion[m]> I have a suggestion on how to make Monero instantly the most popular in the World.
13:48:05 <aksion[m]> Let's give each person on Earth an equal number of coins (not anonymously), so that people can start mutual settlements. It won't make anyone richer or poorer. But there will be mutual settlements in Monero. Those who want anonymity - let them buy or mine for themselves additionally.
13:51:10 <chad[m]1> aksion please stop spamming your messages across all channels and please keep this channel to -dev
14:29:08 <XxFedexX> Hello. I coded a tipping bot for Wownero's IRC, and i could easily convert it to being a Monero bot, is there any tipbot on this IRC already?
14:31:47 <sethsimmons> <chad[m]1> "aksion please stop spamming your..." <- Cleaning this up on the Matrix side, at least.
15:02:39 <moneromooo> There was one recently in #monero. I think it's gone. It had a faucet command so the channel ended up a sewer. If yours doesn't and isn't spammy, why not.
16:04:48 <midnightmage[m]> Anyone got a read up or link to the libraries etc that are being used with monero
16:09:57 <UkoeHB> libraries?
16:10:18 <UkoeHB> midnightmage[m]: https://github.com/monero-project/monero/tree/master/external
16:17:44 <selsta> https://github.com/monero-project/monero#dependencies
16:20:41 <midnightmage[m]> I know of two RW locks, c++14 and boost, or would you prefer if I use a third option?
16:24:08 <selsta> we currently use C++11 but we are soon updating to C++14 https://github.com/monero-project/monero/pull/7971
16:24:18 <selsta> boost would be fine too
16:24:47 <midnightmage[m]> thanks
16:26:08 <selsta> do you have anything specific in mind for rw lock moneromooo?
16:28:58 <moneromooo> Hmm. I'd say probably boost, since windows probably not gonna like pthread and monero still builds with C++11.
16:29:40 <moneromooo> Ah, taken care of in the lines above. Well, I have no other opinion on it.
16:31:00 <moneromooo> I guess if we do move to C++14, using the C++ ones will be preferable. Some platform had a locking bug that forced us to use boost versions. Can't recall what that was exactly, but git log should have that.
16:31:15 <moneromooo> Might not be relevant to this but maybe worth looking at.
16:31:25 <moneromooo> I think it was some windows.
16:31:37 <midnightmage[m]> anything else I should know before attempting this `rw lock for the Blockchain class instead of mutex` ? it is off jberman's bucket list of things to do
16:32:17 <moneromooo> Well, one it can be tricky :D
16:33:17 <atomfried[m]> will the code move first to C++14 or directly to C++17?
16:33:19 <moneromooo> There was a patch for this at some point, got abandoned by the author as it had various other changes dumped in with it IRC.
16:33:47 <moneromooo> (no link, but it was on github) 
16:34:41 <midnightmage[m]> what's the catch? i thought it would be pretty simple, track down all uses of the mutex, see what's read only and what's not
16:35:11 <moneromooo> Sure. It's simple then.
16:36:27 <moneromooo> If you're familiar with threads and locking.
16:36:52 <atomfried[m]> isnt the  rw mutex (std::shared_mutex) only available since c++17?
16:38:11 <midnightmage[m]> atomfried[m]: https://en.cppreference.com/w/cpp/thread/shared_timed_mutex
16:39:05 <atomfried[m]> ah ok you are using the timed version then. the untimed version is c++17 
16:39:05 <atomfried[m]> https://en.cppreference.com/w/cpp/thread/shared_mutex
16:40:45 <atomfried[m]> didnt know that shared_timed_mutex is c++14 😅
16:42:01 <midnightmage[m]> atomfried[m]: it is a standard quirk, they did a more featured class earlier
16:47:11 <atomfried[m]> <midnightmage[m]> "it is a standard quirk, they did..." <- if you link the branch where you are trying to refactor to use the std::mutexes i would like to help :D
16:59:01 <selsta> atomfried[m]: we won't move to 17 for a while
16:59:34 <selsta> it would require us to update the min supported macOS version to 10.14 (we currently support 10.10)
17:01:49 <selsta> midnightmage[m]: I plan to merge to C++14 patch soon so it would be fine if you use shared_timed_mutex
17:37:22 <UkoeHB> I want to memwipe the key stored in this string in case it is a secret (https://github.com/UkoeHB/monero/blob/ace6c889a29838dde8494a82e21336bed6336314/src/mock_tx/seraphis_crypto_utils.cpp#L704). What is the best way to do that? `memwipe(const_cast<char*>(hash.data()), hash.size())`?
17:38:08 <moneromooo> There's a wipeable_string class that does it automatically.
17:38:17 <UkoeHB> Ah neat thank you
20:00:54 <UkoeHB> Has there been any interest/thought put into moving from keccak to a faster hashing algorithm (for hot-path stuff anyway)?
20:12:56 <moneromooo> Not that I know of.
21:49:20 <hyc> how much difference would there really be
21:49:47 <hyc> blake2 or blake3 would be the only faster candidates, no?
21:51:53 <UkoeHB> https://github.com/BLAKE3-team/BLAKE3/blob/master/media/speed.svg
21:52:37 <UkoeHB> However, idk how that compares to an EC op
21:54:06 <hyc> these are speeds using 16KB data. what's the typical chunk of data we hash?
21:56:42 <UkoeHB> it varies from ~32-3kB (I think Grootle transcript hashes need on the order of 3-8kB to capture all the ring members)
21:56:55 <UkoeHB> 32bytes-3kB
21:57:21 <hyc> and the smaller the chunk, the more proportional time spent in setup overhead
21:59:08 <UkoeHB> ah yeah good point
22:04:39 <UkoeHB> The blake3 paper has more detailed benchmarks (figure 5: https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf).
22:07:10 <Ched[m]> hello!
22:09:13 <Ched[m]> sorry if this is a really common question - I'd like to learn programming as a hobby with the hope of contributing to monero, as I really vibe with it as a concept. what language should I begin with?
22:11:11 <UkoeHB> The main code base is C++ (I recommend learncpp.com), but projects associated with Monero use other languages.
22:14:18 <Ched[m]> thankyou :)
23:24:03 <jimmyt[m]> <Rucknium[m]> "jimmyt: That question is..." <- Thanks