<k​ayabanerve:matrix.org> FWIW this is the exact discussion I've prior tried to highlight with discussions on a transaction kernel, proof, and auxiliary data for wallets. These schemes only allow replacing the proofs.

<k​ayabanerve:matrix.org> The pruned TX intent is to remove the proofs, with some degree of success.

<k​ayabanerve:matrix.org> Also, the proofs wouldn't be logarithmic to the original amount of proofs inherently. It'd depend on the scheme used. Ideally, it's constant.

<k​ayabanerve:matrix.org> Apologies, yet time slipped by and I am not posting this at least a day or two before the next MRL meeting. If that means this gets deferred to the next next meeting, I personally have no ability to object and would understand. gist.github.com/kayabaNerve/3a32eb393a41f48fe7c183c31dc57680

<k​ayabanerve:matrix.org> cc jberman jeffro250 Rucknium rbrunner7 whoever_else

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

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

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

Hello

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

<v​tnerd:monero.social> Hi

<c​haser:monero.social> hello

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

<v​tnerd:monero.social> Working on various lws-frontend stuff - finishing the lib and improving the build process

<k​ayabanerve:matrix.org> Managing audits to various degrees

<r​ucknium:monero.social> me: Have worked on more speedups to OSPEAD code. Running OSPEAD with updated data on the new 1TB RAM/256 thread MRL computing machine.

<r​ucknium:monero.social> I noticed that you can now authenticate your ORCID in your GitHub profile: github.blog/changelog/2024-03-13-authenticate-orcid-id

<r​ucknium:monero.social> info.orcid.org/orcid-and-github-sign-memorandum-of-understanding

<r​ucknium:monero.social> When I did it, this was the message for the permissions: "Allow this organization or application [GitHub] to get your 16-character ORCID iD and read information on your ORCID record you have marked as public."

<r​ucknium:monero.social> MoneroKon deadline for talks submissions is now April 14: cfp.twed.org/mk5/cfp

<r​ucknium:monero.social> 3) License for items in research-lab GitHub repo. Creative commons for non-code materials? monero-project/research-lab #123

<r​ucknium:monero.social> I merged a dependency update into the `research-lab` repo. It's the first update to the repo in about 7 years. Thanks to Siren for her review of the PR.

<r​ucknium:monero.social> One of the other pending PRs is about the license for the repo, which is BSD.

<j​berman:monero.social> me: just submitted a PR for the FCMP++ competition announcement: monero-project/monero-site #2463

<j​berman:monero.social> Implemented banning torsioned output pubkeys and commitments at consensus at the fork (after the fork, wallets won't have to do the expensive check for/clear torsion when building the tree), fixed a recently introduced issue with reorg handling in the wallet scanner tree builder, implemented a static table for FCMP++ proof size (calculating it from n inputs and n layers can be slo<clipped message>

<j​berman:monero.social> w), implemented banning n_tree_layers >12 to keep the table small and portable (the tree supports a max of ~200 quadrillion outputs at 12 layers by my math)

<j​berman:monero.social> This week I'm working on including the tree root in the block's PoW hash so clients can (eventually) verify PoW on the daemon's reported tree root, and therefore have a solid degree of confidence in the tree the client is using to construct or verify txs

<r​ucknium:monero.social> But BSD is an open source license, not a license for written research. Actually, AFAIK, the MRL research bulletins do not have explicit licenses at all.

<r​ucknium:monero.social> Would it be better to specify a Creative Commons license for MRL PDFs?

<r​ucknium:monero.social> For example, this has no explicit license: getmonero.org/resources/research-lab/pubs/MRL-0010.pdf

<r​ucknium:monero.social> BSD doesn't even explicitly cover software documentation, unlike MIT. As I understand it. The research bulletins probably cannot be considered documentation, anyway. Too much of a stretch.

<b​asses:matrix.org> yes

<j​berman:monero.social> +1 for CC

Not knowing enough about licensing to judge. I just asked myself whether you can give a license to something without one retro-actively without asking the author(s)

<j​berman:monero.social> ^that too

<r​ucknium:monero.social> Recently, I have been posting my work under CC BY-SA 4.0 creativecommons.org/licenses/by-sa/4.0

<j​berman:monero.social> (I'm not sure either)

<r​ucknium:monero.social> which is a very permissive license IMHO

<r​ucknium:monero.social> Probably, it depends if it is copyright the authors or copyright the Monero Project.

<r​ucknium:monero.social> Or both

CC BY-SA 4.0 seems to have pretty widespread use

<r​ucknium:monero.social> Or we could leave the papers that exist there as they are, and assign a CC license for materials in the future. Either way, I don't know exactly how the BSD license should be handled. Maybe put it in the directories where relevant. Where there is actual code.

<r​ucknium:monero.social> I think the "Adapt — remix, transform, and build upon the material for any purpose, even commercially" clause leans toward very permissive. Since in theory someone could take the LaTeX of a document, make a few edits, add their name, and then re-publish it. But that's a strength for work that is unfinished, or could be extended.

<r​ucknium:monero.social> Ok. I will make an issue in the repo so that it can be discussed further.

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

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

<k​ayabanerve:matrix.org> does "must distribute under" mean "must distribute under" or mean "if distributed, distributed under"? 🤔

<k​ayabanerve:matrix.org> GPL has the notable edge where distributions must be licensed but there's no obligation to distribute. People accordingly sell GPL codebases, and while the customers receive it under a GPL license, I can't demand the company provide me a copy for free.

<k​ayabanerve:matrix.org> I assume it means if distributed but would like to raise that Q on the choice of CC license

<r​ucknium:monero.social> Here is the full text: creativecommons.org/licenses/by-sa/4.0/legalcode.en

<j​berman:monero.social> "Anything more to discuss on this?" -> nothing from me

<j​berman:monero.social> I'll re-raise the blog post PR: monero-project/monero-site #2463

<r​ucknium:monero.social> "b. ShareAlike. In addition to the conditions in Section 3(a) , if You Share Adapted Material You produce, the following conditions also apply. "

<j​effro256:monero.social> Hi sorry I'm late

<k​ayabanerve:matrix.org> Thanks for clarifying, Rucknium!

<r​ucknium:monero.social> A different CC license could prevent alteration of the research materials, and only permit free distribution of them.

<r​ucknium:monero.social> 5) Cypher Stack Divisors Conclusion. gist.github.com/kayabaNerve/3a32eb393a41f48fe7c183c31dc57680

<k​ayabanerve:matrix.org> Other than what's in the gist, I don't have much to say other than I'm happy this'll be over.

<j​berman:monero.social> Strong +1 on this proposal

Just to be sure: Was it clear for a long time that this will be a part of the way somehow, or has the necessity for this become clear recently?

<r​ucknium:monero.social> This is the research product that will tell us that the divisors do not need a range proof because of the FCMP context, correct?

<k​ayabanerve:matrix.org> rbrunner: We've incrementally handled the work from Veridise and review of each step has been expected.

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

<k​ayabanerve:matrix.org> We had three documents of note from Veridise

<k​ayabanerve:matrix.org> Technique

<k​ayabanerve:matrix.org> Logarithmic derivatives + no bit constraints

<k​ayabanerve:matrix.org> Interactive proof + gadget attestation

<k​ayabanerve:matrix.org> We've had the first two reviewed and we all pretty much agree the technique holds, you can take the logarithmic derivative of it

<k​ayabanerve:matrix.org> Cypher Stack disagrees we don't need bit constraints because of ambiguity over what's occurring

<k​ayabanerve:matrix.org> The technique proves that a collection of points sum to the additive identity (analogous to 0)

<k​ayabanerve:matrix.org> You can take the logarithmic derivative of that to reduce the verification cost and that's fine

<k​ayabanerve:matrix.org> The issue is regarding selecting which points are claimed to sum to zero.

<k​ayabanerve:matrix.org> We can't claim, when proving a scaling of G, that the output point is 1G. Then everyone is using 1G for their random mask.

<k​ayabanerve:matrix.org> We instead let the prover select a set constructed from 2**i G for 0 <= i <= 255, where the prover performs this selection via specifying coefficients

<k​ayabanerve:matrix.org> That's where the bit constraints come in. Veridise says it still proves a sum regardless. Cypher Stack notes that someone who cannot prove 1 A + 1 B == 0 can forge such a proof by specifying -1 A + -1 B = 0 if that latter condition holds.

<k​ayabanerve:matrix.org> So, when we allow the prover to specify the set, it's less proving these points sum to zero and more these points generate a subgroup of the elliptic curve where the prover knows an ordered index of the point at infinity?

<k​ayabanerve:matrix.org> And that's fine for our uses. In the scalar multiplication document, this third paper from Veridise, we specifically prove a sums of points for

<k​ayabanerve:matrix.org> s_i G_i + 1 R

<k​ayabanerve:matrix.org> The prover gets control of s_i and R yet not G_1 nor 1.

<k​ayabanerve:matrix.org> *-1 R, nor -1

<k​ayabanerve:matrix.org> So yes, the prover specifies *their* point they use as a blinding factor, and yes they can malleate the index specified for that statement to sum to 0, yet they can't malleate the index w.r.t. to their output point: solely the fixed generator.

<k​ayabanerve:matrix.org> That's fine for our construction and without issue.

<r​ucknium:monero.social> And why doesn't the prover get control of those elements? Who controls them?

<r​ucknium:monero.social> Or what

<k​ayabanerve:matrix.org> But it's this question of how the bit constraints (/range proof) commentary is pretensed on this intent and context which is why I had a long discussion with CS on how to move forward, creating the resulting quote.

<k​ayabanerve:matrix.org> The ZK proof constrains G_i/-1.

<k​ayabanerve:matrix.org> It only lets the prover specify G_i and R.

<k​ayabanerve:matrix.org> So for s_i G_i + -1 R == 0, we get the rewrite s_i G_i == 1 R. Cypher Stack's note is that lhs can be malleated. We don't care.

<r​ucknium:monero.social> The ZK proof (which is maybe used for something else) constraints the elements, so a separate range proof isn't needed. Is that correct?

<k​ayabanerve:matrix.org> It's only possible when we give the prover the ability to select points (so it's no longer sums of point, which sure, this malleation would break, yet sums of multisets of points), the sum statement itself holds (albeit malleated), and the malleation still reduces to a consistent index.

<r​ucknium:monero.social> separate dedicated range proof

<k​ayabanerve:matrix.org> 1) We'd never do a separate proof. We'd do a range proof inside the FCMP

<k​ayabanerve:matrix.org> 2) We don't need a range proof

<k​ayabanerve:matrix.org> Instead of proving 1 * G + 2 * G == 3 * G, you can prove 0 - 1 * G + 4 * G == 3 * G. You can malleate the lhs.

<r​ucknium:monero.social> Who will check this logic? Or is the logic so simple that it need not be checked by review?

<k​ayabanerve:matrix.org> You still have to prove you can open the rhs over the generator we specify, for some malleable index. That malleable index, while the prover can create infinite representations, still is only openable as a single index.

<k​ayabanerve:matrix.org> It's like, I can send you "Hi" or "Hi ". I then have to tell you the English word I sent you. Regardless of how many spaces I added after, I still can only tell you I sent you "Hi"

<k​ayabanerve:matrix.org> So those are the only two properties we need.

<k​ayabanerve:matrix.org> 1) That the technique fundamentally holds

<k​ayabanerve:matrix.org> 2) That while a single index may have infinite representations, you can't claim one representation is for distinct indexes

<k​ayabanerve:matrix.org> And CS's noted malleation, which would be fixed by range proofs, doesn't break those properties (so we don't need range proofs)

<k​ayabanerve:matrix.org> The third document from Veridise posits a complete interactive protocol, security proofs for it, and asserts my specification matches (after a pair of typos).

<k​ayabanerve:matrix.org> The current quote from CS is for review of the latest document and a summary opinion asserting if they're convinced this is valid for Monero.

<k​ayabanerve:matrix.org> My expectation is their work will confirm my inclinations, which I believe they share based on our discussions, their posited malleation doesn't break our use.

<k​ayabanerve:matrix.org> This is just such a long discussion because our use is from the third document, and larger context, and CS specifically reviewed the second document prior, where the range proofs could be argued depending on intent.

<k​ayabanerve:matrix.org> Hence why this current quote is meant not just to be review yet also a conclusive statement re: Monero's intent and use.

<k​ayabanerve:matrix.org> If we all agree the academia is sound, and my specification is, I'd note Veridise is currently contracted to perform the audit my impl matches.

<k​ayabanerve:matrix.org> (circling back to who checks the logic)

<k​ayabanerve:matrix.org> > So, when we allow the prover to specify the set, it's less proving these points sum to zero and more these points generate a subgroup of the elliptic curve where the prover knows an ordered index of the point at infinity?

<k​ayabanerve:matrix.org> This is probably my best technical comment for anyone who wants to understand this better.

<k​ayabanerve:matrix.org> It also isn't too horrifically technical and ideally is decently accessible.

<k​ayabanerve:matrix.org> Proving you know the index of an output point, over a specified generator, satisfies proving you know the discrete logarithm of the output point over the generator. Even for infinite possible indexes, the discrete logarithm is the index reduced by the curve order.

<r​ucknium:monero.social> I hope today we can reach loose consensus on this 175 XMR expense for FCMP research gist.github.com/kayabaNerve/3a32eb393a41f48fe7c183c31dc57680

<r​ucknium:monero.social> More comments from meeting attendees on this?

<j​berman:monero.social> Appreciate the detail kayaba

If I got anything from these explanations, which is not much, frankly, it's this: This review is really needed to clear things up once and (hopefully) for all. +1 from me

<r​ucknium:monero.social> Yes, thank you for explaining.

<k​ayabanerve:matrix.org> And we do reuse indexes (we prove one point is an index of the subgroup generated by U, then we prove one point is the same index of the distinct subgroup generated by V). That was why I commented we require the indexes, while malleable, cannot have multiple openings. And again, they do not so long as the subgroup generators have the same order (which they do in our use).

<k​ayabanerve:matrix.org> rbrunner: pay money to no longer have to think about things

<j​effro256:monero.social> Without knowing many details besides what was outlined by Kayaba here, 175 XMR seems a little high considering that the review is more or less an analysis of non-applicability of this malleation issue, which seems already somewhat understood by both parties. That's my two cents

<k​ayabanerve:matrix.org> :p

<k​ayabanerve:matrix.org> It is not jeffro

<k​ayabanerve:matrix.org> It's review of the third document specifying the interactive proof premised on this technique, and the summary opinion

<k​ayabanerve:matrix.org> ... also, technically the third document asserts our specification matches the describe interactive proof, so review of that claim includes further review of the fcmp spec

<k​ayabanerve:matrix.org> Also, the security proofs for the interactive proof premised on this technique

Right now it sounds a bit like a proof for a trick at a circus that a safety net is not necessary because the artists can do it. Better be damn sure.

<r​ucknium:monero.social> Do we have all three documents from Veridise?

<j​berman:monero.social> "I'd note Veridise is currently contracted to perform the audit my impl matches" -> isn't this the divisors impl we're discussing? For which we don't have someone contracted yet (as we're ideally waiting on the contest)? Or is that in reference to gadgets/circuit impl audit?

<r​ucknium:monero.social> I think I only have two here. Maybe I am missing one: moneroresearch.info/index.php?actio…hod=subcategoryProcess&id=1&catId=1

<k​ayabanerve:matrix.org> Ugh. I may have yet to upload the third document. I thought SGP had prior...

<k​ayabanerve:matrix.org> That'd help clarify for jeffro

<r​ucknium:monero.social> I may definitely possibly be missing it in MR.info . But if we can get the doc titles, that would clarify things.

<k​ayabanerve:matrix.org> rbrunner: From 0, you understand how proving knowledge of a discrete logarithm is saying you know the integer x such that x * G = O, right?

<k​ayabanerve:matrix.org> jberman: This is re: the gadgets which is not the divisor construction.

<j​effro256:monero.social> Sorry, I missed that the 175 proposal also includes review of Veridise's R1CS interactive proof. I mixed this up in my head with the other CS reviews of Veridise's work. Reading comprehension :/. That makes it a *lot* more justifiable

<k​ayabanerve:matrix.org> rbrunner: We don't specify x. We specify s_i such that x = sum_{i=0}^255 s_i 2**i.

I don't dare to answer out of fear of follow-up questions :)

<k​ayabanerve:matrix.org> Cypher Stack's claim is literally, as relevant to our use case, that instead of specifying bits such as 01000000, you can specify 20000000

<k​ayabanerve:matrix.org> It has an equivalent evaluation yet is malleated.

I think I see, on a very high conceptual level, what is attempted here, and I am on bord if the review confirms.

<k​ayabanerve:matrix.org> I mean, unless I'm horribly wrong and this is all broken, yet that's why we're paying Cypher Stack for their review and summary opinion on Monero's use and its security :p

<k​ayabanerve:matrix.org> I just want to be clear it's more a miscommunication than taking a safety net from trapeze artists

<j​berman:monero.social> Clarifying also: this proposal is for a summary opinion of divisors generally as used in FCMP++ (which includes addressing the malleation issue as one detail in that summary). I would think there is more beyond just the malleation issue and even just review of the 3rd Veridise doc, that encompasses such a review

<k​ayabanerve:matrix.org> As for miscommunications and how the project was managed,

<k​ayabanerve:matrix.org> > Other than what's in the gist, I don't have much to say other than I'm happy this'll be over.

<j​effro256:monero.social> +1 on the proposal

<r​ucknium:monero.social> If the Veridise document that is supposed to be reviewed is not yet publicly available, can it be posted ASAP? Possibly in the next few minutes?

<r​ucknium:monero.social> I think it is OK to approve this with less than 24 hours notice, but not having the document that is supposed to be reviewed goes a little far.

<k​ayabanerve:matrix.org> If I can message you to upload it, then yes

<k​ayabanerve:matrix.org> I truly thought it prior was uploaded to the research CCS. Apologies there.

<k​ayabanerve:matrix.org> Sent to Rucknium. I cannot upload it under the research CCS myself for some hours.

<r​ucknium:monero.social> Uploading very soon. Is this a 2025 doc or 2024?

<k​ayabanerve:matrix.org> I can do charades to try and act out its contents while we wait

<k​ayabanerve:matrix.org> Received March 5th, 2025

<j​berman:monero.social> sgp_: shared it in MRL chat here via a matrix link that's dead now: libera.monerologs.net/monero-research-lab/20250306#c505745 , we just need a more permanent URL (MoneroResearch.info is good for that)

<k​ayabanerve:matrix.org> Oh thank God I'm not insane and hoarding documents

<k​ayabanerve:matrix.org> Thank you jberman

<r​ucknium:monero.social> Sorry, I must have missed that

<r​ucknium:monero.social> Here: moneroresearch.info/259

<r​ucknium:monero.social> Any more comments on this proposed expenditure for FCMP research?

<r​ucknium:monero.social> +1 from me on gist.github.com/kayabaNerve/3a32eb393a41f48fe7c183c31dc57680

<j​berman:monero.social> btw still keeping this FCMP++ Research Tracking spreadsheet updated: cryptpad.fr/sheet/#/2/sheet/view/yP…A9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM

<r​ucknium:monero.social> I see loose consensus here in favor of 175 XMR for "Cypher Stack Divisors Conclusion" gist.github.com/kayabaNerve/3a32eb393a41f48fe7c183c31dc57680

<r​ucknium:monero.social> 6) Release of OSPEAD HackerOne and CCS milestone submissions. Analysis of risk of new decoy selection algorithm without a hard fork. github.com/Rucknium/OSPEAD gist.github.com/Rucknium/fb638bcb72d475eeee58757f754acbee

<r​ucknium:monero.social> I posted some analysis code in the gist ^. I don't really have any new results to share. I have been working on code speed improvements: github.com/Rucknium/OSPEAD/commits/main

<r​ucknium:monero.social> and actually re-running the OSPEAD estimates on the new MRL research machine. Using 100 threads and 800 GB of RAM :D

<r​ucknium:monero.social> The machine has 256 threads, but not using all of them at the moment.

<r​ucknium:monero.social> Thank you to CCS donors for supporting the 1TB of RAM purchase.

Yeah, we don't want to overdo it, do we :)

<r​ucknium:monero.social> And thank you to gingeropolous for setting up and managing the machine.

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

<j​effro256:monero.social> When deploy OSPEAD Hadoop cluster?

<j​effro256:monero.social> Just for fun, could you potentially imagine designing the data processing to use something like MapReduce? Is it possible/productive to parallelize it this way?

<r​ucknium:monero.social> jeffro256: `bjr()` has the capability to send jobs to separate machines in the same cluster. It uses an SSH connection, basically. I did that on previous runs, but not this one. There is overhead because you have to send data over the wire to the other machines. It's probably not worth the overhead now that `bjr()` is much faster.

<r​ucknium:monero.social> But you could split the processing by week of data, and send that over the wire.

<r​ucknium:monero.social> Some of the steps in the whole process aren't very parallelized. Pulling data from `monerod`? That's as parallel as I can get it. The multiple R threads are waiting on the node to respond. Even if I have multiple nodes on the same storage medium, I don't get much speedup, so it's probably I/O bounded. Then, the actual optimization in rucknium.github.io/OSPEAD/CCS-milestone<clipped message

<r​ucknium:monero.social> -2/OSPEAD-docs/_book/parametric-fit.html , which takes about a day, can't be parallelized much. The optimization process to numerically find the minimum of the function depends on the results of previous iterations.

<r​ucknium:monero.social> "aren't very parallelizable", I mean

<b​oog900:monero.social> have you tried reading directly from monerod's DB?

<r​ucknium:monero.social> No, because it's not documented AFAIK

<p​reland:monero.social> I second this, I don’t think it’s documented (or at least not documented well)

<p​reland:monero.social> It also is very finicky when trying to open it in standard database viewers

<b​oog900:monero.social> SyntheticBird: made this: github.com/Cuprate/old_book/tree/main/src/monero/database, also I made this tool in Rust: github.com/Boog900/monero-db-rs

<r​ucknium:monero.social> If I wanted to work on a speedup for that part of my workflow, it would be setting up incremental updates. As of now, I re-build the database in RAM from scratch, from the first RingCT block. But with incremental updates, if I want to add a new variable to the database, I would have to re-build from scratch again.i

<r​ucknium:monero.social> It only takes about 12 hours to pull the necessary data from the node.

<r​ucknium:monero.social> boog900: Thanks.