<Elijah[m]> "Thanks abberant , that did the..." <- Have you only swapped or have you also find a flag?

<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 monerodocs.org/interacting/monerod-reference

through my limited knowledge, some things that use randomx like p2pool and xmrig have "light" modes that use a lot less memory

lightmode is ok for block verification but too slow for mining

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

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?

I used it some years ago, and functionality is ok if not stellar.

Or do real devs nowadays set up their own matrix server for a workgroup?

no need for a server. A room will do it 🙂

but yeah drop taiga

In any case I don't want to spend too much time myself with setting up something. Right going to work would be ideal :)

rbrunner: then github is probably the best choice

curious to know more about the workgroup btw 🙂

Ok, thanks for the tip, will have a look.

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.

Who is missing? I think most of them already signaled support through fluffypony

ErCiccione: Where can I see this fluffypony post/reply ? Or was it private discussion

nikg83[m]: it's on gitlab repo.getmonero.org/monero-project/ccs-front/-/issues/5

selsta, sarang and alreadyburnt _ have commits in the frontend repo.

i think xiphon's approval is missing

I think the proposals repo doesn't need a license.

Just fork the wownero funding system if you're worried about license. Exactly what Firo did fcs.firo.org/proposals

repo.getmonero.org/monero-project/ccs-back/-/merge_requests/16 is already open, and I think everyone agreed

it just has to get merged

selsta: your commit is in the frontend repo, but could be something minor anyway. I don't think xiphon agreed

plowsof: will look into it, thanks

xiphon literally helped to port it for firo

so he must have agreed

if someone opens one for the frontend repo I can approve it

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!

kwxmr[m]: I am aiming at 128 right now, you can check monero-project/research-lab #91

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

Basically the goal is to not increase verification costs/tx sizes too much compared to the existing protocol.

2x-ing the cost is too much, so 256 is off the table, leaving 128 as the best candidate

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?

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): github.com/UkoeHB/monero/tree/seraphis_lib

Ok thanks!

moneromooo: did you write a patch for this? monero-project/monero #8120

I think you wanted to but maybe you forgot about it.

I did not. I thought someone else might, as it's trivial. Maybe someoe wants their first monero patch :)

If not, I can do it.

But yes, I had forgot about it, thanks.

I looked at it but wasn't sure what the issue was and why !! fixes it.

Ah, !! maps 0 to 0 and non zero to 1.

yes, I know that

but I thought that inside an if an integer is fine

Then maybe I'm wrong :) Let me look again.

0 = false and everything else is true

Yes. I think it might be that some compilers are technically allowed to assume a bool is only 0 and 1.

So if your "bool" has 247, a compiler might generate, eg, "if (b==1) goto true_case; false_case_here; "

Assumption. Though I am fairly sure that's it.

did you also look at portable_storage_from_bin.h:157 ?

The messages are the same. I did not asctually look at the code, just at the bug report.

it's a template function so just adding !! didn't seem correct to me

Ah indeed. You'd have to change only for the bool case. Well, ping me tomorrow, I'm about to go afk now.

ok, it's not too important, I'm just going through the open issues and trying to close everything possible

Got it. Thanks.

why is the mdb zerokval 8 bytes long?

because.

all LMDB internal headers are 8-byte aligned. using an 8-byte key preserves internal alignment, so the data being pointed to remains aligned.

and all of the data is using 8byte integer keys...

more importantly - why do you care?

a zerokval occurs only once in its DB table. so it's not like it's using up excess space.

and it's only once because of DUPFIXED, right?

yes

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.