<m​onerobull:monero.social> Not the room for this

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

<k​ayabanerve:monero.social> 👋

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

<c​haser:monero.social> hello

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

<a​aron:cypherstack.com> Hello!

*waves*

Hi

<o​ne-horse-wagon:monero.social> Hello.

<v​tnerd:monero.social> Hi

<0​xfffc:monero.social> hi everyone

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

FCMP related work. I did an analysis of Ristretto and we had some discussions with kayabaNerve how to simplify the tree hashing.

me: started FCMP integration (initial task is working on the tree in C++ = table design, code flow, and tests). The async scanner PR (faster scanning) was also merged into ukoe's Seraphis lib, going to start making bite-sized PR's to monero core over the next week in preparation. Also opened a new CCS

<r​ucknium:monero.social> me: Working on the fee/ring size tradeoff to deter or defeat black marble flooding. And started working on using the Dulmage-Mendelsohn decomposition to analyze black marble flooding combined with "chain reaction analysis" from Section 4 "Chain reaction graph attacks" of github.com/Rucknium/misc-research/b…d/pdf/monero-black-marble-flood.pdf

<v​tnerd:monero.social> Me: Lws-remote-scanning *still*. Expect to be finished this week, unless I hit another snag

<k​ayabanerve:monero.social> As I said in NWLB, I worked extensively on FCMPs. The spec has been iterated with feedback, the GGBP updates made, and two auditors plan to submit SoW within two weeks. I meet a third today and have also distinctly discussed work with CS.

<0​xfffc:monero.social> Me: Wasted a lot of time last week. I am submitting minor PRs here and there. But overall my main task is performance benchmarking suite and then fixing the locking bottleneck we have.

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

<r​ucknium:monero.social> For the fee/ring size tradeoff, I am computing these metrics for the most cost-effective fee/ringsize response to a specific adversary budget:

<r​ucknium:monero.social> Adversary budget, nominal ring size, fee/byte, effective ring size when flooded by adversary's budget, user's cost for 2in/2out tx, user's tx size for 2in/2out tx, average block size (no flooding), Block size (continuous flooding), one year of blockchain growth (each combination of unpruned/pruned and no flooding/continuous flooding).

<r​ucknium:monero.social> Any other metrics I should compute?

tx verification time

<j​effro256:monero.social> Howdy

<r​ucknium:monero.social> How can we get that? Have a private testnet with a specific modified ring size and do benchmarks?

<c​haser:monero.social> Rucknium I think that's doable without any networking element

<k​ayabanerve:monero.social> Sorry, for a brief reminder, what's the ring size 40 verification time?

CLSAG benchmarks probably can be done without a private testnet

<r​ucknium:monero.social> Verification time in practice and in theory may be different.

I think the seraphis github issue had some benchmarks

<k​ayabanerve:monero.social> Yes and no. There's the unchanging verification time, and then the prep time.

<r​ucknium:monero.social> If we just want to do theoretical verification time, I am ok with that, too. There is time to read the data from storage, too.

<k​ayabanerve:monero.social> It's probably best to simulate the prep time off the mainnet DB?

<k​ayabanerve:monero.social> (So no actual testnet, just a DB)

<c​haser:monero.social> tevador: that's quite a killer reference hardware koe used there

<r​ucknium:monero.social> Tell a monero wallet to construct a K ring member tx from the mainnet database and then verify it? Ok. But probably it is better for someone else to code that since that's definitely not my comparative advantage.

<r​ucknium:monero.social> IMHO the March suspected spam showed that monerod has hidden bottlenecks, so actual performance can be different from theoretical.

<k​ayabanerve:monero.social> Grootle is 17ms no batching for 128. CLSAG is 24ms for 40?

<r​ucknium:monero.social> Ok. I will use koe's CLSAG benchmarks for now. If a C++ programmer wants to run more realistic benchmarks, that would be wonderful.

<r​ucknium:monero.social> I started testing with a Rust implementation of the Dulmage-Mendelsohn decomposition released with this paper: Vijayakumaran (2023) "Analysis of Cryptonote transaction graphs using the Dulmage-Mendelsohn decomposition." moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=39

<r​ucknium:monero.social> I am having some problems with the tests, but I don't know if it is a problem with the data I am submitting to the algorithm or if the algorithm is just slow (it is single-threaded for now).

<r​ucknium:monero.social> That's all I have on this agenda item. Anything else on this item?

<c​haser:monero.social> kayabanerve the benchmarks in koes's Seraphis paper are very close to 24 ms for a no-batch CLSAG 40

<c​haser:monero.social> raw.githubusercontent.com/UkoeHB/Se…eraphis/Seraphis-0-0-18.pdf#page=18

<r​ucknium:monero.social> 4) Generalized Bulletproofs Security Proofs github.com/cypherstack/generalized-bulletproofs/releases/tag/final Aaron Feickert

<a​aron:cypherstack.com> Yes!

<a​aron:cypherstack.com> kayabanerve identified an issue with the generalization in the report

<a​aron:cypherstack.com> It had to do with cross-terms in inner products

<a​aron:cypherstack.com> A fix was identified that works, but isn't as efficient as we'd hoped with the original idea

<a​aron:cypherstack.com> The report has been updated to reflect this; I reissued the tag so existing links point to the right one (but the full git history is there)

<a​aron:cypherstack.com> Kudos to kayabanerve for the find

<k​ayabanerve:monero.social> Clarifying, the additional functionality isn't as efficient.

What is the performance impact?

<k​ayabanerve:monero.social> The originally expected functionality is maintained for all intents and purposes.

<a​aron:cypherstack.com> Right

<k​ayabanerve:monero.social> We went from a

<k​ayabanerve:monero.social> 2 + 2(c//2) poly

<k​ayabanerve:monero.social> To a

<k​ayabanerve:monero.social> 2 * (1 + c) poly

<k​ayabanerve:monero.social> Yet we can halve the amount of needed c.

(@rucknum : if you want complete end-to-end daemon testing with a larger ring size, then this PR is a good reference for what needs to change on the C++ side for the daemon to allow larger ring sizes if you get someone available to do that monero-project/monero #8178/files)

<k​ayabanerve:monero.social> Except for branches which demand a full c to themselves.

<r​ucknium:monero.social> j​berman: Thanks. I remembered when you worked on the August 2022 hard fork you said that the ring size 11 -> 16 increase was not as simple as changing a few numbers in the code.

<k​ayabanerve:monero.social> We can preserve the original formula without the new features. The new formula and new functionality is overall more efficient.

So everything is going according to the plan or better.

<k​ayabanerve:monero.social> For GGBPs? Yes

I think we can move on to general FCMP discussion.

<r​ucknium:monero.social> 5) Research Pre-Seraphis Full-Chain Membership Proofs. getmonero.org/2024/04/27/fcmps.html

An interesting find was that Ristretto doesn't actually help us to remove torsion completely. So we decided to go with the simpler solution of mul8.

<k​ayabanerve:monero.social> The spec, gadgets, layers, and circuit are done. There's some cleanup I want to do on the top-level FCMP code and I need to support aggregate input proofs (which is multiple calls to the circuit).

<k​ayabanerve:monero.social> Performance is extremely hard to benchmark. I said I could not do a production grade lib and would only do one sufficient for working with.

Also the membership proof was simplified to proving that (+/-K,+/-I,+/-C) is in the tree. So we ignore the signs. This allows us to remove the complexity of "permissible points".

<r​ucknium:monero.social> Possible downside of torsion is that someone can write a Monero tx construction implementation that has a torsioned tx that the consensus verification would consider valid, but it would be fingerprintable, right? Like the strange txs that dangerousfreedom found?

A side effect is that people will be able to "spend" -C, so effectively burn funds. But we don't see any issues with that.

<k​ayabanerve:monero.social> I had the goal of 35ms in a batch of 10, the prior estimate. We are now clocking as low as 35ms for one and 10ms in a batch of 10. I hope a new Helios/Selene impl would get us ~2x further.

<k​ayabanerve:monero.social> Rucknium: FCMPs torsion clears everything.

<r​ucknium:monero.social> tevador: is it possible that a mathematics reviewer or a code auditor would see issues with that?

It should be reviewed during the audit, but I can't imagine what the problem would be.

<k​ayabanerve:monero.social> To be clear, that does not preventing outputs with torsion. It just limits the torsion to that and that alone.

<k​ayabanerve:monero.social> The more notable change of what tevador is discussing is the redefinition of key images from the point L to just the x coordinate.

re: torsion. Using Ristretto without torsion clearing actually reduces the anonymity set to 1/4 of the chain (all keys with the same torsion as the masked key).

So we need torsion clearing.

Yes, we are redefining key images by dropping the sign bit. Should be safe.

<k​ayabanerve:monero.social> And Ristretto offers less torsion clearing (2 steps not 3), but that's not worth it.

I think there will be a migration of the key images table during the update. That's the most efficient solution.

<r​ucknium:monero.social> The table in LMDB?

Yes.

<r​ucknium:monero.social> jeffro256: Any comments on this LMDB key images table migration? ^

<k​ayabanerve:monero.social> It halves the amount of spendable outputs.

<k​ayabanerve:monero.social> It means we need to ensure our address protocol can not only output uniqur keys yet keys with unique abs values.

<k​ayabanerve:monero.social> We either need a LMDB migration OR to double our reads (one for +, one for -).

<k​ayabanerve:monero.social> We may already need a migration. Are key images global or per pool?

what pool are you referring to there?

<k​ayabanerve:monero.social> Amount

Global

^global

<k​ayabanerve:monero.social> Historical outputs are denominated.

<k​ayabanerve:monero.social> Great, then we can either do 2x reads or a migration.

migration is fine

Btw, the migration of key images is effectively a soft fork. It makes double spend validation stricter.

<k​ayabanerve:monero.social> It's justifications are on the gist, but it removes a minor DoS vector re: permissibility.

<k​ayabanerve:monero.social> Crafted points could very feasibly trigger hundreds (thousands?) of additions on accumulation.

And it removes a lot of complexity from the specs and the implementation.

<r​ucknium:monero.social> Monero hard forks are usually also soft forks, right? AFAIK, the definition of the two types of forks is that a hard fork allows new txs that used to be not valid and a soft fork prohibits types of txs that used to be valid.

Soft fork makes some previously valid transactions invalid, but previously valid remain valid.

<k​ayabanerve:monero.social> Monero hard forks are hard.

handling compatibility between old nodes <> updated nodes before fork height sounds a bit tricky, but fine. sounds like we may have to keep the old table around up until the fork height

<k​ayabanerve:monero.social> The addition of BP+ wouldn't be accepted by old nodes so BP+ was a HF.

<k​ayabanerve:monero.social> Same with view tags, as we didn't use TX extra.

Correction: newly valid are also previously valid

or at least, nodes would need to keep key images around that don't pass the stricter height up until the fork height

stricter check*

Only if we expect someone to spend both KI and -KI. Otherwise both give the same result.

and producing both KI and -KI as valid key images implies solving the DLP

<k​ayabanerve:monero.social> Due to the existence of the usage of a Htp tbc.

<k​ayabanerve:monero.social> If we had a constant generator for key images, that would not be the case.

<k​ayabanerve:monero.social> But since we use a hash to point, key images are binding to all components of the output key.

For example, when we fixed the octuple spending bug, we do the same check also for key images before the fix.

So we don't need to keep the less strict rule for old outputs. That was my point.

ok I follow, migration sounds fairly straightforward

Anyways, all this is just a performance optimization. AFAICS the math checks out.

<k​ayabanerve:monero.social> In total, FCMP++s have had a lot of work done on development, have hit performance goals without the proper curve impls, and are moving steadily ahead on research.

integration moving full steam ahead as well

<r​ucknium:monero.social> Fantastic. Any other business?

<s​yntheticbird:monero.social> In the current trajectory, should we expect full public release in 1.5 years as planned ?

integration I think is still complete-able within 6 months fwiw

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

<c​haser:monero.social> any retrospective thoughts on the May 3 consolidation flood, when we had a ~8 hour constant stream of 150/2's (i.opnxng.com/r/Monero/comments/1ci9…days_flood_attack_on_the_network/)? is there any indication that it's related to the March flood? are there any potential privacy implications or new insights into DDoS vectors? it still troubles me how this caused major<clipped message>

<c​haser:monero.social> disruption to some nodes.

there is another consolidation event today and the backlog is presently being cleared

<c​haser:monero.social> nice catch. it's interesting that it's around the same of the week.

<a​lex:agoradesk.com> The consolidation flood really affects nodes a lot. Feels like a DoS vector.

<a​lex:agoradesk.com> Moreso than the tx flood aka black marble attack.