08:27:29 <Charlbermensch[m> <Elijah[m]> "Thanks abberant , that did the..." <- Have you only swapped or have you also find a flag?
08:32:59 <abberant[m]> <Charlbermensch[m> "Have you only swapped or have..." <- I just read through the flags and didnt find anything, maybe can try something else in the performance section tho https://monerodocs.org/interacting/monerod-reference/
08:35:50 <abberant[m]> through my limited knowledge, some things that use randomx like p2pool and xmrig have "light" modes that use a lot less memory
08:44:54 <hyc> lightmode is ok for block verification but too slow for mining
08:45:50 <hyc> monerod uses light mode already. it may try to use full mode if you try to use its built in miner, but otherwise only uses light mode
14:13:57 <rbrunner> Is using taiga.getmonero.org for a brand new dev-related workgroup / project a good idea? Or is this on its way out and somebody will soon switch off the light?
14:14:37 <rbrunner> I used it some years ago, and functionality is ok if not stellar.
14:15:13 <rbrunner> Or do real devs nowadays set up their own matrix server for a workgroup?
14:20:57 <ErCiccione> no need for a server. A room will do it 🙂
14:21:06 <ErCiccione> but yeah drop taiga
14:26:14 <rbrunner> In any case I don't want to spend too much time myself with setting up something. Right going to work would be ideal :)
14:48:35 <ErCiccione> rbrunner: then github is probably the best choice
14:49:21 <ErCiccione> curious to know more about the workgroup btw 🙂
14:49:27 <rbrunner> Ok, thanks for the tip, will have a look.
15:06:09 <ErCiccione> Can we get all copyright holders of the CCS frontend and backend to approve the license if they didn't do it already? Otherwise we cannot fork it for Haveno.
15:06:27 <ErCiccione> Who is missing? I think most of them already signaled support through fluffypony
15:09:33 <nikg83[m]> ErCiccione: Where can I see this fluffypony post/reply ? Or was it private discussion 
15:10:11 <ErCiccione> nikg83[m]: it's on gitlab https://repo.getmonero.org/monero-project/ccs-front/-/issues/5
15:11:05 <ErCiccione> selsta, sarang and alreadyburnt _ have commits in the frontend repo.
15:11:24 <ErCiccione> i think xiphon's approval is missing
15:12:33 <selsta> I think the proposals repo doesn't need a license.
15:13:13 <plowsof[m]> Just fork the wownero funding system if you're worried about license. Exactly what Firo did https://fcs.firo.org/proposals 
15:13:33 <plowsof[m]> https://funding.wownero.com/proposals
15:13:54 <selsta> https://repo.getmonero.org/monero-project/ccs-back/-/merge_requests/16 is already open, and I think everyone agreed
15:14:00 <selsta> it just has to get merged
15:51:34 <ErCiccione> selsta: your commit is in the frontend repo, but could be something minor anyway. I don't think xiphon agreed
15:51:38 <ErCiccione> plowsof: will look into it, thanks
15:52:01 <selsta> xiphon literally helped to port it for firo
15:52:07 <selsta> so he must have agreed
15:52:31 <selsta> if someone opens one for the frontend repo I can approve it
20:38:56 <kwxmr[m]> Hi, do you confirm that seraphis is going for 64 ring size, is it decided or still in debate? Where can I find last updates about seraphis, thanks!
20:41:55 <UkoeHB> kwxmr[m]: I am aiming at 128 right now, you can check https://github.com/monero-project/research-lab/issues/91
20:46:43 <kwxmr[m]> Ok thanks for info! I suppose it will be between 64,128 and 256 right? What are the tradeoffs in short, I mean for a none professional audience how would you explain it with simple words? thanks
20:50:40 <UkoeHB> Basically the goal is to not increase verification costs/tx sizes too much compared to the existing protocol.
20:52:18 <UkoeHB> 2x-ing the cost is too much, so 256 is off the table, leaving 128 as the best candidate
20:53:00 <kwxmr[m]> Ok thanks! And  Seraphis-Concise, Seraphis-Merge, Seraphis-Squashed refer to specific implementations of the seraphis abstraction, right? And if I understand Seraphis-Squashed is the more likely, maybe the one you started to implement in the monero repositrory? 
20:55:09 <UkoeHB> Yes, each of those use slightly different proofs. And yes, I have been working on Seraphis-Squashed in my seraphis_lib branch (which also has jamtis now): https://github.com/UkoeHB/monero/tree/seraphis_lib
20:55:42 <kwxmr[m]> Ok thanks!
22:53:58 <selsta> moneromooo: did you write a patch for this? https://github.com/monero-project/monero/issues/8120
22:54:04 <selsta> I think you wanted to but maybe you forgot about it.
22:59:21 <moneromooo> I did not. I thought someone else might, as it's trivial. Maybe someoe wants their first monero patch :)
22:59:24 <moneromooo> If not, I can do it.
22:59:35 <moneromooo> But yes, I had forgot about it, thanks.
23:20:20 <selsta> I looked at it but wasn't sure what the issue was and why !! fixes it.
23:20:57 <moneromooo> Ah, !! maps 0 to 0 and non zero to 1.
23:21:04 <selsta> yes, I know that
23:21:12 <selsta> but I thought that inside an if an integer is fine
23:21:17 <moneromooo> Then maybe I'm wrong :) Let me look again.
23:21:30 <selsta> 0 = false and everything else is true
23:22:04 <moneromooo> Yes. I think it might be that some compilers are technically allowed to assume a bool is only 0 and 1.
23:22:57 <moneromooo> So if your "bool" has 247, a compiler might generate, eg, "if (b==1) goto true_case; false_case_here; "
23:23:27 <moneromooo> Assumption. Though I am fairly sure that's it.
23:24:05 <selsta> did you also look at portable_storage_from_bin.h:157 ?
23:24:37 <moneromooo> The messages are the same. I did not asctually     look at the code, just at the bug report.
23:25:07 <selsta> it's a template function so just adding !! didn't seem correct to me
23:27:05 <moneromooo> Ah indeed. You'd have to change only for the bool case. Well, ping me tomorrow, I'm about to go afk now.
23:28:11 <selsta> ok, it's not too important, I'm just going through the open issues and trying to close everything possible
23:29:12 <moneromooo> Got it. Thanks.
23:47:36 <TheCharlatan> why is the mdb zerokval 8 bytes long?
23:49:47 <hyc> because.
23:50:50 <hyc> all LMDB internal headers are 8-byte aligned. using an 8-byte key preserves internal alignment, so the data being pointed to remains aligned.
23:51:51 <hyc> and all of the data is using 8byte integer keys...
23:52:36 <hyc> more importantly - why do you care?
23:52:59 <hyc> a zerokval occurs only once in its DB table. so it's not like it's using up excess space.
23:54:55 <TheCharlatan> and it's only once because of DUPFIXED, right?
23:55:03 <hyc> yes
23:59:14 <TheCharlatan> was just curious about the length, everything else is reasonably well documented, but the length seemed arbitrary. The allignment reasoning makes sense to me, thanks. I was spending some time going through the database code and am trying to build a good mental model of it.