<d​imalinux:monero.social> Can anyone confirm what @xmrack wrote?

<d​imalinux:monero.social> I don't see an update on the official webpage (github.com/j-berman/fcmp-plus-plus-optimization-competition).

<d​imalinux:monero.social> I submitted my Helioselene entry 5 days early. Berman answered a question that I put into the PR. No feedback or requests for changes were given in the PR or here in Matrix chat. I'm happy make any changes needed or required even if they are outside the scope of the contest, but I'd need to know what was invalid if that's truely the case. I'd like to make the repo public, but sinc<clipped message>

<d​imalinux:monero.social> e there is a chance that the competition is ongoing, here's a Gist with the benchmarks that I was getting:

<d​imalinux:monero.social> gist.github.com/dimalinux/fef1a6f70df3f6924e22c45f50b1cc3b

<3​21bob321:monero.social> Are you in monero research lab ?

<3​21bob321:monero.social> Was posted there

<d​imalinux:monero.social> I'll join it (thanks!). If you read the README for the competition, this is the official channel.

woopsidaisy

<d​imalinux:monero.social> Wow. After spending many, many man hours on the Helioselene contest, the last thing I expected as the result was to be accused off plagiarism and writing code that breaks US Copyright law (see the research channel). I know kayabanerve can be passionate and I'm very grateful for all the work he does, so I'm not going to hold it against him. That said, to counter these accusations,<clipped message>

<d​imalinux:monero.social> I'm opening the repository permissions for my submission:

<d​imalinux:monero.social> dimalinux/fcmp-plus-plus-optimization-competition #1

<d​imalinux:monero.social> All my code is in the branch called `contest`. I submitted my entry 5 days early and explicitly asked in the PR on how to do attribution for the `crypto-bigint` code. If I had received a request, I would have already made it. The contest is using the MIT license, just as the `crypto-bigint` library, and the `cypto-bigint` library was already doing the vast majority of the liftin<clipped message>

<d​imalinux:monero.social> g in the competition's reference code.

<d​imalinux:monero.social> The rules for the contest stated:

<d​imalinux:monero.social> > helioselene uses crypto-bigint for its arithmetic. Replacing its field arithmetic with a tailored implementation will likely provide significant savings.

<d​imalinux:monero.social> I stripped the library down to the nuts and bolts and created a tailored U256 implementation with const modular arithmetic.

<d​imalinux:monero.social> Here is what the reference code was using (and the code base that I started with):

<d​imalinux:monero.social> github.com/RustCrypto/crypto-bigint…ustCrypto/crypto-bigint/tree/v0.5.5

<d​imalinux:monero.social> The code in question that started from the `cypto-bigint` (but doesn't have a ton in common with it now) is all under this folder (no where else):

<d​imalinux:monero.social> github.com/dimalinux/fcmp-plus-plus…st/helioselene-contest-src/src/u256

From what I read in the research-lab channel, the main problem with this is that it's a dependency inlined in the source tree of this solution, which adds a burden of maintaining it (who will pull and integrate all the fixes and changes from the parent lib?). Also, there is not comments in files with attributions and/or reference of where the files

were taken from. No matter if it's a MIT license (free for any use), authors of that code should be mentioned in the top comment in each file ("copyright" comment). And their original LICENSE file should also be there. Another problem with this solution was that it wasn't fast enough if the original crypto-bigint lib was used.

<d​imalinux:monero.social> @sech1 The `crypto-bigint` is a ginormous monster. Look at how much code is in that `u256` module:

<d​imalinux:monero.social> ```

<d​imalinux:monero.social> helioselene-contest-src$ wc -l $(find src/u256 -name '*.rs') | tail -1

<d​imalinux:monero.social> 1659 total

<d​imalinux:monero.social> ```

<d​imalinux:monero.social> @sech1 The `crypto-bigint` library is a ginormous monster. Look at how much code is in that `u256` module:

<d​imalinux:monero.social> ```

<d​imalinux:monero.social> helioselene-contest-src$ wc -l $(find src/u256 -name '*.rs') | tail -1

<d​imalinux:monero.social> 1659 total

<d​imalinux:monero.social> ```

1659 line is a monster? That's a small library, if you ask me. You haven't seen BIG libraries yet.

<d​imalinux:monero.social> Also note that I didn't strip any copyrights from the code (that project only does its license at the top of the repo), and I nicely asked how to best add attribution here on June 25th:

<d​imalinux:monero.social> dimalinux/fcmp-plus-plus-optimization-competition #1#discussion_r2167611866

Ah, 1659 files, not lines. Still not very big. grpc C++ library with all its dependencies is 13223 files, for example

<d​imalinux:monero.social> 1659 is *my* code for U256. The `crypto-bigint` library is much larger. And it's a monster in terms of readability, as it is trying to solve a much bigger problem than U256. My version eliminates a lot of templating.

Still, the best practice is to use the original library as it is much easier for maintainability. And another point about your code not being fast enough with the original library, still stands. But I'm not the judge in that competition.

<d​imalinux:monero.social> 1659 is _my_ code for U256 (that's lines, there are 20 files). The `crypto-bigint` library is much larger. And it's a monster in terms of readability, as it is trying to solve a much bigger problem than U256. My version eliminates a lot of templating.

<d​imalinux:monero.social> Optimizing the U256 code was where I spent the majority of the time and how I got the performance improvements. The contest rules explicitly suggested removing its use with a tailored solution, so that is what I ran with.

I took a quick look at github.com/RustCrypto/crypto-bigint…/tree/master/src/modular/monty_form (this library, right?), and I don't see any mess in the code. Yes, the code is complex and has this feel of long-time developed library that handles all the possible uses, but it's not a mess and not a monster code

<d​imalinux:monero.social> Optimizing the U256 code was where I spent the majority of the time and how I got the performance improvements. The contest rules explicitly suggested removing crypto-bigint's use with a tailored solution, so that is what I ran with.

Like I said, I'm not the judge in that competition. They had their reasons, probably.

<d​imalinux:monero.social> For what it is trying to accomplish, it is not a mess. It is just trying to accomplish a hell of a lot more. Note that it is big enough that you did not pick the right directory. You wanted `src/modular/const_monty_form`.

<r​brunner7:monero.social> Looks to me as if "being faster" and "using the original library" are mutually exclusive. Bring the original library in again -> there is no more contest entry, because nothing is any faster than before.

Good point. The contest was about helioselene, not bigint optimization

<r​brunner7:monero.social> (I am speaking in the context of dimalinux 's contest entry, and I tend to support their viewpoint that what they did should be permitted, given the circumstances.)

The contest rules weren't clear enough then

<r​brunner7:monero.social> Yeah, right :) Hindsight, I heard about it

<r​brunner7:monero.social> But well, if it turns out that BitInt optimizations *is* on the way to make Helioselene faster ...?

I considered taking part in the contest, but Rust stopped me. I also read that heliosene entries were expected to have some Crandall prime optimization (?) that would really speed them up. And I agree, algorithmic optimizations are always better than hand-tuning the code to get a few %

<d​imalinux:monero.social> @rbrunner7:monero.social: I just don't feel like there was any way I could have known these requirements. I'll quote the contest suggestion again as it is getting buried here:

<d​imalinux:monero.social> > helioselene uses crypto-bigint for its arithmetic. Replacing its field arithmetic with a tailored implementation will likely provide significant savings.

<d​imalinux:monero.social> My u256 module is a tailored implementation of the math for the field arithmetic. On top of that, I'm being accused of plagiarism and breaking copyright law. So I opened up the repo permissions so that everyone can see that this is plainly not the case.

And this submission didn't do it

In fact, both submissions didn't do it

<r​brunner7:monero.social> And the contest rules didn't ask for it ...

<r​brunner7:monero.social> Only perhaps hinted at it to be a good way

<d​imalinux:monero.social> Does anyone have good references for Crandall prime optimization? Especially references tailored for implementing it in code? (They were hinted at on the top page. Putting it in the helioselene specific page could have helped people a little.)

<r​brunner7:monero.social> No idea :) In a few hours some people in the know, located in the Americas, will wake up and might help. Could be a good idea to also ask in the MRL room.

I guess the answer is somewhere in this book amazon.com/Prime-Numbers-Computational-Richard-Crandall/dp/0387947779

<d​imalinux:monero.social> Anyways, I'm going to bed. By any reasonable interpretation of the contest rules, I should be awarded the prize and I will gladly modify the code until it makes everyone happy. I'm even happy to forgo the prize until J Berman and Jeffro are happy with it assuming they have time to communicate in the PR or chat about the changes to make. The cuprate group wanted lots of changes whe<clipped message>

<d​imalinux:monero.social> n I implemented the legacy cryptonight hash in Rust for them. They'll vouch for me. I made sure that everyone was happy before that code got merged. My contest entry is open now, so no one can seriously accuse me of breaking copyright law (or even not wanting to give attribution for the roots of the `u256` module).

<s​yntheticbird:monero.social> good night

<s​yntheticbird:monero.social> sweet dream

<a​illia:matrix.org> annas-archive.org/search?index=&pag…nce%2C+Prime+Numbers&display=&sort=

<k​ayabanerve:matrix.org> dimalinux: I'm sorry if I personally offended you, and I did not mean to. AFAICT, your repository currently violates crypto-bigint's license. That was my citation.

<k​ayabanerve:matrix.org> Asking in a PR how to attribute crypto-bigint does not make it attributed. Your library bring MIT-licensed does not make crypto-bigint properly licensed. crypto-bigint already being a dependency does not mean its source code can be directly copied without attribution.

<k​ayabanerve:matrix.org> My comment was on the pedantry of it, and I hope it was clear I acknowledged the contest had a flawed feedback loop IMO and that should have explicitly existed and been better handled. One of the reasons I supported an extension was to effect that feedback loop despite not originally being present.

<k​ayabanerve:matrix.org> sech1, rbrunner7: Depends on the definition of "expected".

<k​ayabanerve:matrix.org> dimalinux: "I should be awarded the prize", no, you should be eligible for the prize in your opinion. Being awarded it would require you have the best eligible submission.

<k​ayabanerve:matrix.org> I'm legitimately unsure if your entry meets the minimum performance bar once the Ed25519 code is reverted. Because of how you replaced the macro'd point for a generic (completely valid), I was unable to quickly revert that aspect and evaluate from there.

"Expected" means some algorithmic improvements, not just code tuning

like with divisors, where it got 30x speedup. Now that's the speedup!

<k​ayabanerve:matrix.org> While we could not revert the ed25519 code, it's unusable without such a reversion because not using the same type from dalek_ff_group removed functionality and broke interoperability.

Code tuning can be done slowly over time, once an optimal algorithm is implemented

<k​ayabanerve:matrix.org> sech1: I mean, the expectation was performance and the presumed was way Crandall prime. That didn't introduce an explicit expectation.

<k​ayabanerve:matrix.org> Also, friendly reminder I'm speaking as someone who proposed the contest, someone who works on the FCMP++ tree, and someone who did some review of the entries, not as a judge.

<k​ayabanerve:matrix.org> My opinion is solely an opinion.

a​illia thanks for the link btw, will be an interesting weekend read for me (irrespective of the current contest)

<d​imalinux:monero.social> I appreciate the apology. Honest question here: If crypto-bigint is dual licensed under the MIT license and the contest is under the MIT license, why would there be any licensing conflict. I think we should give attribution in wherever the code is going. I feel like maybe no one even looked at the code to see how different it is after optimizing it for the contest use case.

<k​ayabanerve:matrix.org> Because MIT requires attribution.

<d​imalinux:monero.social> I appreciate the apology. Honest question here: If crypto-bigint is dual licensed under the MIT license and the contest is under the MIT license, why would there be any licensing conflict. I think we should give attribution in wherever the code is going. I feel like maybe no one even looked at the code to see how different it is after optimizing it for the contest use case (as a side note).

<k​ayabanerve:matrix.org> MIT doesn't require you use the same license. MIT requires you follow the stated licensing terms. MIT requires attribution. The code I viewed did not attribute itself properly.

"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software"

so as long as the LICENSE and AUTHORS file are copied (and copyright comments in the source files are preserved), it should be enough

<k​ayabanerve:matrix.org> Distinctly, regarding the crypto-bigint changes: I did not have access to the commit history and did not run a diff at the time. I only cared for the end performance numbers at this time which did outperform the implementation of helioselene I initially put forth :)

<k​ayabanerve:matrix.org> Right, so there's my LICENSE file in dimalinux's tree: github.com/dimalinux/fcmp-plus-plus…2Fhelioselene-contest-src%2FLICENSE

<k​ayabanerve:matrix.org> The inclusion of the u256 mod: github.com/dimalinux/fcmp-plus-plus…ene-contest-src%2Fsrc%2Flib.rs#L194

<k​ayabanerve:matrix.org> And then its actual code: github.com/dimalinux/fcmp-plus-plus…e-contest-src%2Fsrc%2Fu256%2Fmod.rs

<k​ayabanerve:matrix.org> All without further licensing (and none in that folder).

<k​ayabanerve:matrix.org> > Copyright (c) 2021-2025 The RustCrypto Project Developers

<k​ayabanerve:matrix.org> > ...

<k​ayabanerve:matrix.org> > The above copyright notice and this permission notice

<k​ayabanerve:matrix.org> shall be included in all copies or substantial portions

<k​ayabanerve:matrix.org> of the Software.

<r​brunner7:monero.social> So just to be clear, that attribution problem is out of the way as soon as there is an attribution. It's a problem, but one that will be easy to solve. There are more issues of course, but that is thankfully simple.

<k​ayabanerve:matrix.org> I'm not saying dimalinux is malicious and didn't simply misunderstand, which was a flaw in the contest. It didn't have a proper flow to correct (relatively simple) misunderstandings, hence the extension.

<k​ayabanerve:matrix.org> I am saying that yes, currently this breaks one of the contest rules.

<k​ayabanerve:matrix.org> rbrunner7: Yes.

<r​brunner7:monero.social> Ok :)

<k​ayabanerve:matrix.org> FWIW crypto-bigint is also APACHEd (user's choice) and that also wasn't chosen, and I did immediately recognize the code.

<d​imalinux:monero.social> I was following the suggestion right in the contest:

<d​imalinux:monero.social> > helioselene uses crypto-bigint for its arithmetic. Replacing its field arithmetic with a tailored implementation will likely provide significant savings.

<d​imalinux:monero.social> Was I supposed to somehow clean room the tailored implementation even though the the 2 code bases are completely license-compatible?

<k​ayabanerve:matrix.org> No. You didn't license crypto-bigint though dimalinux

<k​ayabanerve:matrix.org> Your current usage of crypto-bigint, AFAIK, I am not a lawyer, is subject to American DMCA claims and lawsuits.

<k​ayabanerve:matrix.org> The contest has a rule to not accept code that puts the Monero project in a legally risky position.

<k​ayabanerve:matrix.org> Using it as a dependency didn't redistribute its source code. Inlining it does. I want to clarify that in case your confusion was over our existing usage of the library.

<k​ayabanerve:matrix.org> Also, again: the suggested fix from the MRL discussions isn't to replace your fork. It's just to license it.

<j​effro256:monero.social> There's also the issue of the first part of rule 2 and rule 7:

<j​effro256:monero.social> > 2. Submissions must be written by the submitter...

<j​effro256:monero.social> and

<j​effro256:monero.social> > 7. Dependencies must be pre-approved.

<j​effro256:monero.social> Is modifying and vendoring a dependency still a dependency? We could argue technicalities, but I argue that it breaks the spirit of the rules either way, and it wasn't pre-approved. The majority of the submission by line count isn't written by you AFAICT.

<j​effro256:monero.social> There's also the issue of the first part of rule 2 and rule 7:

<j​effro256:monero.social> > 2. Submissions must be written by the submitter...

<j​effro256:monero.social> and

<j​effro256:monero.social> > 3. Dependencies must be pre-approved.

<j​effro256:monero.social> > Is modifying and vendoring a dependency still a dependency? We could argue technicalities, but I argue that it breaks the spirit of the rules either way, and it wasn't pre-approved. The majority of the submission by line count isn't written by you AFAICT.

<d​imalinux:monero.social> Ok. So if I duplicate the MIT license file in the `u256` folder and add `Copyright (c) 2021-2025 The RustCrypto Project Developers` to give them attribution and we are good?

<j​effro256:monero.social> There's also the issue of the first part of rule 2 and rule 7:

<j​effro256:monero.social> > 2. Submissions must be written by the submitter...

<j​effro256:monero.social> and

<j​effro256:monero.social> > 7. Dependencies must be pre-approved.

<j​effro256:monero.social> Is modifying and vendoring a dependency still a dependency? We could argue technicalities, but I argue that it breaks the spirit of the rules either way, and it wasn't pre-approved. The majority of the submission by line count isn't written by you AFAICT.

<j​effro256:monero.social> Sorry about the edits IRC folks...

<k​ayabanerve:matrix.org> jeffro256: That was something I raised yet a discussion which wasn't actually had. I'll refrain from that beyond speculation and if this submission is optimal, given the line count, would likely call for its allowance given it's a fork of a pre-approved dependency but that's my opinion as an individual.

<k​ayabanerve:matrix.org> dimalinux: Regarding my licensing concerns? Yes. Inclusion of their license should reconcile that.

Regarding Crandall primes, I think this is what was meant by this: eprint.iacr.org/2006/121.pdf

"Also, Crandall [2] proposed a new form of primes, namely n = 2d−C, where C is a relatively small odd number, e.g. no longer than the length of a computer word (16-32 bits). When a modulus n is of this form, modular arithmetic can be accomplished using only shifts and additions, eliminating costly divisions."

Eliminating divisions will indeed bring a huge speedup

<d​imalinux:monero.social> Thanks for the clarity. I'll add it.

<a​nchoc:matrix.org> No fair use exemption for privately shared contest code when the proper attribution and source was acknowledged?

<j​effro256:monero.social> I'm not a lawyer, but I'm pretty sure fair use doesn't apply when in a contest for monetary benefits. Doesn't matter that it isnt publicly shared. Proper attribution *wasnt* given , which is the issue at hand

<a​nchoc:matrix.org> Doesn't fair use cover research and scholarship?

<a​nchoc:matrix.org> I think it not being publicly shared goes to 'the purpose and character of the use'

<d​imalinux:monero.social> I feel the need to comment here, as "wasn't" was written in bold. It was very clearly noted in the unmerged PR submitted well before the deadline:

<d​imalinux:monero.social> dimalinux/fcmp-plus-plus-optimization-competition #1#discussion_r2167611866

<d​imalinux:monero.social> As soon as my question as to how best to attribute the code was answered here in the chat today, I added the additional MIT licence to the repo. It's not the solution I would have come up with, so I am glad that I asked for clarification.

<a​nchoc:matrix.org> I think the contest submission was covered by fair use and it was wrong to say it was illegal. Would have been better to say you would be more comfortable with the copyright additions and leave it at that, instead of making legal accusations.

<a​nchoc:matrix.org> Looks resolved now so I will be quiet. Like others here IANAL.

<d​imalinux:monero.social> So everyone else knows. There are two "field" types ("U256 mod P types") used in the helioselene contest:

<d​imalinux:monero.social> * HelioseleneField (with a Crandle prime)

<d​imalinux:monero.social> * FieldElement (Ed25519 prime, I called this Field25519 in my code)

<d​imalinux:monero.social> Both of these fields are wrapping `crypto-bigint` in the reference code. It wasn't a coincidence that both entries were wrapping `crypto-bigint`. It was the reference solution.

<d​imalinux:monero.social> Under the changed rules of the contest extension, contestants *must* must use the `FieldElement` struct as-is (no trait compatibility like the original contest). So if you optimized a small subset of `crypto-bigint` to use with the curves, you can only use it with the HelioseleneField, and not with the Ed25519 field. Since I started the contest early, I was making everything with <clipped message>

<d​imalinux:monero.social> the 2 fields orthoganal to make the code logical and easier to understrand. If I were to resubmit before the extended deadline, I'd have to rip out the orthoganality, and let the Ed25519 field use the unoptimized, full-version of `crypto-bigint`.

<d​imalinux:monero.social> Here is the FieldElement struct:

<d​imalinux:monero.social> github.com/kayabaNerve/fcmp-plus-pl…pto/dalek-ff-group/src/field.rs#L40

<d​imalinux:monero.social> If you are wondering what a `Residue` is in that link, newer versions of `crypto-bigint` give it the more meaningful name `MontyForm`.

<s​yntheticbird:monero.social> lmfao

<s​yntheticbird:monero.social> (don't mind irc)

Can you guys move from #dev to some other channel. This is strictly for developer questions, not contest appeals

<s​yntheticbird:monero.social> There hasn't been any channel desginated for the contest and #monero-dev came out naturally, in part due to its low activity. #no-wallet-left-behind is hosting questions regarding several PRs.

I have notifications set for this channel, it's getting annoying

#monero-research-lounge better

<s​yntheticbird:monero.social> fair enough

<a​ntilt:we2.ee> or move to a private room @dimalinux:monero.social@jeffro256:monero.social@jberman:monero.social ?

<k​ayabanerve:matrix.org> Sorry, but this appears to be the proper channel. If someone is uninterested in this discussion on development for libraries for the Monero project, I believe that's unfortunate for them.