00:01:44 <m-relay> <o​frnxmr:monero.social> https://github.com/monero-project/monero/pull/8815
00:56:32 <m-relay> <a​ck-j:matrix.org> I’d vote to focus on fcmp++ instead of hard forking twice in a short period of time. The statistical attack has been present since 2018 and a ring bump wont fix the root of the issue, but fcmp will.
01:03:06 <m-relay> <o​frnxmr:monero.social> Again, i'm against a ring bump
01:03:49 <m-relay> <o​frnxmr:monero.social> Hard forking twice in a short period of time is better than breaking than putting all eggs in one baskey
01:04:08 <m-relay> <s​yntheticbird:monero.social> Latter give bigger omelette
01:04:10 <m-relay> <o​frnxmr:monero.social> we have 2 yrs worth of backlog on master, + randomx + fcmp++
01:07:14 <m-relay> <o​frnxmr:monero.social> The first hard fork would mostly be to ensure that _everyone_ is running master, reducing technical debt, adding in the coinbase decoy stuff (because, why not), and randomxv2
01:09:17 <m-relay> <o​frnxmr:monero.social> its not like the first hard fork would be a big one. Its basically ready. Just a wakeup call to everyone still runnin 18.0.0
01:10:35 <m-relay> <o​frnxmr:monero.social> and if its not ready, that just shows that, regardless of fcmp++, the foundation code (master) isnt ready to be deployed
06:45:35 <m-relay> <r​brunner7:monero.social> Regarding the contest a possible and maybe not-altogether-improbable scenario popped up in my mind: Several persons implement the same algorithmic improvement, and as a result the execution speeds of several solutions are so close together that the difference is below measurement uncertainty. Would we split the price in such a case? jberman
09:01:44 <m-relay> <r​brunner7:monero.social> Or maybe it would make sense to move on to additional criteria: Which of those basically speed-identical solutions has the cleaner code? The better commented code? The better modularized code? And so on
15:00:19 <NorrinRadd> that last one sounds good rbrunner7
15:14:33 <m-relay> <s​packle:monero.social> For OSPEAD, I would think you can avoid the risk of low adoption by delaying the DSA switch until a time after the updated software is published.
15:14:34 <m-relay> <s​packle:monero.social> Famous last words, but I do not understand why this would be profoundly onerous. One of the listed improvements is a direct update of the log-gamma shape and rate parameters.
15:32:00 <m-relay> <j​berman:monero.social> "We reserve the right to select a winner based on our discretion, and rule out submissions for reasons we may not have identified above. For example, if the fastest code has issues we did not identify above, we may select the 2nd fastest code. We aim to ship the winning code in Monero."
15:33:08 <m-relay> <j​berman:monero.social> @rbrunner7  I think this part adequately covers it without endless debate over additional critetia before we see code
15:48:43 <m-relay> <r​ucknium:monero.social> jberman: I'm trying to decide whose job it is: Should you or I contact binaryFate about the suggestion to fund the optimization competition prize with XMR from the General Fund?
15:53:23 <m-relay> <p​lowsof:matrix.org> Rucknium is the request finalised / easily linked to yet? https://libera.monerologs.net/monero-research-lab/20250305#c504881
16:01:41 <m-relay> <r​ucknium:monero.social> jberman would be able to confirm all the details. I now realize that makes it his job :)
16:09:09 <m-relay> <p​lowsof:matrix.org> sgp_ for the pending veridise CCS payment (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/449#note_28862) so you want $11,750 @ time of sending , or is there an extra % on top required?
16:18:17 <m-relay> <s​gp_:monero.social> 11750 is fine
16:19:31 <m-relay> <s​gp_:monero.social> https://matrix.monero.social/_matrix/media/v1/download/monero.social/BZrluzIcTJyPjWdesfpWcYLl
16:19:33 <m-relay> <s​gp_:monero.social> final version ^
16:22:27 <m-relay> <s​gp_:monero.social> I am speaking with Veridise later today to discuss the next audits
16:47:17 <m-relay> <g​ingeropolous:monero.social> for the contest.... is it assumed the optimizations will be single-threaded?
16:55:50 <m-relay> <g​ingeropolous:monero.social> and/or not utilizing GPU accelerators?
16:58:01 <m-relay> <g​ingeropolous:monero.social> well i just bought the 5600G regardless.
18:31:32 <m-relay> <r​ucknium:monero.social> spackle: IMHO, your suggestion is worth investigating. I think I have enough reason to look into the area of research I discuss in Section 16 "Postestimation Classification of On-Chain Rings into DSAs" of https://github.com/Rucknium/OSPEAD/blob/main/CCS-milestone-1/pdf/PRIVATE-OSPEAD-Fully-Specified-Estimation-Plan.pdf
20:44:19 <m-relay> <j​berman:monero.social> "that makes it his job" -> will ping binary :)
20:47:03 <m-relay> <j​berman:monero.social> gingeropolous: yes to single-threaded, no to GPU accelerators
20:53:58 <m-relay> <r​ucknium:monero.social> Thanks, jberman
22:09:06 <m-relay> <g​ingeropolous:monero.social> so to clarify, because my grammar was odd: single threaded, no GPU accelerators.