15:00:55 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in two hours
16:25:43 <m-relay> <j​berman:monero.social> Unfortunately I won't be able to make today's meeting, I shared my latest, an update regarding FCMP++ optimization competition, and FCMP++ research here: https://github.com/monero-project/meta/issues/1162#issuecomment-2685563055
16:26:56 <m-relay> <j​berman:monero.social> gingeropolous: wondering if you have a suggestion for one of your machines you think we could/should use for the FCMP++ optimization competition? Imo the main requirement really is that it will be around several months from now (when the competition ends)
16:36:59 <m-relay> <r​ucknium:monero.social> I wrote a FAQ for the OSPEAD repo: https://github.com/Rucknium/OSPEAD/tree/main?tab=readme-ov-file#frequently-asked-questions-faqs
16:38:29 <m-relay> <r​ucknium:monero.social> Based of the FAQ, there is a 4-out-of-7 probability that the answer to your question is "No" :P
17:00:44 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/1162
17:00:54 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:00:58 <m-relay> <s​yntheticbird:monero.social> Hello there
17:01:05 <m-relay> <a​rticmine:monero.social> Hello
17:01:07 <rbrunner> Hello
17:01:08 <m-relay> <c​haser:monero.social> hello
17:01:50 <m-relay> <j​effro256:monero.social> Howdy
17:02:09 <m-relay> <b​oog900:monero.social> hi
17:03:01 <m-relay> <v​tnerd:monero.social> hi
17:03:06 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:04:12 <m-relay> <r​ucknium:monero.social> me: Prepared and posted the OSPEAD Hackerone and CCS Milestone 1-2 documents and code: https://github.com/Rucknium/OSPEAD . Worked on game theory of subnet deduplication as a spy node countermeasure.
17:04:25 <m-relay> <s​gp_:monero.social> Hello
17:05:27 <m-relay> <v​tnerd:monero.social> updated socks5 review, and trying to figure out the bug reports from my recently merged PRs
17:06:26 <m-relay> <j​effro256:monero.social> Responding to reviews for #9135, trying to reproduce bugs on release branch, and improving FCMP++/Carrot transaction construction code.
17:07:22 <m-relay> <r​ucknium:monero.social> 3) Prize contest to optimize some FCMP cryptography code. https://github.com/j-berman/fcmp-plus-plus-optimization-competition
17:07:53 <m-relay> <r​ucknium:monero.social> jberman had to miss this meeting, but said in his comment ( https://github.com/monero-project/meta/issues/1162#issuecomment-2685563055 ) "On the FCMP++ optimization competition: we need to settle on a machine to use for benchmarks, and the repo could use a review"
17:10:35 <m-relay> <r​ucknium:monero.social> Maybe this issue was already discussed, but I didn't see it in the repo: One-sided execution of licensing. Say that someone wins the competition, but wants to negotiate for more XMR before assigning the appropriate open source license to their code. How to avoid?
17:10:45 <m-relay> <r​ucknium:monero.social> I think this can be avoided by requiring that contestants submit a Monero address with their code submission. When someone is chosen, the XMR gets sent to them and the code is given the open source license. Therefore, there is no waiting on action by a contestant.
17:11:44 <m-relay> <c​haser:monero.social> can't they still use their own choice of license?
17:12:02 <m-relay> <r​ucknium:monero.social> Yes, but it would be dual-licensed in that case
17:12:32 <m-relay> <r​ucknium:monero.social> When they submit, the terms of the submission are that it gets the open source license if it is the winner (and they get the prize XMR)
17:14:23 <m-relay> <j​effro256:monero.social> Why don't we say put the Monero BSD license on your code to begin with, otherwise the submission is invalid? I'm assuming that the submissions are private to the judges until the winner is picked. We can return the code back to the losers with all rights reserved before, yeah? (IDK I'm not a lawyer)
17:15:18 <m-relay> <r​ucknium:monero.social> They contestants may fear that they won't get the prize XMR if they already give the open source rights in the beginning
17:15:37 <m-relay> <c​haser:monero.social> I'm not an expert at licenses, but what you outlined still sound like they could "show" us an attractive submission that's licensed under their own terms and essentially blackmail us to pay
17:17:43 <m-relay> <v​tnerd:monero.social> Wouldn't they have to disclose the code so that it can be compiled into the benchmark utility? Seems odd that we would even accept an unknown binary
17:17:46 <m-relay> <j​effro256:monero.social> If they fear that we will steal their code ..... why would they ever believe that we would pay them in the first place? IDK, if they don't trust us to blatantly use/license their code correctly, they probably wouldn't be sacrificing their man hours for the possibility of payment in the first place.
17:18:35 <m-relay> <v​tnerd:monero.social> jeffro256: weve had 1-2 people try to hold code hostage in the past, under fear of non-payment
17:18:42 <m-relay> <r​ucknium:monero.social> jeffro256: Because that action would be a violation of open source licensing rules
17:20:25 <rbrunner> Sounds somehow like an "unsolvable" problem to, not possible to do "trustless". We and the contestant may *have* to trust each other
17:20:51 <rbrunner> *problem to me
17:22:56 <m-relay> <r​ucknium:monero.social> AFAIK, under my suggestion, the contestants just have to trust that the Monero Project won't violate open source rules. If the contestants have to assign the license before submission, then they would also have to trust that the Monero Project won't renege on its word. If this isn't considered a possible issue, that's fine, We can keep it as it is.
17:24:36 <rbrunner> They have to trust us to pay also?
17:24:59 <rbrunner> Ah, you mean pay first, license afterwards
17:25:07 <NorrinRadd> "if they don't trust us to blatantly use/license their code correctly, " -- agreed
17:25:26 <NorrinRadd> ignore that 
17:25:40 <NorrinRadd> "why would they ever believe that we would pay them in the first place?" -- agreed
17:25:52 <NorrinRadd> if trust is an issue, they won't participate in the first place
17:26:13 <m-relay> <s​agewilder:unredacted.org> In agreement with Rucknium's approach, a clear definition of the license should be explicitly stated in the reward agreement to prevent any potential loopholes that could allow one party to misappropriate the submission. Even if unlikely.
17:26:14 <m-relay> <s​agewilder:unredacted.org> Regarding the issue of trust, as this is my first collaboration with Monero, I consider the most solid basis possible for any work I submit.
17:26:19 <m-relay> <r​ucknium:monero.social> Ok. If they submit code with the open source license already attached, then that eliminates the issue of having code held hostage from the Monero Project
17:27:10 <m-relay> <r​ucknium:monero.social> Reminder: sagewilder is a likely contestant FWIW.
17:28:14 <rbrunner> "Pay first, delivery afterwards" does make some sense.
17:28:21 <m-relay> <a​rticmine:monero.social> We must have consistent licencing for the project as a whole. Right now this is BSD. If we choose to change the license this is a totally separate discussion from this competition
17:28:39 <rbrunner> They trust us to pay, we trust them to license after payments. It's mutual.
17:29:06 <m-relay> <j​effro256:monero.social> A license that is sort of unambiguous in a code-like manner, but may or may not hold up in court is: "this file is copyrighted by participant X, all rights reserved, unless a Monero payment proof to address A for prize amount P can be provided, in which case this file is copyright of the Monero Project"
17:29:33 <rbrunner> Clever
17:29:45 <NorrinRadd> rbrunner: that requires 2 trust instances.  if the license is present upon submission, only 1 trust instance is required 
17:29:47 <m-relay> <r​ucknium:monero.social> A semi-smart contract :)
17:29:50 <rbrunner> You invented a new license
17:30:26 <m-relay> <a​rticmine:monero.social> We need to specify our license as it is now as a condition of participation in the contest
17:30:31 <rbrunner> NorrinRadd: Yes. As a power shift away from the contestant, towards the Monero project
17:31:11 <NorrinRadd> yes clever Re: Jeffro256
17:31:46 <m-relay> <s​agewilder:unredacted.org> This text and its formulation are satisfactory to me.
17:32:09 <m-relay> <a​rticmine:monero.social> The last thing we need is new "creative" licences
17:32:28 <rbrunner> Surely we would re-license afterwards? Or would that be problematic?
17:32:44 <m-relay> <a​rticmine:monero.social> So the current Monero license is a condition of participation
17:33:28 <m-relay> <a​rticmine:monero.social> We cannot relicense afterwards.
17:33:36 <m-relay> <r​ucknium:monero.social> I don't know if the "conditional license" needs to be assigned to the code submission itself. You can add it as a stipulation in the contest rules.
17:33:40 <m-relay> <s​yntheticbird:monero.social> what? we can't relicense BSD ?
17:34:46 <m-relay> <a​rticmine:monero.social> We can relicense the current BSD but not the other way
17:35:26 <m-relay> <a​rticmine:monero.social> For example turn GPL v3 into BSD
17:35:45 <m-relay> <s​yntheticbird:monero.social> the joy of GPL
17:35:56 <NorrinRadd> it's not a relicense imo. "unless x, in which case this file's license is "abc"" -- it's self contained; all present uplon original submission == not a re-license 
17:37:45 <rbrunner> We hope for several submissions, right? And the chance of reneg / code taken hostage is there, but probably on the smaller side? So in that unlikely case we take the runner up, problem solved.
17:38:03 <m-relay> <a​rticmine:monero.social> There are many arguments in favor and against for example regarding a strong copyleft such as GPL v 3.
17:38:22 <m-relay> <s​yntheticbird:monero.social> imo it should be MIT
17:38:47 <m-relay> <s​yntheticbird:monero.social> just for the ease of mind of the ecosystem
17:39:08 <m-relay> <j​effro256:monero.social> I think Rucknium is saying that that might discourage participants b/c we can legally use their code without awarding them the prize money, even if we pinky promise before-hand that we won't
17:39:16 <m-relay> <a​rticmine:monero.social> This competition is not the place to discuss changing the Monero license
17:39:35 <m-relay> <b​oog900:monero.social> You can relicense GPL if all authors agree, with jeffro256's idea they are giving permission to relicense if they receive payment
17:39:43 <m-relay> <s​yntheticbird:monero.social> oh maybe i misunderstood, i thought you were discussing the license of the submission
17:40:05 <m-relay> <r​ucknium:monero.social> jeffro256: Yes, that is what I am saying.
17:40:49 <NorrinRadd> they are welcome to not participate 
17:40:54 <m-relay> <j​effro256:monero.social> It wouldn't be changing the license of all of the Monero, just that submission
17:41:52 <m-relay> <a​rticmine:monero.social> If they are chosen they agree to the current Monero license.
17:42:01 <NorrinRadd> if conditional are allowed in legal agreements I believe. it's just a license with an if condition. It's not a license change.
17:42:18 <m-relay> <j​effro256:monero.social> AFAIK, in a codebase, not every single line of code has to have the same license. Some files in the repo might have an MIT license, some might have BSD, the main LICENSE file provided in a git repo is just a "default" license, but it doesn't/can't override existing licenses
17:43:02 <m-relay> <a​rticmine:monero.social> As long as the licenses are compatible
17:44:57 <m-relay> <r​ucknium:monero.social> We have a couple more items to get to. We can discuss licensing issues with the contest next meeting, too. jberman isn't in attendance right now. And I'm sure kayabanerve  would like to give input too since he like to give input about licensing.
17:45:16 <m-relay> <c​haser:monero.social> there is a big differential. an established free software project with long-term contributors is much less likely to renege on their word than a pseudonymous contestant who can just assume a new identity without any costs.
17:45:18 <m-relay> <a​rticmine:monero.social> Typically it is one way compatibility. Mixing GPL and BSD for example leads to GPL the whole code
17:45:39 <m-relay> <r​ucknium:monero.social> On which hardware to perform the benchmarks, the MRL computing cluster has some powerful machines:
17:45:48 <m-relay> <s​yntheticbird:monero.social> New achievement unlocked: KayabaNerve, the lawyer 🖊️
17:45:50 <m-relay> <r​ucknium:monero.social> 3700x
17:45:52 <m-relay> <r​ucknium:monero.social> 3900x
17:45:54 <m-relay> <r​ucknium:monero.social> 5900x
17:45:56 <m-relay> <r​ucknium:monero.social> 64 thread AMD Ryzen Threadripper 3970x
17:45:58 <m-relay> <r​ucknium:monero.social> 256 thread 2x 7h12 server
17:46:00 <m-relay> <r​ucknium:monero.social> Epyc server
17:46:07 <m-relay> <r​ucknium:monero.social> And some low-power machines:
17:46:08 <m-relay> <r​ucknium:monero.social> AMD C-50 Processor
17:46:10 <m-relay> <r​ucknium:monero.social> Intel(R) Core(TM)2 Duo CPU T8100  @ 2.10GHz
17:46:13 <m-relay> <j​effro256:monero.social> So you're saying to specify the terms of the contest that "paid/winning submissions became copyright of the Monero project" and to have participants submit their code with no license attached (default is always copyright of the author)?
17:46:50 <m-relay> <a​rticmine:monero.social> I believe we have to distinguish here between the license for the submission and the license the winner agrees for their code ahead of time if they win
17:47:22 <m-relay> <a​rticmine:monero.social> The latter has to be BSD.
17:47:53 <m-relay> <b​oog900:monero.social> that was jeffro's idea AFAIK
17:48:13 <m-relay> <s​yntheticbird:monero.social> jeffro should license his idea in the chat next time
17:48:18 <m-relay> <s​yntheticbird:monero.social> wrong reply
17:48:40 <m-relay> <a​rticmine:monero.social> The submission license should be GPL v3 compatible
17:50:23 <m-relay> <j​effro256:monero.social> My opinion is that we should benchmark and what we believe will be the "median" user hardware in the short term future. So new, but mid-range price range for new hardware
17:50:34 <m-relay> <j​effro256:monero.social> *for what we
17:50:55 <m-relay> <j​effro256:monero.social> new *consumer-grade* hardware
17:51:10 <m-relay> <j​effro256:monero.social> So probably not AMD EPYCs
17:51:33 <rbrunner> Good idea. A server machine may have large first-level caches that make things fast, which might not happen on a "normal" machine
17:52:01 <m-relay> <r​ucknium:monero.social> AFAIK, there is no mid-range consumer hardware in the MRL computing cluster. So we may have to go somewhere else for the bechmark machine.. gingeropolous , any comments?
17:52:30 <m-relay> <s​yntheticbird:monero.social> 3700X is mid range imo
17:54:21 <m-relay> <r​ucknium:monero.social> 4) Release of OSPEAD HackerOne and CCS milestone submissions. https://github.com/Rucknium/OSPEAD
17:54:52 <m-relay> <r​ucknium:monero.social> Comments or questions on this ^?
17:57:18 <m-relay> <c​haser:monero.social> what do you all think about publishing a public-facing post on how these findings practically affect user privacy? IMHO this would be due as responsibility to users who rely on Monero's privacy. Some parts of Rucknium's FAQ looks like a good starting point.
17:58:23 <rbrunner> Sounds good. There have been some insecurities, e.g. about that "ring size eduction to 4.2" or so, i.e. how to actually interpret that
17:58:28 <m-relay> <r​ucknium:monero.social> It's possible, but a little difficult because it affects different threat models differently.
17:58:31 <rbrunner> On Reddit
17:59:21 <m-relay> <s​yntheticbird:monero.social> guys i swear one day we will have a getmonero.org blog that is working. 2 more weeks before new post
17:59:24 <m-relay> <r​ucknium:monero.social> I hope my horse race betting metaphor helps people understand. AFAIK, Monero users are gamblers anyway 😉
17:59:59 <rbrunner> Horse race betting? I have probably overlooked that.
18:00:15 <m-relay> <c​haser:monero.social> true, it's difficult to put the outcomes into exact pigeonholes. however, we can distinguish (as you already have).
18:00:42 <m-relay> <r​ucknium:monero.social> rbrunner: In the FAQ: https://github.com/Rucknium/OSPEAD?tab=readme-ov-file#frequently-asked-questions-faqs
18:00:54 <m-relay> <r​ucknium:monero.social> "Q: Does the MAP Decoder attack work by eliminating decoys?"
18:01:03 <m-relay> <c​haser:monero.social> if we are proper, it should go to the official blog.
18:01:06 <rbrunner> Thanks!
18:01:44 <rbrunner> Yeah, nothing against a getmonero.org blog post. With pointer to it on Reddit, monero.town and maybe elsewhere
18:02:29 <m-relay> <r​ucknium:monero.social> IMHO, it may be a good idea for someone besides myself to reproduce the results from the small validation simulation: https://rucknium.github.io/OSPEAD/CCS-milestone-2/OSPEAD-docs/_book/successful-simulation.html#sec-successful-simulation-code
18:02:43 <m-relay> <c​haser:monero.social> rbrunner: sounds great
18:03:01 <m-relay> <r​ucknium:monero.social> Reproducing the whole Monero estimate isn't possible right now on consumer-grade hardware, but it could be possible with improvements to the code.
18:03:27 <m-relay> <c​haser:monero.social> inb4 OSPEAD optimization contest
18:03:30 <m-relay> <r​ucknium:monero.social> The reproducer would have to install the right packages first:
18:03:30 <m-relay> <r​ucknium:monero.social> https://rucknium.github.io/OSPEAD/CCS-milestone-2/OSPEAD-docs/_book/requirements.html
18:03:32 <m-relay> <r​ucknium:monero.social> https://github.com/Rucknium/OSPEAD?tab=readme-ov-file#installing-the-decoyanalysis-r-package
18:04:09 <m-relay> <r​ucknium:monero.social> chaser: We actually had two proposal already to do that, but circumstances prevented it. So for now I am on my own
18:05:28 <m-relay> <c​haser:monero.social> you mean people volunteering? or an actual contest? I didn't know that!
18:06:30 <m-relay> <r​ucknium:monero.social> These two functions are the specific speedup targets (and I already wrote instructions for someone unfamiliar with the R code to re-implement):
18:06:32 <m-relay> <r​ucknium:monero.social> https://github.com/Rucknium/OSPEAD/blob/main/CCS-milestone-2/decoyanalysis/R/bjr.R#L534-L587
18:06:34 <m-relay> <r​ucknium:monero.social> https://github.com/Rucknium/OSPEAD/blob/main/CCS-milestone-2/decoyanalysis/R/bjr.R#L719-L894
18:06:58 <plowsof> chaser Rucknium is this one of the two proposals? https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/375
18:07:17 <m-relay> <r​ucknium:monero.social> First, isthmus was going to task one of his employees with re-implementing major parts in C++ 
18:07:18 <m-relay> <r​ucknium:monero.social> Yes, that one plowsof. Thanks
18:08:28 <plowsof> mj xmr the other for MAGIC?
18:08:37 <m-relay> <r​ucknium:monero.social> Then later, after I re-factored, hyc was going to ask someone to implement those ^ small parts in C. But it was my fault it was delayed (since I was investigating an inconsistency issue in Monte Carlo simulations that turned out to be rooted in the intra-ring dependence issues)
18:09:21 <plowsof> https://github.com/MAGICGrants/Monero-Fund/issues/21 
18:09:32 <m-relay> <j​effro256:monero.social> This is purely optional, but it would be nice to have these four plots on the same graph: A) empirical distribution of all ring members in Monero B) gamma distribution we currently use C) Estimated real spend distribution as demixing of A and B and other analysis from your work, and D) the distribution you recommend in Milestone II to approximate C
18:11:59 <m-relay> <j​effro256:monero.social> The beta distribution recommended was interesting
18:12:23 <m-relay> <r​ucknium:monero.social> jeffro256: Except for (A), those are plotted here in Figure 3.1: https://rucknium.github.io/OSPEAD/CCS-milestone-2/OSPEAD-docs/_book/performance-evaluation.html#fig-decoy-distributions-top-1-3-not-log
18:12:40 <m-relay> <r​ucknium:monero.social> I meant 13.1
18:13:07 <m-relay> <r​ucknium:monero.social> Vertical log scale here in Figure 13.3: https://rucknium.github.io/OSPEAD/CCS-milestone-2/OSPEAD-docs/_book/performance-evaluation.html#fig-decoy-distributions-top-1-3-log
18:13:35 <m-relay> <r​ucknium:monero.social> I'll work on getting (A) in the same plot with the others
18:16:01 <m-relay> <j​effro256:monero.social> Are the output ages since creation or since spendability
18:16:02 <m-relay> <r​ucknium:monero.social> IMHO, the generalized beta distribution of the second kind (GB2) won because it is flexible. It might not be the best to actually implement because the code to make those draws might not be widely available in relevant programming languages, but those details can be discussed down the road. The difference between the top 4 choices wasn't very much (0.2 percentage points attack suc<clipped message
18:16:04 <m-relay> <r​ucknium:monero.social> cess probability).
18:16:30 <m-relay> <r​ucknium:monero.social> Table 13.1 has the comparison of the fitted proposed decoy distributions: https://rucknium.github.io/OSPEAD/CCS-milestone-2/OSPEAD-docs/_book/performance-evaluation.html#tbl-main-attack-success
18:16:37 <m-relay> <r​ucknium:monero.social> Spendability.
18:18:21 <m-relay> <r​ucknium:monero.social> So the edits to the decoy selection algorithm that jberman made in 2021 would be reverted. Those edits moved the Moser-based gamma from beginning at the 10 block lock to the chain tip. and then re-distributed the "unspendable" part of the gamma distribution t the recent spend window
18:18:57 <m-relay> <r​ucknium:monero.social> The Moser paper estimated their distribution on historical data when the 10 block lock wasn't a consensus rule and some wallet implementations violated it.
18:19:07 <m-relay> <k​ayabanerve:matrix.org> Rule #1 requires an approved license Rucknium
18:21:20 <m-relay> <k​ayabanerve:matrix.org> The approved licenses is a file in-repo which doesn't exist. I'd recommend public domain (CC0, unlicense), MIT, BSD-1, BSD-2, BSD-3, and maybe some LGPLs.
18:22:00 <m-relay> <r​ucknium:monero.social> So, the license had to be applied before submission, under the draft rules?
18:24:22 <m-relay> <a​rticmine:monero.social> I oppose LGPLs. We should not be changing the license of the Monero project by this competition
18:25:15 <m-relay> <a​rticmine:monero.social> I propose the only approved license is the current Monero license
18:25:51 <m-relay> <s​gp_:monero.social> I see that as the only option that makes sense
18:26:20 <m-relay> <s​gp_:monero.social> you're paying for it, you get to pick the license, so pick the same one
18:26:31 <m-relay> <s​yntheticbird:monero.social> I'm against and i've no argument to explain it therefore i'm all for it
18:26:38 <m-relay> <s​yntheticbird:monero.social> checkmates myself
18:27:43 <plowsof> BSD-3 
18:33:03 <m-relay> <r​ucknium:monero.social> I will draft a public-facing post about the OSPEAD results. (Just because I write a draft doesn't mean it has to go on getmonero.org). In the meantime, feel free to continue giving feedback about interpretations and especially the FAQ: https://github.com/Rucknium/OSPEAD?tab=readme-ov-file#frequently-asked-questions-faqs
18:33:52 <m-relay> <r​ucknium:monero.social> We can end the meeting here. Thanks everyone!
18:34:09 <m-relay> <a​rticmine:monero.social> Thanks
18:34:10 <m-relay> <s​yntheticbird:monero.social> thx Rucknium
18:34:12 <m-relay> <s​yntheticbird:monero.social> thx everyone
18:34:14 <m-relay> <s​yntheticbird:monero.social> thx myself
18:35:39 <m-relay> <j​effro256:monero.social> Thanks everyone !
18:39:28 <m-relay> <c​haser:monero.social> thank you Rucknium! and thank you all.
19:00:55 <m-relay> <k​ayabanerve:matrix.org> ArticMine: A LGPL lib does not propagate to Monero. It only requires the copy-left terms be applied to derivatives of the lib itself.
19:01:45 <m-relay> <k​ayabanerve:matrix.org> Only approving Monero's BSD-3 is silly as we have non-BSD-3 libs *and* the existing libs are MIT. Anyone who forks them so their submission is an improvement can't unilaterally relicense to BSD-3.
19:02:10 <m-relay> <k​ayabanerve:matrix.org> It'd force complete rewrites of the existing libs.
19:02:59 <m-relay> <k​ayabanerve:matrix.org> If we're already at MIT and BSD-3, why not allow public domain dedications which impose no terms at all? What's the issue with LGPL when it wouldn't propagate to Monero?
20:09:15 <m-relay> <j​berman:monero.social> The way the contest is currently set up, contestants would submit a PR that modifies the existing code *that is already licensed under MIT*
20:09:25 <m-relay> <j​berman:monero.social> I structured the contest like that to make it easier on contestants to get started coding, see the README's for ec-divisors-contest and helioselene-contest: https://github.com/j-berman/fcmp-plus-plus-optimization-competition
20:09:58 <m-relay> <j​berman:monero.social> As such, wouldn't their submissions fall under MIT by default? And I wouldn't see a problem with that. We are fine to use the code in Monero as a git submodule
20:14:29 <m-relay> <j​berman:monero.social> 3700x seems like a solid machine to run the contest on. Maybe if gingeropolous has something available in between that and the low power machines, would be optimal. But I don't see an issue going with a 3700x
20:32:31 <m-relay> <k​ayabanerve:matrix.org> They could introduce API-compatible libs under their own license or individually license files. Again, the entire poly.rs file is ripe for a rewrite.
20:32:57 <m-relay> <k​ayabanerve:matrix.org> I'm fine with kneecapping to MIT alone though.
20:38:05 <m-relay> <j​berman:monero.social> Simplest path here seems MIT to me