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

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

<k​ayabanerve:monero.social> 👋

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

*waves*

Hello

<c​haser:monero.social> hello

<v​tnerd:monero.social> Hi

<j​effro256:monero.social> Howdy

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

<k​ayabanerve:matrix.org> Organizing research/audits, as usual.

<r​ucknium:monero.social> me: Helping with stressnet. Successfully (I think) ran the Dulmage-Mendelsohn Decomposition on a simulated set of transactions that have been flooded by black marbles. Running some stats on the mainnet p2p transaction logs to see if they have evidence of the black marble flooding.

<j​effro256:monero.social> me: polishing fix PR for subaddress-related temporary scanning misses

me: grow_tree and trim_tree are approaching production-grade ready, continuing on trim_tree this week

<v​tnerd:monero.social> I worked on LWS frontend API.

<r​ucknium:monero.social> 3) Stress testing `monerod` monero-project/monero #9348

<r​ucknium:monero.social> Maybe rbrunner can explain what he found in "Daemons processing big blocks may bump against serializer sanity checks and fail to sync" monero-project/monero #9388

It's mostly described in the issue.

The short version: Sanity checks, put in place a few years ago, trigger if daemons asks other daemons for 20 very large blocks

because asking for 20 blocks is what they do per default

The immediate "band aid" measure on stressnet was syncing single blocks, before the root issue was known, which works

I submitted a PR to stressnet to go higher with the sanity checks

Durable and sensible solution might be to go dynamic with that number of blocks requested, depending on average blocksize

<j​effro256:monero.social> Is that PR on spackle's repo?

Yes. 3 constants redefined bigger.

<r​ucknium:monero.social> Here's rbrunner's that set sanity checks higher: spackle-xmr/monero #12

The behavior is acutally quite funny: The daemon starts to disconnect every other daemon because it thinks they all send it corrupt data :)

<r​ucknium:monero.social> Here's mine that just set default sync chunk to 1: spackle-xmr/monero #8

<j​effro256:monero.social> Damn 16K bytes per string is a really tiny limit lol

I think it's 16'000 strings.

<j​effro256:monero.social> Ah I see, that makes more sense

<r​ucknium:monero.social> We are at about 4MB block size now on stressnet. No one falls behind permanently, but there is some temporary fall-behind and re-org/orphaning at this block size: monitor.stressnet.net

moneromooo mentioned that they just chose the limits more or less according to gut feeling, not as the result of some testing, or even simulation

So we probably should not give too much weight to their actual current values

<r​ucknium:monero.social> ofrnxmr set up a stressnet block explorer at (onion hidden service): stressgguj7ugyxtqe7czeoelobeb3cnyhltooueuae2t3avd5ynepid.onion

<j​effro256:monero.social> So blocks could have 820 txs per block, and if there's 20 blocks, then that would go over the string limit?

It seems so, yes. I saw it in the debugger go over the limit.

After getting around 30 MB of data

Although I could not find out where exactly, because that complicated templated serialization code was beyond my debugging fu

<j​effro256:monero.social> Well another issue at hand is why the *serializer* doesn't check those limits while it is writing out

Well, duh, yes

I think it's protection about doctored data that blows up to gigabytes and brings down Monero daemons. Was a thing once as a possible attack, if I remember correctly

*protection against

Maybe vtnerd knows more

I don't plan to work more on this, I think somebody with better knowledge should find a good solution here

Going dynamic might not be trivial

<v​tnerd:monero.social> The current limit was chosen somewhat arbitrarily by moo. My new serializer often does limits based on wire size - a string is frequently required to be of minimum length, etc, instead of a max count. Unfortunately there are still some max counts in a few places that I didn't completely remove

<r​ucknium:monero.social> Do any devs have requests for what spamming "configuration" to set up on stressnet? Right now we are spamming 1in/2out with 4MB blocks and a small txpool. We can increase the txpool, lower/raise block sizes, maybe try many-input txs to analyze "A lot of 150/2 transactions in the txpool causes memory spike / OOM" monero-project/monero #9317

<j​effro256:monero.social> Doing 1in/16out will let you create the highest number of transactions as quick as possible

<j​effro256:monero.social> Maybe having 150 1-input txs will also cause the issue?

<r​ucknium:monero.social> We are at about 20 txs/second being confirmed with 4MB blocks

I think there is nothing special with having 150 1-input transactions? Maybe I misunderstand.

We have hundreds of transactions going into a single block on stressnet now ...

<k​ayabanerve:matrix.org> For byte spam, inputs is the way to go.

<r​ucknium:monero.social> 150 1-input txs is sort of what we are doing now...over and over again

Without OOM problems, as far as I am aware

<k​ayabanerve:matrix.org> (except you consume inputs faster than you make them)

<j​effro256:monero.social> And you haven't run into the OOM issue at all?

<r​ucknium:monero.social> Per byte of data, inputs also take longer to verify than outputs according to my tx performance tests

Seems so, yes

<r​ucknium:monero.social> jeffro256: Low-RAM stressnet machines OOM if they have too many connections. On my 4GB node I've set connections to 4in/4out IIRC

All kinds of problems, but I did not hear about daemons running out of memory. Not on machines with "reasonable" amount of memory to start with

<r​ucknium:monero.social> You can check the monitor node's RAM use, connections, CPU, etc on monitor.stressnet.net

<r​ucknium:monero.social> Or did the data collection go down?

<j​effro256:monero.social> nice website ;)

<r​ucknium:monero.social> I'll check that after the meeting

<r​ucknium:monero.social> 4) Potential measures against a black marble attack. monero-project/research-lab #119

<r​ucknium:monero.social> I made progress on two topics.

<r​ucknium:monero.social> A paper Vijayakumaran, S. 2023, "Analysis of Cryptonote transaction graphs using the Dulmage-Mendelsohn decomposition." Paper presented at 5th Conference on Advances in Financial Technologies (AFT 2023). moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=39

<r​ucknium:monero.social> was released with a DM decomposition program written in Rust. I took the transactions that occurred during the suspected black marble flooding and eliminated the "black marbles" and removed black marble ring members from "real" txs. Then I ran the DM decomposition to see if even more ring members could be eliminated.

<r​ucknium:monero.social> For more info on this attack, see Section 4 "Chain reaction graph attacks" of my github.com/Rucknium/misc-research/b…d/pdf/monero-black-marble-flood.pdf

<r​ucknium:monero.social> According to my initial calculations, the suspected black marble flooding could reduce 0.5% of rings to effective ring size one (i.e. the real spend could be deduced) without trying any chain reaction graph attacks. In preliminary results, the Dulmage-Mendelsohn Decomposition can double that percentage to 1%. That number is within what I expected.

<r​ucknium:monero.social> The other topic is analyzing p2p tx broadcast logs. I have two questions.

<r​ucknium:monero.social> How is the time of queue set in src/cryptonote_protocol/levin_notify.cpp for fluff txs? I think nodes wait for some random time before sending a gossip message with the txs it has accumulated. How is that set?

<r​ucknium:monero.social> The other question is whether Dandelion++ starts broadcasting at the "top of the minute", e.g. 17:31:00. In the data the gossip message arrival times are not uniformly distributed across the seconds of a minute. It almost looks like D++ does start broadcast at the top of the minute. I see higher probability of receiving a tx gossip message in the first 15 seconds of a minute. Then<clipped message

<r​ucknium:monero.social> there is a smaller bump at about :40, which is the D++ embargo timeout time.

<r​ucknium:monero.social> Another explanation is that some entity is broadcasting lots of txs at the top of the minute...like a spammer

<v​tnerd:monero.social> I don't see how the code waits until the top of a minute, that sounds like something custom

<r​ucknium:monero.social> Thanks. Then it's a possible fingerprint

<r​ucknium:monero.social> If the gossip messages were uniformly distributed across a minute, then each second would have 1.667% of the messages. But what I am seeing is that the 10th second has 1.8%.

<r​ucknium:monero.social> This is with about 15 million gossip messages. It cannot be random variation

<r​ucknium:monero.social> Thanks to people who submitted monerod logs :)

<r​ucknium:monero.social> I asked my first question because I noticed that txs were 'clumped" in gossip messages more than I expected.

Hmm, I wonder why you would care about minutes if you spam.

<r​ucknium:monero.social> I mean, I want to understand the process of clumping

Ah, maybe some primitive throttle that results in this?

<r​ucknium:monero.social> I don't think the spam script was set to maximum of what it was capable of.

<r​ucknium:monero.social> 5) Research Pre-Seraphis Full-Chain Membership Proofs. Discuss hiring Cypher Stack for 4 days of work (38 XMR) reviewing Veridise's proofs of the divisor technique. getmonero.org/2024/04/27/fcmps.html repo.getmonero.org/monero-project/c…als/-/merge_requests/449#note_25181

<r​ucknium:monero.social> kayabanerve: You wanted to discuss this

<k​ayabanerve:matrix.org> Yep

<k​ayabanerve:matrix.org> So the divisor proofs are complete, with ~3-4 hours to spare which is now moving to the R1CS circuit review as available.

<k​ayabanerve:matrix.org> That means we need to

<k​ayabanerve:matrix.org> 1) Have the proofs reviewed (which is arguable tertiary since Eagen originally proposed the technique)

<k​ayabanerve:matrix.org> 2) Potentially be fine extending Veridise's contract 2-3 hours for the full R1CS review which should be less than a grand?

<v​tnerd:monero.social> Oh that it is expected if I'm understanding you correctly. There's a fluff delay so txes will be grouped somewhat

<k​ayabanerve:matrix.org> I solicited two quotes and received one from Cypher Stack on the proof review. It was 38 XMR @ 4 days (I believe 4 days of work, not 4 days of turnaround). cc Diego Salazar to confirm the quote if they're around.

<v​tnerd:monero.social> But I wouldn't expect it to happen specifically at the top of a minute

<d​iego:cypherstack.com> ye

<k​ayabanerve:matrix.org> So that'd be my endorsement, and now subject to jberman 's co-endorsement (prior solicited yet needing an on-the-record version) and then MRL's.

<r​ucknium:monero.social> vtnerd: Thanks. I skimmed the code with my non-C++ eyes and I couldn't find how the fluff timer is set. Every X seconds, with a random component?

<k​ayabanerve:matrix.org> And then, I forgot to bring this up prior, but yes, I'd also like to confirm it's fine if we contract Veridise a few more hours as necessary to complete the R1CS review. It was projected at 5 hours and we're a bit short of that much time remaining. It's all reasonable to me.

<v​tnerd:monero.social> I'm skimming the code to remind myself hold on

+1 for Cyper Stack divisor proof review, +1 for Veridise contract extension for R1CS review. Both sound solid to me

<r​ucknium:monero.social> kayabanerve: Thanks. You said you solicited two quotes for the divisor proof review. Any info on the second one?

<k​ayabanerve:matrix.org> I also have a tertiary topic I'd like to solicit MRL's opinion on, if we have a few minutes after the this Veridise discussion. It should be relatively brief, and is vaguely related to FCMPs, but I apologize if I should've brought it up prior and gotten it officially on the agenda. I only thought of it a couple days ago.

<k​ayabanerve:matrix.org> I solicited two and received one.

<k​ayabanerve:matrix.org> Because we didn't actually receive the other quote in a timely fashion (solicited over a week ago), we decided to move on with the proposal from CS which is reasonable and from the very trusted Aaron.

<r​ucknium:monero.social> "Cyper Stack divisor proof review" and "Veridise contract extension for R1CS review" sound good to me.

From the little I can really judge this, good for me as well ...

<k​ayabanerve:matrix.org> I will note we did not solicit a full spread as we originally did. Given the prior prices we've been quoted, I'm definitely preferring working with boutique firms (which is leading to not sending out as many emails and doing as many calls for results probably not worthwhile).

<k​ayabanerve:matrix.org> rbrunner: Progress :D Exciting things :D Sign over more money and get more progress :D

Suuure :)

<k​ayabanerve:matrix.org> On a much more legitimate and descriptive note, the divisor technique is a way to efficiently prove in-circuit a scalar multiplication.

<k​ayabanerve:matrix.org> We use it to add (and remove) terms to Pedersen Commitments

<k​ayabanerve:matrix.org> The divisor technique makes the cost 7 multiplicative constraints. Otherwise, it'd be 512.

<k​ayabanerve:matrix.org> So it's 72x faster than prior state of the art.

<v​tnerd:monero.social> The randomized timer is set per connection - slightly longer timeout for in connections. It gets set when there are no txes in the connection queue and gets flushed entirely when it expires. So you should see batches of txes sent

<k​ayabanerve:matrix.org> The technique was posited by Eagen in 2022. Eagen's divisor work is largely subject to a lot of the same criticism as faced BP++. Aaron Feickert may be a more accurate person to comment as an individual who actually does review.

<k​ayabanerve:matrix.org> Veridise was prior contracted to do a proper set of proofs for the technique, expanding on the rather sparse notes of Eagen on safety (~ half a page).

<r​ucknium:monero.social> vtnerd: Thank you!

<a​aron:cypherstack.com> I haven't done a thorough review of the divisor preprint, so I can't provide meaningful conclusions on that yet

<k​ayabanerve:matrix.org> We now have a 12 page document establishing the background and security. While that's arguably already secondary review, Eagen being the primary source, tertiary review of the idea/secondary review of the proofs is reasonable.

<a​aron:cypherstack.com> My very initial reading suggested that there could be similar issues as in BP++ (at least the initial version of BP++)

<k​ayabanerve:matrix.org> So that's all this is. Hiring Cypher Stack/Aaron to do review and ensure we actually get such great performance safely :)

<r​ucknium:monero.social> IMHO, giving the task of review to a skeptical reviewer is a good move. That's what is proposed AFAIK.

<k​ayabanerve:matrix.org> By the numbers, I'll also note Veridise (with extension to complete the R1CS review) + this review by Cypher Stack is cheaper than both the Cypher Stack and Goodell quotes to do the proofs AFAICR.

<k​ayabanerve:matrix.org> If no one has any objections, and the above summary provides sufficient clarity, I'd like to bring up my semi-adjacent topic. Would that be fine with you, Rucknium?

<k​ayabanerve:matrix.org> (i ask as you execute our agenda)

<r​ucknium:monero.social> Sounds great. I think we have loose consensus in favor of your two proposals today.

<k​ayabanerve:matrix.org> 👍️

<k​ayabanerve:matrix.org> My other topic is simply how I want to contract review of the unreviewed hash function in Monero which we rely on for security.

<k​ayabanerve:matrix.org> This is out of scope of the FCMP work, and the FCMP research budget, but I don't want to throw a researcher into submitting a CCS/MAGIC fundraise without a MRL endorsement.

<k​ayabanerve:matrix.org> And I'd like to get this review done before the FCMP hard fork so if our unreviewed hash function is found unsafe, we can replace it at that time.

You mean the CryptoNight "slow hash"?

<k​ayabanerve:matrix.org> I'm specifically referring to the bespoke hash to point within the Monero codebase, which has been documented yet not reviewed, and I would not be surprised if it had bias.

<k​ayabanerve:matrix.org> If we're argue it as targeting 126 bits of security, and it has 110, it's fine yet should be deprecated and replaced (and we can replace it any time. Right now, the FCMP++ proposal has the key image generator a variable in the tree. It can be calculated however we want, including fixed to some constant if we had a proposal there)

<k​ayabanerve:matrix.org> Hm. That's an interesting thought for its own line of research :D

<k​ayabanerve:matrix.org> Yet to go back to my original point: bespoke hash to point probably not great. We don't know if it's great or acceptably bad or very bad. We should have this reviewed. If not great, FCMP++ should replace it with Elligator or similar.

<k​ayabanerve:matrix.org> I'd just like to ask MRL that sounds reasonable and if I get a researcher to submit a CCS/MAGIC fund raise, they have backing on the premise being worthwhile.

<a​aron:cypherstack.com> Any reason _not_ to simply go with Elligator, as it's well studied?

<a​aron:cypherstack.com> Or is that "simply" carrying too much weight

<k​ayabanerve:matrix.org> Performance, political capital, we still have to do this research to ensure supply hasn't been violated historically.

<k​ayabanerve:matrix.org> Elligator (at least as used, which may be some variant) does two hash to points and sums them to create a non-biased point AFAIK.

<k​ayabanerve:matrix.org> A lot of the hash to points discussed for standardization do so from my brief experience with them (which may be incomplete).

<k​ayabanerve:matrix.org> So I don't want to propose a 50% perf drop without justification. We get the justification it's 'standard' but now we have two hash algos and the old is tech debt still needing impl/maintenance. Even if we said the security alone was sufficient, we still need to understand the security of the old one.

<k​ayabanerve:matrix.org> And if the old one ends up secure, why move off?

<a​aron:cypherstack.com> Yep, basically

<k​ayabanerve:matrix.org> Considering its keccak256 with some method of determining a y coordinate which is valid, and recovering the x, my expectation/hope is that it's a bn254-esque issue.

<k​ayabanerve:matrix.org> Deprecate, don't use, still out of human feasibility as understood today.

<r​ucknium:monero.social> 50% perf drop on this operation means what percent drop on verifying a whole tx?

<k​ayabanerve:matrix.org> Which means if we replace it, we're fine and can move on.

<r​ucknium:monero.social> i.e. how important is it?

<k​ayabanerve:matrix.org> Uhhhh right now or FCMP++s?

<r​ucknium:monero.social> If you can give an answer on both

<k​ayabanerve:matrix.org> Right now, we don't cache the key image generator. Every ring signature loads the output and re-runs the hash to point AFAIK.

<k​ayabanerve:matrix.org> So input verification would decrease... 10-20%? Off-hand estimate?

<k​ayabanerve:matrix.org> That hash to point will be 1/3 hash functions done by the CLSAG which is dominated by its hashes IIRC.

<a​aron:cypherstack.com> Well, presumably you could use a faster hash function with Elligator, no?

<a​aron:cypherstack.com> If you'd already be migrating

<k​ayabanerve:matrix.org> Under FCMP++s, input verification doesn't do a hash to point. We calculate it once per output and save it to the tree.

<k​ayabanerve:matrix.org> Like honestly, we may even be able to do a static point there now that I think about it.

<a​aron:cypherstack.com> _e.g._ one of the BLAKEs

<k​ayabanerve:matrix.org> Eh. No. We rely on the explicit hash to point to achieve a binding property in the linking tag and prevent using a view key to burn other outputs.

<k​ayabanerve:matrix.org> So we'd need to at least solve that problem, and then also redo the considerations on related key attacks.

<k​ayabanerve:matrix.org> And then even if it wasn't for those issues/necessities, we just had the composition reviewed and I can't sign off on that much time/effort when it's an optimization/protocol simplification at best.

<k​ayabanerve:matrix.org> Anyways. Should be marginal under FCMP++s, off-hand I'd guess 10-20% worse CLSAG verification due to lack of caching.

<k​ayabanerve:matrix.org> Aaron Feickert: I'd argue the end hash would need to be 20+% faster to be justified, and likely under the FCMP++ design (which determines and saves the key image). We can make the current CLSAG verify use a variable hash to point yet we'd have to track ring member age with the ring member which is a mess.

<k​ayabanerve:matrix.org> (if we were picking a new function and justifying it based on performance. A 5% faster algorithm isn't worth complicating the specification)

<a​aron:cypherstack.com> Could be interesting to time that out... Elligator-upon-some-BLAKE vs. CN

<k​ayabanerve:matrix.org> Interesting to time out, I agree :D

<a​aron:cypherstack.com> I've seen solid throughput numbers for the BLAKEs, but don't recall what that means for small inputs where "throughput" probably isn't really the measurement you want

<k​ayabanerve:matrix.org> But again, historical review is necessary to ensure current integrity so I'd just like MRL's endorsement on an effort to find *someone* to review the current fn for bias/determine how much bias it has.

<r​ucknium:monero.social> kayabanerve: Can you say if you have a candidate to attempt this?

<k​ayabanerve:matrix.org> Worst case, it's not collision resistant and we need to start arguing the security of CryptoNote ring signatures? Does CLSAG's soundness hold even if the dynamic generator is non-uniform Aaron Feickert ?

<k​ayabanerve:matrix.org> Rucknium: No, I asked one person and they deferred believing there to be better candidates. I don't want to cold email the Elligator people before knowing MRL endorses this research.

<k​ayabanerve:matrix.org> Because I can cold email and organize a CCS, but then CCS will ask for MRL's opinion and we'll be in a MRL meeting a month from now (after I used a bunch of people's time) discussing the premise of this research as we are now :p

<k​ayabanerve:matrix.org> I'd like to confirm the premise is agreed upon, find a candidate, and then have MRL solely review the specific proposal (not the premise of the proposal, which has become a stated goal)

<r​ucknium:monero.social> I don't fully understand this specific issue, but I am in favor of funding research on potential vulnerabilities. It sounds like this is that.

<k​ayabanerve:matrix.org> So don't worry, not going to ask to raise 100k ahead of time as a slush fund for this research :p

<a​aron:cypherstack.com> It assumes the hash-to-point function can be modeled as a random oracle

<k​ayabanerve:matrix.org> Yes but does it have to be a _good_ random oracle for _soundness_

<k​ayabanerve:matrix.org> (I can follow up in DMs later, don't worry :) )

<a​aron:cypherstack.com> Yeah, probably a little off topic for this meeting

<a​aron:cypherstack.com> (basic answer... consequences of "bad" RO unclear)

<r​ucknium:monero.social> I have a question: If it isn't as secure as we want, can the issue be eliminated on the blockchain by prohibiting new txs with that operation (e.g. use Elligator instead), or do the unspent outputs on the chain _need_ to use the old operation? So it would be harder to stop a vulnerability from being exploited later

<k​ayabanerve:matrix.org> Yeah, so worst case (<110 bits of security), we'd do follow up work on the CN ring sigs/MLSAG/CLSAG to investigate impact.

<k​ayabanerve:matrix.org> This effects the key image.

<r​ucknium:monero.social> Can we get the opinion of tevador about this topic? Or jeffro256 ?

<k​ayabanerve:matrix.org> Hm. Both affects and effects are arguable as valid there. I meant to type affects but I'm not sure I'm wrong for not doing so...

<k​ayabanerve:matrix.org> But yeah, we can't move to Elligator universally without enabling double spending all historical outputs.

<r​ucknium:monero.social> By the way, monitor.stressnet.net is back. The data collector script had died.

<k​ayabanerve:matrix.org> The exact implications of it being bad are unclear.

<k​ayabanerve:matrix.org> I'd want to say under FCMP++, it'd only break unlinkability? I don't believe we argue soundness at all as premised on the hash to point?

<a​aron:cypherstack.com> IIRC soundness would not be directly affected

<k​ayabanerve:matrix.org> We output `I' = I + r_i V` and a commitment to `r_i`. The membership circuit asserts the r_i is consistent. Even if you found a relationship of I to V, it doesn't matter as we computationally bind to the V randomness.

<k​ayabanerve:matrix.org> Right. So even if the existing points are biased, and you can find relationships for existing points, it shouldn't be an issue.

<a​aron:cypherstack.com> At no point do things like commitment binding depend on any particular relationship between the hash output and other generators

<k​ayabanerve:matrix.org> And we'd stop the ability to produce new unbiased points, so you could only work off what's already on-chain.

<a​aron:cypherstack.com> (this was specifically checked)

<k​ayabanerve:matrix.org> The larger concern is the existing ring signatures, MLSAG historically, and CLSAG. CLSAG very strongly transcripts and I hope its soundness to be fine. Ring signatures... may have some short Schnorr argument? MLSAG, I'd hope to follow CLSAG.

<k​ayabanerve:matrix.org> But ring signatures' use of hash to point is incredibly load bearing, to a horrific degree.

<k​ayabanerve:matrix.org> That's its own nightmare. Thankfully, FCMP++s mean we can finally deny TXs with ring signatures (they're still allowed today for migratory purposes).

<k​ayabanerve:matrix.org> Anyways. Whole thing. Investigating the bias would be the first step to any discussion.

<a​aron:cypherstack.com> FWIW I can take a closer look at the CLSAG security proofs later to investigate this more thoroughly

<a​aron:cypherstack.com> It's a good question

<a​aron:cypherstack.com> (anyone else is of course welcome to do this too)

<k​ayabanerve:matrix.org> Part of me doesn't want you to waste your time before we determine bias, yet I'd explicitly be curious if MLSAG/CLSAG soundness holds upon a bad ROM here.

<r​ucknium:monero.social> kayabanerve: A decision on this can wait until next meeting, right? Maybe get more opinions and discuss next time.

<k​ayabanerve:matrix.org> it can? It just delays my contacting people. I have yet to hear any objections into this research which is obviously ambiguous, and in the worst case, enables forging key images/proofs.

<a​aron:cypherstack.com> Eh, I'm curious :D

<k​ayabanerve:matrix.org> So if you want the official position to be until next meeting, sure, yet I personally think the premise has been well received enough I'm fine moving forward.

<a​aron:cypherstack.com> "Do random oracles actually exist" is a major load-bearing question for a lot of cryptography...

<k​ayabanerve:matrix.org> But also yes, I'd love tevador's opinion.

<k​ayabanerve:matrix.org> (And if I'm fine moving forward, I get it's not yet officially MRL backed and promise to not so represent it ;) )

<k​ayabanerve:matrix.org> If MLSAG/CLSAG holds, the absolute worst case is we migrate all existing RCT outputs yet not all historical CN outputs. Then we turnstile those so it goes from inflation to theft.

<k​ayabanerve:matrix.org> (migrate into FCMP++)

<k​ayabanerve:matrix.org> I have nothing else to say immediately on this (and apologies it took much longer than expected), other than the above comment being *why* this review should complete *before* the FCMP++ PR is finalized. We can finish discussions next week for any official endorsement of the research topic (though yes, I'll probably start reaching out prior to the official endorsement). I have not<clipped message

<k​ayabanerve:matrix.org> hing else to say on FCMPs other than congrats to CS for the new work.

<r​ucknium:monero.social> --- END MEETING ---

<r​ucknium:monero.social> Thanks, everyone.

<s​gp_:monero.social> thank you

Is the 'hash to point' function the only one in the current protocol that doesn't already have a formal review conducted (and one assumes published)?

<k​ayabanerve:matrix.org> There are two hash to point functions, technically. Informally, decompress(keccak256()), which has a failure rate, and map(keccak256()), used for key image generators and without a failure rate.

<k​ayabanerve:matrix.org> The former is only used for the generator `H`. The latter is used for key image generators and BP generators.

<k​ayabanerve:matrix.org> Aaron Feickert: should be able to comment that the former is fine? They may decline to as the exact security properties may be difficult to define exactly, yet I've never heard it implied to be significantly faulty.

<a​aron:cypherstack.com> The former should be fine, yes

<k​ayabanerve:matrix.org> I'll also note Shen notated the function a bit, and cited other hash to points at the time (noting how this construction was distinct). Unfortunately, they didn't work on positing it as comparable/secure. My points of contact will presumably be the people who proposed the hash to points being standardized, some modern researchers, and potentially one or two who have similar constructions.

<k​ayabanerve:matrix.org> (if anyone are similar)

Excuse my ignorance, but why would the former be fine, and not the latter?

<k​ayabanerve:matrix.org> Because decompression effectively forces rejection sampling until it finds a valid y.

<k​ayabanerve:matrix.org> The map function does coercion which may produce a non-uniform y.

The cryptonote hash-to-point originates in this paper: arxiv.org/pdf/0706.1448. And is informally described by Shen Noether in web.getmonero.org/resources/research-lab/pubs/ge_fromfe.pdf

kayabanerve: i really appreciate that explanation. I actually think i understand it!

UkoeHB: nice, thanks.

<k​ayabanerve:matrix.org> UkoeHB: Shen described it as novel. TIL there is a citation for it.

<k​ayabanerve:matrix.org> Do you have further background on where/when that was found? I'm pulling it up ro compare now

<k​ayabanerve:matrix.org> *to

<k​ayabanerve:matrix.org> Not to say the theory isn't related, yet the formula Shen notated do not appear present in the former paper.

<k​ayabanerve:matrix.org> That could be notational, I won't claim to know either algorithm expertly after 10m, or could be a lack of equivalence.

<k​ayabanerve:matrix.org> Or it could be how the former isn't for hashing to twisted edwards and the latter would have to embed the map from the Weierstrass curve in order to hash to a twisted edwards point.

<k​ayabanerve:matrix.org> Pulled up ZtM. It cites the CryptoNote WP for that claim.

<k​ayabanerve:matrix.org> Found the relevant citation in the CN WP. I'd have to ping Aaron Feickert on if the former actually lines up with the latter, assuming some Weierstrass map was crammed in?

I never looked into the math of it, so not sure if the citation is accurate.