<3​21bob321:monero.social> deity twatted about it ?

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

<o​frnxmr:monero.social> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) as of yesterday, there was 1072xmr left in the research ccs

<o​frnxmr:monero.social> This includes the 70xmr to cypherstack. Sgp has the number at 1002 if including the 70

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

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

<a​rticmine:monero.social> Hi

Hello

<v​tnerd:monero.social> Hi

<j​berman:monero.social> *waves*

<k​ayabanerve:matrix.org> 👋

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

<r​ucknium:monero.social> me: Set up a data pipeline and visualizer webapp for the Monero node network scanner. Repo: github.com/Rucknium/xmrnetscan Webapp: moneronet.info (not to be shared on social media yet). Continuing to monitor Qubic's hashpower share. Updated plots here: gist.github.com/Rucknium/0873b10b6d36ff6c9d6f8f54107d16f7

<j​effro256:monero.social> Howdy

<b​randon:cypherstack.com> yo. i finished up the latest draft of silver bullet and sent it along to kayaba. i will be around for a bit to answer any questions which have come up. when we are done copyediting, we will be putting it up on iacr

<v​tnerd:monero.social> Me: updated jeffro256 mx255519 fork to support arm64 asm. Updated LWS API specs. Currently working on seeing if I can simplify the lws build process a bit

<v​tnerd:monero.social> * the asm now does unclamped calculations correctly

<s​yntheticbird:monero.social> Hello

<a​rticmine:monero.social> I am finalizing scaling and fees after MoneroKon

<a​rticmine:monero.social> For the most part the current fee structure can remain with FCMP++

<a​rticmine:monero.social> There are some consensus changes to the Medians and transitional changes to accomodate FCMP++

<j​berman:monero.social> me: reduced data stored per output in the curve tree, continued PR review, subaddress lookahead expansion

<r​ucknium:monero.social> 3) [SLVer Bullet: Straight Line Verification for Bulletproofs](github.com/cypherstack/silver-bullet). [Cypher Stack review of divisors for FCMP](github.com/cypherstack/divisor_deep_dive).

<r​ucknium:monero.social> Did kayabanerve complete his review of SLVer Bullet? Where do things stand?

<k​ayabanerve:matrix.org> Not quite. I'm still working on mapping it into FCMP++.

<r​ucknium:monero.social> surae/Goodell put up a thread about SLVer Bullet on BlueSky: bsky.app/profile/bggoodell.bsky.social/post/3lswc55nwhc2j

<r​ucknium:monero.social> Anything more to discuss on this item?

<r​ucknium:monero.social> 4) [FCMP++ optimization coding competition](getmonero.org/2025/04/05/fcmp++-contest.html).

<r​ucknium:monero.social> The submission period for the competition has ended. Any info to share, jberman and jeffro256 ?

<j​berman:monero.social> We received 2 helioselene submissions, 1 divisors submission

<j​berman:monero.social> Divisors submission so far looks very solid, pending further review (initial benchmark clocks in at 95%+ speed-up). We may not end up needing a blinds cache

<g​ingeropolous:monero.social> hi, i've started fiddling with shadow, got it to at least run 2 nodes :/

<s​yntheticbird:monero.social> Holy moly

<r​ucknium:monero.social> 95%? Wow. How much does this operation account for, out of the whole tx verification?

<s​yntheticbird:monero.social> Will author name be revealed ?

<j​berman:monero.social> If the author wants yes

<j​berman:monero.social> this is strictly blinds calculations on the proving side

<j​berman:monero.social> does not affect verification

Just to be clear - it's almost twice as fast as the code is now?

<r​ucknium:monero.social> Oh

<j​berman:monero.social> Like 30 times as fast

<k​ayabanerve:matrix.org> No, 30x.

<g​ingeropolous:monero.social> wow

<s​yntheticbird:monero.social> wow

Ah, I see. A bit strange to express that as "95% speed up", but yeah, wow :)

<r​ucknium:monero.social> That means alpha stressnet can get more stressy :D

<k​ayabanerve:matrix.org> Only provers benefit, so only sort of? Besides, provers could already cheat this if they wanted to.

<r​ucknium:monero.social> I mean, if tx proving took a long time, then it would be hard to send a lot of txs on the stressnet, even with the blinds cache

<k​ayabanerve:matrix.org> Unless the prover cheats, which they can.

<s​yntheticbird:monero.social> Are there good news on the verification side?

<r​ucknium:monero.social> Well, at least it avoids anyone needing to write "cheating" prover code specifically for the stressnet

<r​ucknium:monero.social> (And what is this cheating, anyway?)

<r​ucknium:monero.social> Oh, maybe make unspendable outputs?

<k​ayabanerve:matrix.org> No. The divisor is used to prove a scalar multiplication. You can take one scalar and make a proof for it. That proof is then always usable for any instance of that scalar.

<k​ayabanerve:matrix.org> Scalars shouldn't be reused, as it breaks the privacy of the scheme. If you don't care, you can reuse them however.

<j​berman:monero.social> On helioselene: we have some thoughts on the submissions. Initial speed-ups clock in in the range of 20-40% as is, but have some issues that jeffro, kayaba and I have been discussing

<j​effro256:monero.social> You can "cheat" by re-using divisors, which is bad for privacy in the real world, but allows you to create valid FCMPs really fast.

<j​berman:monero.social> I'll get more into helioselene once we're done discussing divisors here

<k​ayabanerve:matrix.org> There's also worse things you can do, but that's the trivial way to cheat.

<r​ucknium:monero.social> I see. Maybe not a good idea to push that type of "cheating" code out into the wild, then, or someone might use it. Or ChatGPT would use it 😬

<j​berman:monero.social> Ok going to continue on helioselene

<j​berman:monero.social> The primary issue with both helioselene submissions is that they replace ed25519 arithmethic, which was not intended scope of the contest and we unfortunately did not explicitly rule it out in the contest rules (I also mistakenly told one contestant it was ok to swap out dalek-ff-group in a DM when they asked i.e. could replace ed25519, and the rules did not explicitly rule it out<clipped message>

<j​berman:monero.social> ). One submission (the one I DM'd) is still over the 20% floor for validity swapping dalek's ed25519 back in. The other is trickier to swap back in and we don't know right now if it would still meet the bar

<k​ayabanerve:matrix.org> I was invited to review the above and fundamentally disagree with that position.

<k​ayabanerve:matrix.org> The libraries worked to a purpose and there was a reasonable intent the derivative libraries would work to the purpose. We explicitly included an arbitrary disqualification rule for any libraries which met the rules yet didn't meet the purpose.

<k​ayabanerve:matrix.org> Both Helioselene submissions replaced the 2**255-19 field definition used, and in doing so, broke interoperability with the Ed25519 curve library used (where the Helioselene library implements a curve cycle whose entire purpose was interoperability with the Ed25519 curve).

So they work on their own alone, but not within the proposed framework?

<k​ayabanerve:matrix.org> While it wasn't explicitly tested, and accordingly wasn't covered under the requirement tests pass, deleting functionality from the codebase is not a legitimate way to claim a faster codebase.

<k​ayabanerve:matrix.org> There is the complexity in that jberman personally gave a clarification to a contestant claiming this would be legal, when I would say it absolutely shouldn't be.

<k​ayabanerve:matrix.org> They will fundamentally not compile in the FCMP++ codebase and would require changes to the larger codebase.

And they are not that radically faster to make that look worthwhile

<k​ayabanerve:matrix.org> With one submission, I was able to revert back to the existing definition without notable complexity. It still met the 20% minimum improvement criteria. It also included variable-time arithmetic and is accordingly invalid under that rule.

<k​ayabanerve:matrix.org> With the other submission, I was unable to trivially revert back to the existing definition of Ed25519 due to how the library at large had been reworked. I accordingly cannot comment if it'd still meet the 20% criteria.

<r​ucknium:monero.social> kayabanerve: Their original submission had variable-time arithmetic, not your edit?

<k​ayabanerve:matrix.org> With those pain points aside, I'll note I'm personally disappointed neither submission implemented the Crandall-prime reduction which was a specific property tevador chose the field bespoke to Helios/Selene to have.

<k​ayabanerve:matrix.org> Rucknium: Both libraries replaced the definitions of the representations of the mathematical finite fields. One did so with a bespoke implementation (a rather simple 256-bit representation, optimizing for how the 256th bit is unused as our fields only require 255 bits), and one did so with a distinct off-the-shelf integer representation.

<k​ayabanerve:matrix.org> The bespoke implementation is the one which executes in variable time, and the one I was able to revert as required for potential usage in FCMP++.

<r​ucknium:monero.social> And having variable-time disqualifies a submission, right?

<k​ayabanerve:matrix.org> The one which used a distinct 'off-the-shelf' (it was forked and optimized to some degree my review has yet to cover, apologies for any handwaving there which is dismissive of work) implementation was the one I couldn't make legal for re-benchmarking and I'm unsure if it'd still meet the required performance metric after (as this may halve its performance gains, and it did not gai<clipped message

<k​ayabanerve:matrix.org> n twice the required minimum).

<k​ayabanerve:matrix.org> Correct, and that was an explicit rule.

<k​ayabanerve:matrix.org> So to be a pedantic asshole, even with the exception granted, both of these submissions could be immediately disqualified leaving literally no one happy. While we could reconcile the good parts of the submissions, we'd still need the Crandall-prime reduction and associated bespoke finite field implementation to be optimal.

<j​effro256:monero.social> Yes, technically it is explicitly illegal for the code to be variable time dependent on secret data. Although it can be argued whether or not a submission should be outright denied for variable timeness and the other aforementioned issues if there are other valid parts of the code that are usuable, and fixing those problems would result in the fastest now valid submission.

<k​ayabanerve:matrix.org> Which leads us to jberman's suggestion.

<j​berman:monero.social> Moving forward: I suggested we give both contestants 2 additional weeks to fix our major issues with their submissions, and allow them both the opportunity to improve their submissions (i.e. they can use a Crandall prime reduction, which is long term what we would hope to integrate into the helioselene lib)

Sounds pretty fair

<k​ayabanerve:matrix.org> Sorry, clarifying:

<k​ayabanerve:matrix.org> - The bespoke implementation present used `u128`, a Rust-language primitive which defers to the LLVM IR for 128-bit arithmetic. The LLVM IR is observed to generate variable time assembly for its 128-bit arithmetic on nontrivial platforms (and maybe also trivial platforms. Quick, who has an Amiga and a weekend to kill?)

<k​ayabanerve:matrix.org> - The forked 'off-the-shelf' implementation, even with the exception granted to one participant universally applied (despite how they were unaware of this exception), forked a library and provided no attribution within the file tree. Beyond the rules regarding plagiarism (to be harsh), this arguably circumvents the 'no additional dependencies' rules by not adding a dependency to t<clipped message

<k​ayabanerve:matrix.org> he dependency tree, yet inlining the 20 relevant files from the library into the Helioselene library. The library inlined WAS on the approved dependency list however, so it's a question of if a fork of a dependency counts as approved, what's a reasonable maintenance burden there, etc. Even beyond the ambiguity of 'is it a dependency* however, the lack of attribution *in file tree*<clipped message

<k​ayabanerve:matrix.org> would be sufficient to disqualify for improper citations.

<r​ucknium:monero.social> jberman and jeffro256 are named as the contest judges. That means they have final judgement, correct? What does jeffro256 think about this?

This is almost fractally complicated :)

<r​ucknium:monero.social> I see a 👍️ from jeffro256 on jberman's "Moving forward..."

<r​ucknium:monero.social> Contract incompleteness theorem strikes again

<k​ayabanerve:matrix.org> Yes, I'm solely a third-party advisor ready to be pedantic, please be aware I don't actually have a standing and now that I've played bad cop, the level-headed people may chime in.

<r​ucknium:monero.social> Or is it a theorem? Anyway.

<j​effro256:monero.social> If the contestants agree to it, I agree with the route of allowing 2 additional weeks to refine their submissions, where we explicitly lay out more explicit boundaries around desired behavior, and with the specific feedback for each submission. It will be awkward if one likes the idea, and the other doesn't...

<k​ayabanerve:matrix.org> I don't hate we didn't explicitly require the Crandall reduction. I just wouldn't host the contest again. I would host the divisors contest again though, per my current understanding.

By the way, I believe to have seen some @tritonn:matrix.org in the dev channel that wrote about running out of time. Maybe they could submit something with a 2-week extension, who knows

<j​berman:monero.social> I will add that the second contestant (who forked a library and included in their submission) did ask us how we wanted them to proceed w.r.t attribution for that lib in their PR submission and did clarify where it came from. We missed it / didn't respond to that prior to the deadline

<r​ucknium:monero.social> Whether the contestants are amenable to the extension may depend on how they would do (in XMR payments) without it.

<k​ayabanerve:matrix.org> And I can fire back that it isn't up to us: it's up to the license they code was used under.

<k​ayabanerve:matrix.org> Literally, I can't ask Microsoft how I should handle Apple source code. It's not up to them.

<j​berman:monero.social> I personally think it would be most fair to the contestants who did get their submissions in time to have the opportunity

<k​ayabanerve:matrix.org> I disagree with allowing more people in.

Understandable. It's complicated enough as it is

<j​effro256:monero.social> rbrunner7: I had this same thought, but I lean towards agreeing with @jberman on this one: it wouldn't be fair to the people who submitted in time. Especially since new participants now know where the benchmarks for the "leading" submission stands, whereas before they didn't know that information.

Makes sense

While I have no say in the matter, if no entry is valid, an extension of the contest is a totally fair outcome. Preventing other entries would be unfair. It would only be fair if at least one of the original submissions was valid.

<k​ayabanerve:matrix.org> It's due to mixed legality of existing entries and of how there should've been a tighter loop for clarifications/submissions/responses to ensure legality, IMO.

(assuming the code for each entry is not public yet)

<k​ayabanerve:matrix.org> Pedantically, none are legal IMO. Reasonably, one of these can be made legal in potentially a few hours.

<j​effro256:monero.social> Yes, the Helios-Selene entries will remain private until further notice. The ec-divisors submission may be made public as soon as we get explicit confirmation from the author

If those two solutions, if possible to get rectified, hoover only around 20% improvement, that's still not very exciting. Is there hope for that "Crandall reduction" to make things substantially faster still?

<r​ucknium:monero.social> And is the Crandall reduction modular, or would major parts of the submissions have to be re-written to include it?

<k​ayabanerve:matrix.org> Yes rbrunner, and the two of them can still fight it out even if we disallow a third competitor, but if the argument is for a third competitor, so it is.

<k​ayabanerve:matrix.org> Rucknium: It's related to how the underlying numeric data is represented, so while it's an algorithm and algorithms are implemented in code and rewritten and ported, it's not pleasant.

<k​ayabanerve:matrix.org> But it's not an entire ZK proof, or blockchain. It's an algorithm to take 8 words on a 64-bit computer and reduce it to 4 words.

<j​berman:monero.social> Another important element to consider here: it seems we may not spend any time integrating these solutions into the lib because the speed-up is not so drastic. With a bit of work, they can be what we would consider technically/pedantically valid submissions that also meet the 20% bar, but without a Crandall prime reduction, and with the relatively minor speed-up they realized, we <clipped message>

<j​berman:monero.social> may not actually integrate them

True, but IMHO in the light of the contest that would be no real problem: Technically valid and best -> payout. Not useful for us, bad luck

<j​berman:monero.social> Yea agree

<j​effro256:monero.social> For better or worse, agreed.

<k​ayabanerve:matrix.org> I prior said I'd consider this unfortunate and not worth repeating, but would move to accept a patched version of either library so long as they still clear the minimum performance bar.

<k​ayabanerve:matrix.org> Except the divisors library seems to have done great, so it's less 'are contests worthwhile' and more 'why did one fail where one succeeded'

<r​ucknium:monero.social> Low sample size. Hard to draw a conclusion :P

<k​ayabanerve:matrix.org> We could take a survey. Surveys shows 97% of participants like taking surveys.

<j​berman:monero.social> Ok, I still lean in favor of keeping it to the contestants because it's a small amount of work for them to "fix" their submissions relative to the work they've already done

<r​ucknium:monero.social> Exactly. We don't know who looked at the contest and decided not to compete

<r​ucknium:monero.social> IMHO, the decision belongs to jberman and jeffro256, including the timeline to make a decision. I think people can continue to give thoughts to them.

<k​ayabanerve:matrix.org> Which is why they should only have two days, not two weeks, and even that should be considered generous. In fact, I say we require them eight hours from the end of this meeting, one work day. If the edits aren't done then, then the edits weren't so trivial as to justify this extension.

<k​ayabanerve:matrix.org> /s, but I do feel two weeks is VERY generous compared to the amount of time expected for a presumed review + reconcile cycle.

<s​gp_:monero.social> Two weeks for the two submitters seems the most reasonable to me. They may not love it but they'll like that more than being rejected

<s​gp_:monero.social> And this is definitely a lesson in scoping imo. It's especially challenging for open contests because people may be incentived to win on a technicality. The incentive isn't to make the most useful submission, it's to win the game

Nicely put

<r​ucknium:monero.social> The contest designers were smart to include the clause "You cannot win on a technicality", which they basically did

<j​berman:monero.social> I did include this clause for this reason fwiw:

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

Giving those people more time but not others *is* unfair. Giving tiny amounts of time based on one's opinion of how much time is needed for those particular submissions is biased towards those submissions. Agree with the scoping fail point though.

<k​ayabanerve:matrix.org> I feel the 20% rule largely helped with this, yet was surprisingly too low a bar given the unfortunately small sample size.

<s​gp_:monero.social> People who didn't submit anything aren't entitled to anything ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

<k​ayabanerve:matrix.org> Issues such as *not being interoperable with our Ed25519 lib when the entire point is Ed25519 interoperability*?

<s​gp_:monero.social> Right, that's a fundamental issue

False. They're entitled to the same rules as others.

Rules that aren't made to fit those invalid submissions.

<j​effro256:monero.social> Maybe we could look to other contests as how they handled similar situations?

<a​ntilt:we2.ee> deadline is often adjusted equally for all

<j​berman:monero.social> One (arguably worse) submission I personally wouldn't argue is invalid because of the licensing question (it's an open question if they would still meet the bar swapping dalek ed25519 back in). I think the other submission (that uses u128 arithmetic which as kayaba noted isn't constant time on all arches but can be fixed) appears superior at this point in time

<j​berman:monero.social> > It would only be fair if at least one of the original submissions was valid.

<j​berman:monero.social> One of the submissions I think has a reasonable claim at validity, but appears to be the worse submission, and going by this clause in the contest:

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

<j​berman:monero.social> Gives us the right to rule it out for its inferiority

<k​ayabanerve:matrix.org> Except they can't trivially swap ed25519 back in due to the extensive edits made.

<r​ucknium:monero.social> You could decide that no extension will be given, and the contest ended with no acceptable submission.

<k​ayabanerve:matrix.org> ^

<j​berman:monero.social> Right that's another option. I think it's arguable that is a more fair outcome than opening the contest back up to everyone

<r​ucknium:monero.social> 2-3 months of time was given, and this is all that the contest got

Closing with no winner can allow another contest, which is equivalent to a large extension for all (and allows for narrower scope).

For the joy of complicating things even more: We could close this and make a new contest :)

And existing entrants still have their code as a leg up.

<k​ayabanerve:matrix.org> One submission illegally (US copyright law) included code, even if they asked us how to legally include it (when it's not our decision), and illegally (against the intended contest scope) replaced the Ed25519 field definition.

<k​ayabanerve:matrix.org> One submission is variable time and replaced the Ed25519 field definition, but they were told that latter was okay.

Yes, I think the position to refuse to accept both is maybe not "nice", but defensible

Were they told using another lib was fine, or not using ed25519 was fine ? ie, was "another lib" (mis)understood as "another ed25519 lib" ?

<k​ayabanerve:matrix.org> At this point, due to the trend of the debate, I'd say extend acceptance for two weeks to everyone, explicitly allow messaging jberman/jeffro256 for clarifications on rules, and one of them cannot unilaterally issue new clarifications. They need to talk it out with each other future.

<k​ayabanerve:matrix.org> But it's not my contest :p

<k​ayabanerve:matrix.org> it's either theirs, or it's the CCS's who holds the $$$

<r​ucknium:monero.social> IMHO, rules clarification should happen in a public channel, e.g. #monero-dev:libera.chat

<r​ucknium:monero.social> IIRC, the payment, if any, would come out of Core's general fund

<a​ntilt:we2.ee> you may extend the d/l without giving reasons at all...

<a​ntilt:we2.ee> we'r not in a hurry, are we

<r​ucknium:monero.social> Or even as an edit to the rules in the GitHub repo

<j​berman:monero.social> <m​oneromooo> Were they told using another lib was fine, or not using ed25519 was fine ? ie, was "another lib" (mis)understood as "another ed25519 lib" ?

<j​berman:monero.social> They were told another lib was fine (they're still using ed25519, just using their own impl). Worth noting still, that submission is still over 20% when using the expected ed25519 lib

<k​ayabanerve:matrix.org> We can require all rules clarifications be done via GH issues?

<b​asses:matrix.org> their own implementation of ed25519? Does't that require another audit?

<j​berman:monero.social> It can be done directly in the github readme

<r​ucknium:monero.social> jberman: , jeffro256 : What do you want to do with this discussion? Do you have enough input to make a decision?

<j​berman:monero.social> I'm not ready to make a decision yet but happy to hear further thoughts / continue the discussion after the meeting. I appreciate the points moneromoo and flip flop raised

<r​ucknium:monero.social> 5) [Spy nodes](monero-project/research-lab #126).

<r​ucknium:monero.social> I made this webapp: moneronet.info Like I said, not yet ready to share widely on social media, please

<r​ucknium:monero.social> I think it has already given some actionable info: About 50% of honest reachable nodes have the DNS ban list enabled.

<a​ntilt:we2.ee> 50% ?!

<r​ucknium:monero.social> That means that it _would_ be worth it to update the DNS ban list to, at least, include all the big spy nodes subnets. The DNS banlist is "full", so a few singleton IPs would have to be dropped

<r​ucknium:monero.social> That's according to my analysis. You can infer that a node has a ban list enabled if they share zero nodes on the ban list in their handshake. They share 250 IP addresses, selected from their white_list

It would be fairly trivial to bypass the "full" issue by checking other records. Besides, IP addresses can be represented by integers (ie, raw, not split into bytes).

<r​ucknium:monero.social> It may be because SethForPrivacy recommended the DNS ban list flag

<r​ucknium:monero.social> sethforprivacy.com/guides/run-a-monero-node

<r​ucknium:monero.social> sethforprivacy.com/guides/run-a-monero-node-advanced

<a​ntilt:we2.ee> sry - confused with --ban-list

<r​ucknium:monero.social> moneromooo: I agree with that, but it would require an update to the `monerod` code, right?

Yes. I did not realize that was an obstable.

<r​ucknium:monero.social> flip flop: Right. The MRL ban list has about 6% adoption.

<r​ucknium:monero.social> AFAIK, nodes that check the DNS ban list will pull in the new list once per week, if they do not restart.

<r​ucknium:monero.social> About 35% of honest reachable nodes are pruned. And 30% of honest reachable nodes say they have RPC available (But I did not check if they actually have that port open, yet).

That's already a considerable part of nodes pruned ...

<r​ucknium:monero.social> The webapp also has an interactive treemap of spy/honest nodes and their subnets, like the static treemap in the draft MRL research bulletin. You can click on the boxes to get more info about each node. I don't think it's mobile-friendly, however.

<r​ucknium:monero.social> I'm thinking about computing the Herfindahl-Hirschmann Index of the honest nodes, by subnet and Autonomous System Number (ASN) to measure node "concentration" through time.

<r​ucknium:monero.social> The RPC numbers are of interest because they are nodes theoretically susceptible to any RPC vulnerabilities. The Magic Monero Fund has contracted a firm to create an RPC fuzzing harness to anticipate those vulnerabilities.

<r​ucknium:monero.social> Any feedback on the webapp is welcome :)

<r​ucknium:monero.social> Anything more on spy nodes?

<r​ucknium:monero.social> 6) CCS proposal: [Monero Network Simulation Tool](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589).

<r​ucknium:monero.social> Earlier, gingeropolous said "hi, i've started fiddling with shadow, got it to at least run 2 nodes :/"

<j​berman:monero.social> (ready to circle back to contest discussion next)

<r​ucknium:monero.social> 7) Peer Scoring Metrics.

<r​ucknium:monero.social> Anything on peer scoring metrics?

<a​ntilt:we2.ee> would need a serious investment in time and also systems theory.

<a​ntilt:we2.ee> nothing new. Exept: if a connection handshake for an anchor_node fails for whatever reason, its first_seen value is reset (its thrown out of the anchor_list).

<a​ntilt:we2.ee> I'd keep it around for say three cx fails. But thats not how apl is designed currently. Just a theoretical thought for now.

<r​ucknium:monero.social> Ok we can have the official end of the meeting here. And feel free to continue discussing topics, especially the coding competition. Thanks everyone.

<j​berman:monero.social> On the contest:

<j​berman:monero.social> New proposal: 1 week extension open to all, starting tomorrow. This gives the contestants a reasonably significant leg up compared to the field

<j​berman:monero.social> And is the 1 week expectation kayaba initially stated

<j​effro256:monero.social> I agree

<j​berman:monero.social> Pinging kayabanerve @moneromooo Rucknium sgp_ flip flop for potentially dissenting thoughts?

<r​ucknium:monero.social> How would you intend to give notice of the deadline extension?

<j​berman:monero.social> First, update the github repository. DM contestants. I can write a blog post expanding on it. And we can request monero twitter account broadcast it

<r​ucknium:monero.social> Maybe, the people who had private forked repos, but did not submit, could be notified by some GitHub magic.

<r​ucknium:monero.social> A blog post on getmonero.org may take a while to get deployed, FWIW

<j​berman:monero.social> Sure, maybe no blog post then

<r​ucknium:monero.social> Sounds OK to me. I like this passage from the `Complete contract` entry in Wikipedia:

<r​ucknium:monero.social> > A complete contract is an important concept from contract theory. If the parties to an agreement could specify their respective rights and duties for every possible future state of the world, their contract would be complete. There would be no gaps in the terms of the contract.

<r​ucknium:monero.social> > However, because it would be prohibitively expensive to write a complete contract, contracts in the real world are usually incomplete. When a dispute arises and the case falls into a gap in the contract, either the parties must engage in bargaining or the courts must step in and fill in the gap.

<r​ucknium:monero.social> So, this is normal and a judgement must be made

<3​21bob321:monero.social> Mrl needs social media presence

<j​berman:monero.social> Btw, the divisors contestant has made their submission public :) fabrizio-m/fcmp-competition #1

Was that monumental speedup very surprising? Did you nearly "fall from your chair" when you saw what they did?

<j​berman:monero.social> Yes :) Appears to be using a mathematical method I hadn't heard of before and "deserves to be known as the standard method of polynomial interpolation": people.maths.ox.ac.uk/trefethen/barycentric.pdf