<r​ucknium:monero.social> MRL meeting in this channel in two hours. Anyone with a matrix.org homeserver Matrix account want to say here that matrix.org users sometimes cannot see all messages here, but we can see them? And to read invisible messages by refreshing libera.monerologs.net/monero-research-lab

reposting from IRC incase matrix dot org cant see ....

<r​ucknium:monero.social> MRL meeting in this channel in two hours. Anyone with a matrix.org homeserver Matrix account want to say here that matrix.org users sometimes cannot see all messages here, but we can see them? And to read invisible messages by refreshing libera.monerologs.net/monero-research-lab

<r​ucknium:monero.social> nioCat: Thanks, but AFAIK when matrix.org users cannot see monero.social messages, they cannot see IRC messages either. The IRC relay is a monero.social user.

<r​brunner7:monero.social> That's also my understanding regarding IRC, sadly it seems to help only if you leave Matrix aside for the moment and "step down" to IRC, with an IRC users, if your Matrix user is on matrix.org. In Monday's wallet group meeting we more or less all ended up on IRC ...

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

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

<a​aron:cypherstack.com> Hello!

Hello

<s​yntheticbird:monero.social> Hi

hello!

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

Hi

<d​iego:cypherstack.com> Hi hi

<r​ucknium:monero.social> me: More analysis of the suspected spam. I think I can push the new draft by the time we get to the spam agenda item 😅

<a​rticmine:monero.social> Hi

<s​yntheticbird:monero.social> Working on a monitoring software for monero nodes. I'll use it to build a dataset on which I want to train a neural network to identify network anomalies. This will be part of webpanel idea I had for a little while

me: finished reviewing @jeffro256 's PR to write txs to disk once instead of twice on sync (monero-project/monero #9135), and wrapping up the Seraphis lib async scanner to speed up wallet scanning another ~20-40%

<a​rticmine:monero.social> Working on fees and scaling. In particular to support FCMP and ring sizes of 40 or higher

<a​rticmine:monero.social> Along the lines of what I mentioned before. Also taking a close look at minimum node relay fees

<r​ucknium:monero.social> 3) Update from CypherStack on Bulletproofs++ Peer Review: ccs.getmonero.org/proposals/bulletproofs-pp-peer-review.html

<d​iego:cypherstack.com> That's us!

<d​iego:cypherstack.com> Progress continues. Things are going smoothly. We expect to complete this proposal by the end of the month.

0xFFFF has paused his current ccs for the foreseeable future (he is working on the lmdb read/write lock PR, so just wanted to share for visibility)

In a few days then? Splendid.

<a​aron:cypherstack.com> We're nearly finished with the report, yes

<a​aron:cypherstack.com> It will no doubt require some additional polish after that. I would be shocked if it were free of typos :D

Hoping for a positive outcome of course, i.e. that it will indeed make sense for Monero to switch to ++

<r​ucknium:monero.social> Were you able to figure out if the security proofs were sound?

<r​ucknium:monero.social> You can wait if you want, but I thought maybe you wanted to be on the agenda to give more details :)

<a​aron:cypherstack.com> We still have doubts based on a significant lack of clarity and some of the "base" results

<r​ucknium:monero.social> When the full report is released I may have to figure out if "doubts" is a diplomatic way to say that the soundness proofs are not clearly safe.

<r​ucknium:monero.social> "Base" = lemmas in the paper?

<a​aron:cypherstack.com> We haven't identified any particular exploits, if that's what you mean.

<a​aron:cypherstack.com> Generally, the idea is that the proof should convince the reader about the correctness of its reasoning. I will certainly say that several of the proofs in the preprint did not do that for this reader.

<r​ucknium:monero.social> That's not really what I mean, but a conjecture is still unproven even if no counterexamples have been found yet.

<a​aron:cypherstack.com> For some we were able to determine the actual intent and make corrections, but for others we were not.

<a​aron:cypherstack.com> Can you be more specific?

<a​aron:cypherstack.com> I do want to be clear that "this proof does not appear to substantiate the claims to our satisfaction" is certainly not the same as "the protocol under question is definitively unsafe"

<r​ucknium:monero.social> I think you answered my question with "Generally...". Thanks.

<a​aron:cypherstack.com> I was particularly concerned with the lack of clarity around a key soundness proof

<d​iego:cypherstack.com> There is a certain amount of diplomacy here, yes. :P

<a​aron:cypherstack.com> The idea is that the proof needs to build an algorithm called an extractor that has to do very specific things

<a​aron:cypherstack.com> In this case, the proof is extremely informal about this, without detail that convinces me of its construction

<a​aron:cypherstack.com> You will also find the word "presumably" in many places in the report, where we had to make assumptions about intent

<a​aron:cypherstack.com> I'm certainly not trying to be wishy-washy here. Just professional and accurate.

This all also seems to confirm something you mentioned last time, that things are considerably more complex compared to "+". IMHO, that doesn't help either

<a​aron:cypherstack.com> Yeah, the second "+" in the name carries a _lot_ of weight

We will already have a quite a serious step up in complexity with Seraphis and Jamtis.

<a​rticmine:monero.social> What are the advantages of ++ in terms of size and verification time?

<a​aron:cypherstack.com> The authors claim single-proof verification time with BP++ (over secp256k1) at 0.840 ms

<a​aron:cypherstack.com> whereas for BP over secp256k1 they saw 2.223 ms

<a​aron:cypherstack.com> (There are other numbers for other implementations, but those are really hard to compare fairly)

<a​aron:cypherstack.com> They also get single proofs at 416 bytes, compared to BP+ at 576 bytes or so

<a​aron:cypherstack.com> I do have one question that wasn't directly addressed. Typically such a review will issue findings and corrections as appropriate, which is what our report does. But it's obviously not a pass/fail sort of thing (though I have seen this before...)

<a​aron:cypherstack.com> Is the community looking for something more cut and dry as a top-level sort of thing?

<r​ucknium:monero.social> IMHO, cryptographers on the MRL end should give their interpretation of the final report instead of you needing to summarize it like that. I think I caused some confusion by saying "unsafe". I meant that something that is not definitely proven is not safe enough for Monero mainnet, even if it is not definitely proven wrong in the mathematics meaning.

<r​ucknium:monero.social> In other words I don't think you need to put FAIL in bold red letters at the top. Or PASS in bold green as needed.

<a​aron:cypherstack.com> Rucknium: I would agree that Monero-specific interpretation should certainly be left up to community researchers

<a​aron:cypherstack.com> And no, there will not be a big red or green stamp at the top =p

<a​rticmine:monero.social> This can be a tough question. In my view we are looking at an incremental improvement vs what I see as serious concerns regarding the proofs themselves.

<a​aron:cypherstack.com> (I saw one audit that did issue a pass/fail, and was immediately suspicious...)

<a​aron:cypherstack.com> And anyone who has gone through journal- or conference-style review surely knows that three different reviewers may have three wildly different conclusions

"I will certainly say that several of the proofs in the preprint did not [convince the reader about the correctness of its reasoning] for this reader" -> I think this is a reasonable conclusion and a report that backs up that conclusion in its contents would be satisfactory, rather than a PASS/FAIL

<a​rticmine:monero.social> I agree this is not a pass / fail question, but the benefit of doubt has to be with the reader and auditor not the prover.

<a​rticmine:monero.social> In the case of doubt or concerns it becomes a fail

<a​rticmine:monero.social> For inclusion into the Monero code

<a​aron:cypherstack.com> We do certainly hope that the authors can find value in the report too, to make corrections and improvements as they see fit

<r​euben:firo.org> What about BP+ verification vs BP?

<r​ucknium:monero.social> I agree. The stakes are very high. Any real doubts would mean not adopting it into Monero mainnet IMHO.

<a​aron:cypherstack.com> Reuben: they include numbers for that, but it's with different implementations over different curves. Not comparable IMO

<r​euben:firo.org> 🥲

<a​aron:cypherstack.com> In terms of raw numbers, I can say that at least one BP+ implementation (in Rust over Ristretto) is likely comparable to their BP++ implementation. But I haven't tested their benchmark on the same machine

<a​aron:cypherstack.com> Unless you're using the same curve library and fair optimizations between implementations, it's a crapshoot to make claims about raw numbers

+1 based on that conclusion, it would seem ideal next step would be to share the final report with the authors and see if able to fill in the gaps / beef up the proofs

<a​aron:cypherstack.com> Oh Reuben maybe I misread... you weren't asking about BP++ at all?

<a​rticmine:monero.social> Yes. I agree.

<a​aron:cypherstack.com> @jberman: How would the community like that handled?

<d​iego:cypherstack.com> It's always been the plan to release the report publicly and let the original authors know about the report. But we don't want to send and wait for their response before delivery. We also don't care to dictate how the whole process is handled.

<r​euben:firo.org> Was just thinking if BP++ isn't a significant improvement over BP+ then I mean with the risks of BP++ doesn't seem to justify pushing too hard into it

<a​aron:cypherstack.com> Oh OK, you were asking about BP++ vs. BP+. Got it

<a​aron:cypherstack.com> (too many BPs floating around...)

<r​euben:firo.org> FCMP currently uses BP only yes ?

<r​ucknium:monero.social> "It's always been the plan to release the report publicly and let the original authors know about the report." This sounds fine to me. There is no need to wait for a response from the original authors. You've already contacted them about a few things anyway IIRC.

<r​euben:firo.org> Forgot if we found a solution

<a​aron:cypherstack.com> Yes. To my knowledge, no one has used BP+ or BP++ arithmetic circuit modifications for that

original plan laid out by @diego makes sense. I think we can assess next steps after that point

<a​aron:cypherstack.com> Rucknium: We contacted them about a couple of initial findings, but nothing beyond that. We hadn't heard back from our latest question

I see things similarly to jberman

<a​aron:cypherstack.com> As a courtesy, we would certainly like to inform them directly to let them know about the report and where to read it

<a​rticmine:monero.social> In my opinion this comes down to the allocation of resources. For example are we better off coding parallel processing and graphics processing with the existing proofs to get the verification time advantage?

<a​rticmine:monero.social> I know I am thinking as an engineer and not a mathematician.

<a​aron:cypherstack.com> Development is likely to be quite complex compared to BP or BP+

<a​aron:cypherstack.com> For BP and BP+, range proofs work differently than the more general arithmetic circuit proofs they also support

<a​aron:cypherstack.com> For BP++, you basically need the full arithmetic circuit proving system implemented

<r​ucknium:monero.social> IMHO the recent suspected spam has exposed a lot of cracks in the network that better engineering could patch. And some cracks that need better math or something.

<a​aron:cypherstack.com> And that doesn't account for optimizations needed to presumably get the numbers they saw

<a​aron:cypherstack.com> To be fair, they do have a reference implementation in C over secp256k1

<a​aron:cypherstack.com> Regardless of the report findings, I think it's safe to say that a complete from-scratch implementation would pose nontrivial engineering risk in itself

Yeah, we definitely won't run out of important work soon, so with these shadows of doubts over BP++ ...

<a​aron:cypherstack.com> I'm certainly not trying to influence any decisions here. Just wanted to provide my best assessment

<a​rticmine:monero.social> For a marginal benefit

<a​aron:cypherstack.com> Other reviewers may have different conclusions

<a​aron:cypherstack.com> ArticMine: the proof size difference is impressive

<a​aron:cypherstack.com> From a verification perspective, tough call. Batch verification is already pretty snappy, and it's not clear at what point the returns from that become diminished compared to the rest of transaction/network operations

<a​aron:cypherstack.com> Anyway, it sounds like the final report should be publicly delivered to the community? And then we can inform the authors directly as a professional courtesy?

<d​iego:cypherstack.com> Cool. Can we move on to the next thing for Cypher Stack?

<r​ucknium:monero.social> Aaron Feickert: Thank you! Tremendous work. Extremely useful.

Yep, that sounds great to me

+1

<a​aron:cypherstack.com> Thanks! Sorry to take up so much meeting time on it

<r​ucknium:monero.social> Diego Salazar: Yes, you can move to the next CypherStack item.

<d​iego:cypherstack.com> Thanks.

<d​iego:cypherstack.com> Given that we're almost done with this proposal, I'd like to discuss the possibility of the next one.

<a​aron:cypherstack.com> BP#

<d​iego:cypherstack.com> We've been asked by a few MRL individuals what it would mean to do a Seraphis review.

<d​iego:cypherstack.com> Before we give a quote and time estimate, I'd like to discuss with you all hear what exactly you'd want out of such a review.

<d​iego:cypherstack.com> Are we looking to formalize Seraphis? A holistic review?

Uh, I think the word "exactly" here will prove to be tough :)

<r​ucknium:monero.social> Can jberman give the current status of the Seraphis paper?

<r​ucknium:monero.social> The critical cryptography is Seraphis needs to be proven. I don't know what the journey there looks like.

<r​ucknium:monero.social> The last thing I heard about the paper is that it is missing a few proofs at least. The entity that writes the proofs cannot be the one who peer reviews the proofs IMHO.

<a​aron:cypherstack.com> It had previously been my recommendation that a holistic review is more likely to provide practical benefit and return than a more exploratory formalization

<r​ucknium:monero.social> So holistic review means basically figuring out where it needs work and maybe a plan to get it to finalization?

<r​ucknium:monero.social> If the cryptographers in MRL want Seraphis to move forward, they need to move it forward. I'm not the best person to move it forward.

<a​aron:cypherstack.com> It would mean considering its security properties more informally, but from a more practical perspective than a strict security model and formalization

<r​ucknium:monero.social> ^ This is not aimed at CypherStack, but at other MRL people

<a​aron:cypherstack.com> Seeing as developing a security model after the fact (or trying to use an existing one) may not prove fruitful, and still may not capture all practical risks and threats

Could it be said that with a "holistic review" you will "read and think the whole thing through, to find any possible problems"?

<r​ucknium:monero.social> Are you familiar with the paper that formalized Monero's current security model?

<a​aron:cypherstack.com> One reason for my recommendation is also that the worst-case scenario for a formalization engagement is "we were not able to develop a security model that is amenable to the design", whereas the worst-case scenario for a holistic review is "here are findings and recommendations"

<a​aron:cypherstack.com> I recall seeing it, but at the time hadn't reviewed it in detail

<a​aron:cypherstack.com> Trying to hunt it down...

<r​ucknium:monero.social> eprint.iacr.org/2023/321 "A Holistic Security Analysis of Monero Transactions" . It even has "holistic" in the name :P

<a​aron:cypherstack.com> Cypher Stack has been engaged in the past to do non-security-model protocol reviews. And we've certainly provided findings.

<r​ucknium:monero.social> AFAIK it will appear in EUROCRYPT 2024

<a​aron:cypherstack.com> Rucknium: that's it, thanks

<a​aron:cypherstack.com> Rucknium: keep in mind that AFAIK, reviewers are not required to even read security proofs for that conference

<v​tnerd:monero.social> I forgot about the meeting, sorry. Still working on LWS remote account scanning

<r​ucknium:monero.social> And this paper is huge anyway

<r​ucknium:monero.social> 87 pages

<a​aron:cypherstack.com> There are some aspects of its security definitions that would need modification for Seraphis

<a​aron:cypherstack.com> and are fairly specific to Monero's RingCT

<r​ucknium:monero.social> rbrunner: IMHO you or someone you are working with needs to guide the way on Seraphis formalization. I will not push it forward since it is out of my area.

@rucknium the Seraphis paper sketches a rough informal security model in section 1.2 that's light on details and the Seraphis tx protocol does not have formal security proofs

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

A holistic review with an eye toward laying groundwork for a formalization of the protocol I think seems a solid route based on @aaron 's recommendations

I am pretty innocent regarding all things crypto, I wouldn't put much hope that I can really advance something here, even if I wanted

<r​ucknium:monero.social> I suggested you since you are semi-official Seraphis project manager.

<r​euben:firo.org> If a way is not found to formalize security, what then? Afaik some aspects of seraphis are hard to prove

I see. Yeah, for dev work, mostly, at least so far

<r​ucknium:monero.social> If the Seraphis programmers want Seraphis on mainnet, they must get the math arranged.

<a​aron:cypherstack.com> One example of where formalization often comes up short is something like the mempool... this bit an initial iteration of the Spark design, whose security model didn't capture it. I _think_ this linked preprint similarly wouldn't capture it (but am not 100% sure on this)

<a​aron:cypherstack.com> @jberman: Right, an initial holistic review could certainly be done with an eye for future formalization

<r​ucknium:monero.social> Probably mempool is out of scope IMHO.

<a​aron:cypherstack.com> Rucknium: ah, I'd disagree. That's how you get things like certain types of burning attacks

<d​iego:cypherstack.com> Alright, would you like us to draft up a proposal for a holistic review? All things considered, it seems the logical first step on this Seraphis journey.

<a​aron:cypherstack.com> and is why protocols like Seraphis and Spark need to account for different structural components in transactions

<r​ucknium:monero.social> Aaron Feickert: Thanks. I didn't think of that.

I think a first rough estimate how such a "holistic review" might cost would help to decide.

<a​aron:cypherstack.com> Anyway, I would have a few questions regarding scope. Namely the following

<s​yntheticbird:monero.social> Lacking knowledge but since each methods have requirements for seraphis to be mainnet. Having a holostic and formal review seems like a necessity

<a​aron:cypherstack.com> 1. There are two papers on Seraphis: a general structure one, and an implementation-focused one that instantiates the protocol. Which should be in scope?

<a​aron:cypherstack.com> 2. I know JAMTIS has been under design for a while, and it's included in Chapter 8 of the implementation paper. Is it in scope?

<a​aron:cypherstack.com> 3. There are "information proofs" useful for proving various things about addresses and such to a third party, and they're in Appendix A of the implementation paper. Are they in scope?

<a​aron:cypherstack.com> (these are not security proofs)

<a​aron:cypherstack.com> 4. Are there other specific or general scope items we should consider?

The general structure paper is the paper in scope (the implementation-focused one is there as a helpful resource)

that should answer all 4 q's :)

<a​aron:cypherstack.com> @jberman: Am I understanding right? "Implementing Seraphis" is _not_ in scope?

<a​aron:cypherstack.com> If anything, I would have thought the opposite for a holistic review

<d​iego:cypherstack.com> Perhaps one followed by the other?

hmm, a holistic review of the first paper I don't think should take too long in that case

<a​aron:cypherstack.com> True

<a​aron:cypherstack.com> Findings from it could be relevant to the implementation (if in fact the implementation is a proper instantiation of the general design)

<a​aron:cypherstack.com> But it obviously wouldn't capture anything specific to the instantiation, like JAMTIS or other particular components

<d​iego:cypherstack.com> I think doing things in a stepwise fashion gives the community the most bang for its buck

<a​aron:cypherstack.com> That's fair. But any reason not to jump right to the implementation paper?

<a​aron:cypherstack.com> It's much closer to what would actually go into a deployed implementation

<d​iego:cypherstack.com> The odds are very small, but if something is found in the general paper that makes the community rethink Seraphis entirely, it's helpful that they haven't already raised the funds for the instantiation paper

<a​aron:cypherstack.com> @Diego that's fair

<r​euben:firo.org> Isn't it incomplete just for the general design? Since there are various ways to instantiate seraphis with different security implications no ?

<r​euben:firo.org> Also assuming this doesn't include FCMPs either ?

<a​aron:cypherstack.com> @Reuben: Yeah, any specific instantiation would have security and design aspects specific to it

<a​aron:cypherstack.com> JAMTIS is probably the biggest example

<r​euben:firo.org> Would it also affect security proofs ? Different instantiations have different proofs too no ?

<a​aron:cypherstack.com> The best way to look at it would be that different components (_e.g._ a range proof, a membership proof) need particular security properties proven for any particular choice

<a​aron:cypherstack.com> But ideally you build the overall security model such that things are as plug-and-play as possible

<a​aron:cypherstack.com> So you get something like "assume a range proving system with security properties X, Y, Z"

I figure a review of the first paper could clarify areas in which it needs strengthening, and would be specifically helpful in laying a cleaner path toward formalization and structuring a security model

<a​aron:cypherstack.com> You still need to pick a range proving system and prove those properties

<a​aron:cypherstack.com> @jberman: Although I do wonder how many findings could be addressed simply by "read the implementation paper" =p

<d​iego:cypherstack.com> Alright then. Aaron Feickert we'll first make a proposal for the first paper.

<a​aron:cypherstack.com> Anyway, we can certainly do an initial review of just the general design paper

<d​iego:cypherstack.com> And then explore further options once that's complete.

<a​aron:cypherstack.com> It does provide a quicker stopping point in the event of major findings

<a​aron:cypherstack.com> But the paper is significantly general that, TBH, I would be surprised (as @Diego notes) if this were the case

<a​aron:cypherstack.com> and it's far more likely that relevant findings would exist for the implementation paper, where the nuts and bolts live

<a​aron:cypherstack.com> Just want to make sure that expectations are set appropriately, given the structure of the papers

<d​iego:cypherstack.com> Alright. Then I think that we here at Cypher Stack have our marching orders.

I figure the first paper would be the first thing to review before reviewing the implementation paper anyway

<a​aron:cypherstack.com> I think the best way to look at it would be the following

<a​aron:cypherstack.com> A "positive review" of the first paper could basically say "there exist Seraphis instantiations that are likely secure"

<a​aron:cypherstack.com> Whereas a "negative review" could basically say "no Seraphis instantiation meets this informal security goal"

<a​aron:cypherstack.com> Any more specific conclusions would depend on the implementation paper, which could certainly be a follow-up engagement that I'd be excited to do :D

<a​aron:cypherstack.com> So I'll get information to @Diego for a proposal ASAP

<d​iego:cypherstack.com> Great! Nothing else for us then?

<r​ucknium:monero.social> Thank you, Diego Salazar and Aaron Feickert . Please put suggested milestones in the proposal if you want them.

<a​aron:cypherstack.com> Thanks everyone

sounding reasonable to me

<a​rticmine:monero.social> Thanks everyone

<r​ucknium:monero.social> We are past the hour. The suspected spam is still a topic: bitinfocharts.com/comparison/monero-transactions.html#3m

<r​ucknium:monero.social> I will just post a few more plots. The spam looks like it stopped recently. May be temporary. So, mean effective ring size is rising: github.com/Rucknium/misc-research/b…s/empirical-effective-ring-size.png

<r​ucknium:monero.social> I compared current suspected spam with the Chervinski et al. (2021) simulations: github.com/Rucknium/misc-research/b…ffective-ring-size-binomial-pmf.png

<r​ucknium:monero.social> There are more favorable parameters now (higher ring size and lower spam share of outputs), so less than 1% of rings have an effective ring size of 1. The Chervinski simulation had the share of rings with effective ring size one at 12%.

<r​ucknium:monero.social> Chervinski also did a chain reaction analysis, which increased the effectiveness of the attack a little: github.com/Rucknium/misc-research/b…mages/chervinski-chain-reaction.png

<r​ucknium:monero.social> Mean delay to first confirmation from the mempool archive data: github.com/Rucknium/misc-research/b…s/mean-delay-first-confirmation.png

<r​ucknium:monero.social> Mostly below 15 minutes except for two periods that increased to 2+ hours

<r​ucknium:monero.social> Input/Output tx types that show 1in/2out increased on March 4, but other types did not: github.com/Rucknium/misc-research/b…df/images/in-out-tx-type-volume.png

<r​ucknium:monero.social> Fee tiers. More non-spam txs paid the 2nd fee tier after the spam started: github.com/Rucknium/misc-research/b…are-tx-in-fee-tier-spam-removed.png

<a​rticmine:monero.social> ... but the spam stayed at the low fee tier?

<r​ucknium:monero.social> Two ways to look at the data. Maybe all spam was at 20 nanoneros/byte. But there was a burst of 320 nanoneros/byte (3rd tier) on March 12-13 that may have been the spammer switching tiers: github.com/Rucknium/misc-research/b…es/share-tx-in-fee-tier-all-txs.png

<r​ucknium:monero.social> There was also a burst of 320 nanonero/byte 1in/2out in the last day or two before the spammed appeared to stop.

<a​rticmine:monero.social> This is very helpful

<r​ucknium:monero.social> We don't know the budget of the suspected spammer. Maybe they can go to 320 nanoneros/byte. That level would stop txs from the GUI/CLI using the auto fee level from confirming since auto only move from the 1st tier (20) to the 2nd (80).

<a​rticmine:monero.social> I am also trying to understand the psychology of both the ham and the soam

<r​ucknium:monero.social> I have two sets of analysis. One assuming only 80 nanoneros/byte 1in/2out are spam. The other assuming both 20 and 320 nanoneros/byte 1in/2out are spam.

<a​rticmine:monero.social> If as I suspect the spammer is testing the waters then moving the ham to tier 2 would force the spam to tier 3

<r​ucknium:monero.social> The 320 nanoneros/byte could be a central service that tried to get its txs confirmed quickly, too.

<a​rticmine:monero.social> ... but primarily 1/2?

<r​ucknium:monero.social> But I doubt that some large number of ordinary users in unison decided to switch to 320 for a day or two and then switch back.

<a​rticmine:monero.social> I agree given the past behavior of the ham

<r​ucknium:monero.social> Yes. When I use the broad definition of spam, I still use the 1in/2out definition. Just increase the criteria to include the 320 fee level, too. Actually, it is the level of txs that we observe minus the pre-spam "normal" volume of 1in/2out 320/byte txs.

<r​ucknium:monero.social> Figuring out if 320 is spam is important to anticipate if increasing the fee may have a large effect on the spam. We don't know much about the suspected spammer.

<a​rticmine:monero.social> I suspect a BS company testing the waters., as a possible if not likely candidate

<r​ucknium:monero.social> And even if this spammer would respond to a fee increase, maybe the next one would have a lower response.

<a​rticmine:monero.social> My take is that a ring size increase combined with a fee increase could deter this. The ultimate deterrent is FCMP.

<a​rticmine:monero.social> This brings me to my next question. Do we have a good estimate of a 2/2 tx under FCMP?

<a​rticmine:monero.social> At least a ballpark. Say between 5000 and 6000 bytes?

<r​ucknium:monero.social> The last I heard was probably the same as you. 5.5kB for 2/2, estimated by kayabanerve in June 2023: monero-project/research-lab #100#issuecomment-1609536076

aaron thanks for your work and clarity on the way forward with the Seraphis papers. I honestly have no input beyond 'here are the papers I wrote as best I could'.

<a​rticmine:monero.social> Thanks. I have to read this thread carefully, but from what I see a 400000 minimum penalty free zone combined with a 8000 byte reference transaction size will do the trick.

<a​rticmine:monero.social> This will mean a 4x increase in fees for a 2% minimum growth rate for the short term median. With a dynamic suggested surge this means a 16x increase in fees

<a​rticmine:monero.social> It would also support ring 40 with the current proofs and tighten the number of transactions in the minimum penalty free zone.

<a​rticmine:monero.social> As for quadratic fee scaling this can be replaced with a one time additional fee level of 1/4 the minimum fee once the sanity median reaches a predetermined level 1600000 bytes or higher

<r​ucknium:monero.social> I'm not familiar enough with the block size scaling model to comment on the dynamic rules. Ring size 40 seems to provide a good safety margin. A modest fee increase seems OK.

<r​ucknium:monero.social> The Chervinski et al. (2021) simulation had high attack effectiveness because 1) Ring size was lower (obviously), but just as important (2) The spam assumptions they had only allowed the spam to grow to the 300kB block size. Because the non-spam txs filled less of the 300kB block than now in March 2024, Chervinski filled the rest of the block with a higher share of black marbles than we have now

<r​ucknium:monero.social> Of course the spammer can push up the block size gradually. That hasn't happened yet, above 400kB at least.

<r​ucknium:monero.social> IMHO more research is needed on fee prediction. The dynamic scaling requires full blocks, which usually requires mempool congestion. As much as possible, users should be able to avoid long waits if they are willing to pay for that convenience.

<r​ucknium:monero.social> This goes for congestion due to spam and "real" usage growth.

<r​ucknium:monero.social> And users cannot change their bid for block space. There is no replace-by-fee nor child-pays-for-parent in Monero. So users just have to wait in the queue if they don't know that the mempool is congested and they choose a low fee.

<d​ave.jp:matrix.org> Rucknium: how many txs/day would attacker need to lower the effective ringsize to 5-6 if we increase ringsize to 40 and honest txs is average 10k ?

<d​ave.jp:matrix.org> And how much they are expected to pay in case we bump fees 5x or 10x

<d​ave.jp:matrix.org> And how much they are expected to pay in fees, in case we bump fees 5x or 10x

<r​ucknium:monero.social> dave.jp: This says that blocks would have to be 1-1.25MB to lower effective ring size to 5-6 when nominal ring size is 40, assuming current "real" transaction volume: github.com/Rucknium/misc-research/b…ted-effective-ring-size-log-log.png

<a​rticmine:monero.social> They currently can but the evidence is that psychologically they don't. At least initially.

<a​rticmine:monero.social> Dynamically changing the suggested fee based upon the transaction pool size together with increasing the initial default growth rate will mitigate this

<r​ucknium:monero.social> Let me see if I can quickly get the exact number of spam txs per block

<a​rticmine:monero.social> Also my proposal of increasing the default growth rate from 1% to 2% will roughly reduce the number of transactions in the minimum penalty free zone to 1/2

<r​ucknium:monero.social> What I see is that to get effective ring size to 5.5 when nominal ring size is 40, there will be 403 black marbles in each block (88.4% of all outputs in a block). About 290,000 spam txs per day. That's with the 4 week pre-spam txs considered as a "normal" level of real user txs

<a​rticmine:monero.social> So combining this with halving the penalty free zone interns it the number of transactions this puts our spammer deep into the penalty

<a​rticmine:monero.social> In terms of transactions

<r​ucknium:monero.social> `(total_block_kb - real_tx_kn) * kb_to_byte * lowest_fee_tier_in_nanoneros * convert_nanoneros_to_XMR * blocks_per_hour * hours_in_day * higher_fee_factor`

<r​ucknium:monero.social> `(1205.595 - 208) * 1000 * 20 * 0.000000001 * 30 * 24 * 10 = 143.7 XMR/day` to send spam at that level

<a​rticmine:monero.social> What was it costing the spammer now

<a​rticmine:monero.social> Per day

<r​ucknium:monero.social> 2.68 XMR/day, assuming the spam is the 1/2 20 nanonero/byte.

<r​ucknium:monero.social> 3.53 XMR/day, assuming the spam is the 1/2 20 _and_ 320 nanonero/byte.

<r​ucknium:monero.social> But the 320 nanonero/byte suspected spam was low and only happened a couple of days.

<a​rticmine:monero.social> I believe your figure of 143 XMR per day is in the ballpark. The issue is surge vs maintenance in the penalty zone

<a​rticmine:monero.social> The spammer can maintain for less but if the spam stops for 100 blocks then the spammer has to surge the short term median again. There is where the cost is

<d​ave.jp:matrix.org> How much less if they limit it ?

<a​rticmine:monero.social> To what?

<d​ave.jp:matrix.org> Sorry I misunderstood, so ~140xmr if they continue the spam and would cost more if they stop for 100blocks

<d​ave.jp:matrix.org> This looks good on paper, any idea when we go ahead with this fork ? do we wait for 6month or can expedite it.

<a​rticmine:monero.social> It is more like 80 XMR for maintenance but each drop would cost the spammer up 480 XMR

<a​rticmine:monero.social> The latter is the hard part for a spammer

<a​rticmine:monero.social> This is why these kinds of spammers tend to shy away from the penalty

<a​rticmine:monero.social> Well I have to develop the algorithms. Then it has to be coded. We have to get consensus, give notice etc

<a​rticmine:monero.social> I will do my best to get this started

<d​ave.jp:matrix.org> Thanks articmine, looking forward to it.

<b​lurt4949:matrix.org> Late to the party, but it's maybe worth mentioning that 2/2 FCMP transactions could be <4kb with proof aggregation, if I'm interpreting kayabanerve correctly. AFAICT it's similar to BP(+) aggregation, just on the input side rather than the output side. I haven't really heard of this before though. monero-project/research-lab #100#issuecomment-1609586250

<d​ave.jp:matrix.org> Rucknium: anything to change in decoy selection to get better effective ring size even if they spam and fill recent outputs ?

<r​ucknium:monero.social> IMHO automatic spam detection is too difficult. An adversary can see the rules for spam detection in the wallet source code and just form the spam to fall outside of the rules.

<a​lex:agoradesk.com> ArticMine: assuming that the black marble attack can be combatted without a hard fork prior to FCMP, would you still support the ring bump hard fork?

<r​ucknium:monero.social> New version of my black marble flooding analysis: github.com/Rucknium/misc-research/b…d/pdf/monero-black-marble-flood.pdf

<r​ucknium:monero.social> I added sections "Chain reaction graph attacks", "Transaction confirmation delay", "Real user fee behavior", and "Evidence for and against the spam hypothesis"

<a​rticmine:monero.social> Yes.

<a​rticmine:monero.social> This is the second time this kind of attack has occurred recently and yes the first one fizzled out this one may also fizzle out.

<a​rticmine:monero.social> This type of attack looks attractive and when the spammer figures out the real cost tends to stop. Still it makes sense to harden Monero against this kind of thing. Furthermore once this HF is in place scaling and fees would support FCMP. There is also a good case to make the scaling change now when the transaction rates are low. For example transaction rates could increase sharpl<clipped messag

<a​rticmine:monero.social> y before FCMP making the scaling change much harder on the network then.

<a​lex:agoradesk.com> Fair.