<r​ucknium:monero.social> MRL meeting in this room in two hours

<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: monero-project/meta #1162#issuecomment-2685563055

<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)

<r​ucknium:monero.social> I wrote a FAQ for the OSPEAD repo: github.com/Rucknium/OSPEAD/tree/mai…ile#frequently-asked-questions-faqs

<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

<r​ucknium:monero.social> Meeting time! monero-project/meta #1162

<r​ucknium:monero.social> 1) Greetings

<s​yntheticbird:monero.social> Hello there

<a​rticmine:monero.social> Hello

Hello

<c​haser:monero.social> hello

<j​effro256:monero.social> Howdy

<b​oog900:monero.social> hi

<v​tnerd:monero.social> hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<r​ucknium:monero.social> me: Prepared and posted the OSPEAD Hackerone and CCS Milestone 1-2 documents and code: github.com/Rucknium/OSPEAD . Worked on game theory of subnet deduplication as a spy node countermeasure.

<s​gp_:monero.social> Hello

<v​tnerd:monero.social> updated socks5 review, and trying to figure out the bug reports from my recently merged PRs

<j​effro256:monero.social> Responding to reviews for #9135, trying to reproduce bugs on release branch, and improving FCMP++/Carrot transaction construction code.

<r​ucknium:monero.social> 3) Prize contest to optimize some FCMP cryptography code. github.com/j-berman/fcmp-plus-plus-optimization-competition

<r​ucknium:monero.social> jberman had to miss this meeting, but said in his comment ( monero-project/meta #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"

<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?

<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.

<c​haser:monero.social> can't they still use their own choice of license?

<r​ucknium:monero.social> Yes, but it would be dual-licensed in that case

<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)

<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)

<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

<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

<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

<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.

<v​tnerd:monero.social> jeffro256: weve had 1-2 people try to hold code hostage in the past, under fear of non-payment

<r​ucknium:monero.social> jeffro256: Because that action would be a violation of open source licensing rules

Sounds somehow like an "unsolvable" problem to, not possible to do "trustless". We and the contestant may *have* to trust each other

*problem to me

<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.

They have to trust us to pay also?

Ah, you mean pay first, license afterwards

"if they don't trust us to blatantly use/license their code correctly, " -- agreed

ignore that

"why would they ever believe that we would pay them in the first place?" -- agreed

if trust is an issue, they won't participate in the first place

<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.

<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.

<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

<r​ucknium:monero.social> Reminder: sagewilder is a likely contestant FWIW.

"Pay first, delivery afterwards" does make some sense.

<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

They trust us to pay, we trust them to license after payments. It's mutual.

<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"

Clever

rbrunner: that requires 2 trust instances. if the license is present upon submission, only 1 trust instance is required

<r​ucknium:monero.social> A semi-smart contract :)

You invented a new license

<a​rticmine:monero.social> We need to specify our license as it is now as a condition of participation in the contest

NorrinRadd: Yes. As a power shift away from the contestant, towards the Monero project

yes clever Re: Jeffro256

<s​agewilder:unredacted.org> This text and its formulation are satisfactory to me.

<a​rticmine:monero.social> The last thing we need is new "creative" licences

Surely we would re-license afterwards? Or would that be problematic?

<a​rticmine:monero.social> So the current Monero license is a condition of participation

<a​rticmine:monero.social> We cannot relicense afterwards.

<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.

<s​yntheticbird:monero.social> what? we can't relicense BSD ?

<a​rticmine:monero.social> We can relicense the current BSD but not the other way

<a​rticmine:monero.social> For example turn GPL v3 into BSD

<s​yntheticbird:monero.social> the joy of GPL

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

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.

<a​rticmine:monero.social> There are many arguments in favor and against for example regarding a strong copyleft such as GPL v 3.

<s​yntheticbird:monero.social> imo it should be MIT

<s​yntheticbird:monero.social> just for the ease of mind of the ecosystem

<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

<a​rticmine:monero.social> This competition is not the place to discuss changing the Monero license

<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

<s​yntheticbird:monero.social> oh maybe i misunderstood, i thought you were discussing the license of the submission

<r​ucknium:monero.social> jeffro256: Yes, that is what I am saying.

they are welcome to not participate

<j​effro256:monero.social> It wouldn't be changing the license of all of the Monero, just that submission

<a​rticmine:monero.social> If they are chosen they agree to the current Monero license.

if conditional are allowed in legal agreements I believe. it's just a license with an if condition. It's not a license change.

<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

<a​rticmine:monero.social> As long as the licenses are compatible

<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.

<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.

<a​rticmine:monero.social> Typically it is one way compatibility. Mixing GPL and BSD for example leads to GPL the whole code

<r​ucknium:monero.social> On which hardware to perform the benchmarks, the MRL computing cluster has some powerful machines:

<s​yntheticbird:monero.social> New achievement unlocked: KayabaNerve, the lawyer 🖊️

<r​ucknium:monero.social> 3700x

<r​ucknium:monero.social> 3900x

<r​ucknium:monero.social> 5900x

<r​ucknium:monero.social> 64 thread AMD Ryzen Threadripper 3970x

<r​ucknium:monero.social> 256 thread 2x 7h12 server

<r​ucknium:monero.social> Epyc server

<r​ucknium:monero.social> And some low-power machines:

<r​ucknium:monero.social> AMD C-50 Processor

<r​ucknium:monero.social> Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz

<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)?

<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

<a​rticmine:monero.social> The latter has to be BSD.

<b​oog900:monero.social> that was jeffro's idea AFAIK

<s​yntheticbird:monero.social> jeffro should license his idea in the chat next time

<s​yntheticbird:monero.social> wrong reply

<a​rticmine:monero.social> The submission license should be GPL v3 compatible

<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

<j​effro256:monero.social> *for what we

<j​effro256:monero.social> new *consumer-grade* hardware

<j​effro256:monero.social> So probably not AMD EPYCs

Good idea. A server machine may have large first-level caches that make things fast, which might not happen on a "normal" machine

<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?

<s​yntheticbird:monero.social> 3700X is mid range imo

<r​ucknium:monero.social> 4) Release of OSPEAD HackerOne and CCS milestone submissions. github.com/Rucknium/OSPEAD

<r​ucknium:monero.social> Comments or questions on this ^?

<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.

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

<r​ucknium:monero.social> It's possible, but a little difficult because it affects different threat models differently.

On Reddit

<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

<r​ucknium:monero.social> I hope my horse race betting metaphor helps people understand. AFAIK, Monero users are gamblers anyway 😉

Horse race betting? I have probably overlooked that.

<c​haser:monero.social> true, it's difficult to put the outcomes into exact pigeonholes. however, we can distinguish (as you already have).

<r​ucknium:monero.social> rbrunner: In the FAQ: github.com/Rucknium/OSPEAD?tab=read…ile#frequently-asked-questions-faqs

<r​ucknium:monero.social> "Q: Does the MAP Decoder attack work by eliminating decoys?"

<c​haser:monero.social> if we are proper, it should go to the official blog.

Thanks!

Yeah, nothing against a getmonero.org blog post. With pointer to it on Reddit, monero.town and maybe elsewhere

<r​ucknium:monero.social> IMHO, it may be a good idea for someone besides myself to reproduce the results from the small validation simulation: rucknium.github.io/OSPEAD/CCS-miles…html#sec-successful-simulation-code

<c​haser:monero.social> rbrunner: sounds great

<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.

<c​haser:monero.social> inb4 OSPEAD optimization contest

<r​ucknium:monero.social> The reproducer would have to install the right packages first:

<r​ucknium:monero.social> rucknium.github.io/OSPEAD/CCS-miles…OSPEAD-docs/_book/requirements.html

<r​ucknium:monero.social> github.com/Rucknium/OSPEAD?tab=read…talling-the-decoyanalysis-r-package

<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

<c​haser:monero.social> you mean people volunteering? or an actual contest? I didn't know that!

<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):

<r​ucknium:monero.social> github.com/Rucknium/OSPEAD/blob/mai…e-2/decoyanalysis/R/bjr.R#L534-L587

<r​ucknium:monero.social> github.com/Rucknium/OSPEAD/blob/mai…e-2/decoyanalysis/R/bjr.R#L719-L894

chaser Rucknium is this one of the two proposals? repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/375

<r​ucknium:monero.social> First, isthmus was going to task one of his employees with re-implementing major parts in C++

<r​ucknium:monero.social> Yes, that one plowsof. Thanks

mj xmr the other for MAGIC?

<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)

MAGICGrants/Monero-Fund #21

<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

<j​effro256:monero.social> The beta distribution recommended was interesting

<r​ucknium:monero.social> jeffro256: Except for (A), those are plotted here in Figure 3.1: rucknium.github.io/OSPEAD/CCS-miles…decoy-distributions-top-1-3-not-log

<r​ucknium:monero.social> I meant 13.1

<r​ucknium:monero.social> Vertical log scale here in Figure 13.3: rucknium.github.io/OSPEAD/CCS-miles…fig-decoy-distributions-top-1-3-log

<r​ucknium:monero.social> I'll work on getting (A) in the same plot with the others

<j​effro256:monero.social> Are the output ages since creation or since spendability

<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

<r​ucknium:monero.social> cess probability).

<r​ucknium:monero.social> Table 13.1 has the comparison of the fitted proposed decoy distributions: rucknium.github.io/OSPEAD/CCS-miles…uation.html#tbl-main-attack-success

<r​ucknium:monero.social> Spendability.

<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

<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.

<k​ayabanerve:matrix.org> Rule #1 requires an approved license Rucknium

<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.

<r​ucknium:monero.social> So, the license had to be applied before submission, under the draft rules?

<a​rticmine:monero.social> I oppose LGPLs. We should not be changing the license of the Monero project by this competition

<a​rticmine:monero.social> I propose the only approved license is the current Monero license

<s​gp_:monero.social> I see that as the only option that makes sense

<s​gp_:monero.social> you're paying for it, you get to pick the license, so pick the same one

<s​yntheticbird:monero.social> I'm against and i've no argument to explain it therefore i'm all for it

<s​yntheticbird:monero.social> checkmates myself

BSD-3

<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: github.com/Rucknium/OSPEAD?tab=read…ile#frequently-asked-questions-faqs

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone!

<a​rticmine:monero.social> Thanks

<s​yntheticbird:monero.social> thx Rucknium

<s​yntheticbird:monero.social> thx everyone

<s​yntheticbird:monero.social> thx myself

<j​effro256:monero.social> Thanks everyone !

<c​haser:monero.social> thank you Rucknium! and thank you all.

<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.

<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.

<k​ayabanerve:matrix.org> It'd force complete rewrites of the existing libs.

<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?

<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*

<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: github.com/j-berman/fcmp-plus-plus-optimization-competition

<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

<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

<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.

<k​ayabanerve:matrix.org> I'm fine with kneecapping to MIT alone though.

<j​berman:monero.social> Simplest path here seems MIT to me