Monero Research Lab Meeting - Wed 29 May 2024, 17:00 UTC about meta HOT 1 CLOSED

< r​ucknium:monero.social > Meeting time! #1015

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

< v​tnerd:monero.social > Hi

< rbrunner > Hello

< a​rticmine:monero.social > Hi

< c​haser:monero.social > hello

< 0​xfffc:monero.social > Hi

< jberman > waves

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

< u​ntraceable:monero.social > hi

< r​ucknium:monero.social > me: Finished the first draft of "Defeating a Black Marble Flood Against Monero: Best Options for Ring Size and Transaction Fee": https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-optimal-fee-ring-size.pdf

< v​tnerd:monero.social > Me: completed LWS remote scanning, looking at how to stress test it to ensure its faster than local only

< jberman > me: set up fcmp lmdb tree implementation, implemented grow_tree in the db + tests, now working on trim_tree and still ironing out the implementation

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

< r​ucknium:monero.social > My analysis ^ suggests that a large increase in ring size and a modest increase in fee/byte are good ways to deter a black marble flood or at least limit its impact on effective ring size. We were unsure of how quickly FCMP research and implementation would be moving, but it seems to be on schedule for the optimistic timeline. So a hard fork to increase ring size and/or fee might not make sense.

< r​ucknium:monero.social > Did chaser have any thoughts on the document?

< c​haser:monero.social > yes, just a sec. what is the latest prospective timeline for FCMP deployment?

< r​ucknium:monero.social > jberman: is the 1.5 years estimate to mainnet the best guess now?

< selsta > I'm going to repeat what I said a couple days ago in a different channel, a large increase to the ring size is going to risk the stability of the network if we don't fix the known daemon inefficiency bugs first. We currently have issues with nodes falling behind and nodes running out of memory during high transaction volume.

< r​ucknium:monero.social > selsta: How would the Monero Project accomplish the inefficiency fix?

< c​haser:monero.social > selsta: you're talking about the many-input transaction stress, right?

< jberman > I'd say we're on target for fcmp's and now it's ~1.3 years to mainnet maybe faster

< r​ucknium:monero.social > I agree with you that monerod has not performed as well as hoped with the recent tx volumes

< a​rticmine:monero.social > So we have to make the daemon inefficiency part of a HF for larger ring size

< selsta > rucknium: we need devs to find a way to reproduce the issue in a local test setting and then work on a fix

< jberman > I think selsta's assessment is fair there also. We need hands to focus on improving daemon inefficiencies

< r​ucknium:monero.social > spackle wanted to run a benchtest network. Maybe he could help organize something.

< selsta > the problem is that some bugs require a large amount of connections to reproduce which makes it more difficult in a local network

< r​ucknium:monero.social > I would be willing to help, too.

< a​rticmine:monero.social > As far as the scaling design a ring 64 or 60 can be accommodated with a 4x increase in fees.

< a​rticmine:monero.social > The fee increase can be optionally reversed with FCMP

< selsta > c​haser: many-input tx can trigger this out of memory issue, yes

< r​ucknium:monero.social > Would setting up a testnet with many cheap VPSes be a good way to start testing?

< a​rticmine:monero.social > We would use a 400000 / 800000 byte reference transaction weight. Depending on the fees

< c​haser:monero.social > selsta: I see. do you also imply there are also other things that can trigger it?

< selsta > it might make more sense to edit the source code in a way that simulates a lot of connections, instead of setting up a lot of VPS

< rbrunner > Sounds like a good idea

< spackle > For what it is worth, I ran a private testnet on a single machine and loaded the mempool with transactions (over 500MB). I did not see any unusually large memory or cpu burden in that circumstance.

< selsta > this is the github issue for the out of memory issue: monero-project/monero#9317

< jberman > I would probably start by spinning up many local testnet daemons and stress testing, instead of going VPS route first

< a​rticmine:monero.social > I can proceed with the scaling design to accommodate both up to ring 64 and a future FCMP

< selsta > the current theory is that the fluff queue is making a copy of each transaction for each network peer, which can cause a memory spike if a lot of large transactions are submitted at once

< jberman > I think it's a reasonable theory that should be reproducible

< r​ucknium:monero.social > In my statistical analysis on tx verification performance, it seemed that verifying one byte of input data took 150% longer than verifying one byte of output data. In other words, if an adversary wanted to get the maximum CPU usage for their XMR budget, they would create lots of inputs.

< rbrunner > It says something about the complexity of the code if such a theory stays a theory for some longer time :)

< r​ucknium:monero.social > I don't know if my tentative statistical results comparing input and output verification time (not explicitly in the paper) are consistent with what's supposed to be happening with the cryptography in theory.

< a​rticmine:monero.social > One question regarding daemon effectively. Can we minimize the number of times the tx proofs are transmitted. So only once between tx relay and block relay?

< jberman > yes: monero-project/monero#9334

< r​ucknium:monero.social > If the bottleneck is tx propagation to so many nodes, then boog900 's proposal may help a lot: "Change how transactions are broadcasted to significantly reduce P2P bandwidth usage" monero-project/monero#9334

< selsta > the other bug is that nodes can fall behind, most of the times it happens during RPC traffic. it's less critical but still annoying for users that rely on remote nodes.

< selsta > in my opinion both of these bugs would be critical to fix before we can increase the ring size significantly

< a​rticmine:monero.social > So if I understand correctly the same approach can be used for mined blocks

< rbrunner > And well, it's possible that much larger rings would trigger problems that we are not yet aware at all

< c​haser:monero.social > so my understanding is the memory issue seems to be regardless of whether the transaction is large because of inputs of outputs. is that right?

< r​ucknium:monero.social > Ok. Let's make a task force or something. spackle could lead. selsta can answer questions. 0xfffc could help with database things. Maybe boog900 , rbrunner7 , and vtnerd could be involved.

< v​tnerd:monero.social > That proposal will probably have minimal effects on tx propagation time, unless some of the timers are removed

< 0​xfffc:monero.social > I am onboard.

< jberman > the rw lock was the stab at the solution to nodes falling behind, wondering how that's going / if that issue was reproduced: monero-project/monero#9181

< selsta > jberman: problem is that we are not able to reproduce the issue locally

< selsta > so unclear if the rw lock helps

< 0​xfffc:monero.social > It is overall in good shape, though there is a bug that sgp reported. Causing speed up 20% initially, but after a while causing slowdown 20%. But during my work on it I realize need a performance benchmark suite.

< 0​xfffc:monero.social > Exactly as selsta explained it.

< jberman > got it

< 0​xfffc:monero.social > Performance benchmark suite will basically a best solution. Spin up multiple node private testnet, then run your scenario. And evaluate the results.

< 0​xfffc:monero.social > If we had that performance suite, rw-lock fix would be trivial and much simpler work.

< 0​xfffc:monero.social > I took stab at the performance suite. (Will send the link) but had to go for a leave for personal reasons.

< 0​xfffc:monero.social > Reporting to community: I have NOT abandoned the work, not I forgot. I just had to fix a few personal issues. Hopefully will be working full time on it from Sunday June 2nd.

< r​ucknium:monero.social > Thanks, 0xfffc . Do you want to try to organize some things together to get a benchmark testnet running?

< spackle > I am happy to do what I can, though I will openly admit that I lack the expertise of selsta/others. My thought was to run a testnet fork specifically for abuse, but if selsta can simulate many connections that may be the direct route.

< 0​xfffc:monero.social > P.S.

< 0​xfffc:monero.social > https://github.com/0xFFFC0000/benchmark-project/blob/main/benchmark_project.cpp

< 0​xfffc:monero.social > This basically manages daemon as separate processes. Eventually we want to run nodes as different daemon objects via C++ code (instead of spin up different processes)

< rbrunner > Sounds quite ambitious. And may have different performance characteristics, worst case.

< 0​xfffc:monero.social > If anyone wants to work together, I am 100% onboard. Just to make sure, I might not be able to code myself until June 2nd. (After that I will write code myself too).

< 0​xfffc:monero.social > But available to talk and share my view 24/7 on matrix until then.

< 0​xfffc:monero.social > ( code is extremely ugly. It is just a draft )

< r​ucknium:monero.social > rbrunner: That is my question about "simulating connections". How do we know we are not catching the bottlenecks if we do not have as realistic a test environment as possible?

< spackle > I can restart/publish the testnet fork I made if that is helpful. Not that forking testnet is difficult, but I do have it ready.

< 0​xfffc:monero.social > ( i took the idea from a professor paper from Imperial College London. They wrote a simulation for Bitcoin. Running different Bitcoin nodes on NS2 -network simulator- then evaluating. Will send the link to their paper here in few moments. )

< r​ucknium:monero.social > I will put this benchmark testnet idea on next week's MRL agenda to encourage progress :)

< rbrunner > Rucknium: Fair enough. But at least, with the right "trick", simulating many connections should be quite easy, unlike turning the Monero daemon into a proper C++ class that you can instantiate at will

< rbrunner > Probably ...

< r​ucknium:monero.social > Any other comments about monerod performance and black marble flood defense?

< c​haser:monero.social > tevador has an anti-spam proposal to modify the clawback such that weight-per-outputs is constant for all output counts when in=1. (monero-project/research-lab#119 (comment)). it makes one of the simplifications in Rucknium's paper more realistic, and I wonder what everyone thinks of it.

< 0​xfffc:monero.social > I agree. For the time being we can simulate this without going into the whole simulation hassle. But honestly I am not much familiar with the connection side. But next week I can help.

< a​rticmine:monero.social > The clawback is currently at 80%

< r​ucknium:monero.social > IMHO, we could add the modified clawback to a hardfork with larger ring size. Probably it doesn't affect most users since most users never send a tx with more than 2 outputs. Some wallets don't even have the capability to send more than 2 output txs.

< a​rticmine:monero.social > I don't see much room there

< a​rticmine:monero.social > An option for large number of outputs is to require a higher minimum node relay fee

< r​ucknium:monero.social > Yes, it probably won't have a large impact. And the suspected March 2024 flooder used 2-out txs anyway, so apparently the incentive to make 16-out txs wasn't very large for them.

< a​rticmine:monero.social > For those outputs

< c​haser:monero.social > I agree, but the sentiment seems to be that monerod bottlenecks may make a larger ring size fork nonviable.

< c​haser:monero.social > that doesn't mean there won't be another actor who realizes this advantage

< spackle > I was thinking a stressnet could be added to the permanent codebase as a limited yearly network. Runs for a few months each year, starting with a unqiue pre-programmed initialization each time and rejecting blocks after a certain height.

< r​ucknium:monero.social > Unless I am missing something, the monerod bottlenecks + ring size increase only matters for "normal" non-spam tx volume. an adversary can spam to try to knock nodes offline by just creating more txs at current ring size instead of fewer txs with larger rings.

< r​ucknium:monero.social > We may have some FCMP updates

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

< c​haser:monero.social > oh, I see

< r​ucknium:monero.social > Anything to discuss about FCMP at this meeting?

< jberman > the Veridise statement of work is signed and they are onboarded

< r​ucknium:monero.social > Excellent

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

< c​haser:monero.social > I have a question about your paper: your largest ring size option (60) won out in all budget scenarios. is this a tendency that could extend beyond 60 with your current model?

< r​ucknium:monero.social > chaser: I didn't test it explicitly, but if we raise the upper constraint, I expect that an even larger ring size would be most cost-effective. The 60 upper limit was set based on some conversations here a while ago.

< c​haser:monero.social > got it, thanks

< c​haser:monero.social > also, a question to Artic: what did you mean that "I don't see much room there" (w.r.t. the clawback)?

< a​rticmine:monero.social > One question I have regarding the ring size proposal is would. 64. be optimal from the perspective of OSPEAD and binning since it is 4x the current Ring size?

< a​rticmine:monero.social > It is currently at 80% of the size gain over 2/2 tx per output

< r​ucknium:monero.social > With binning we would probably want a number that is easily divisible. At this time I don't know if we are considering binning at the same time as a hypothetical pre-FCMP hard fork. For OSPEAD, there is not specific threshold or divisibility that is better, except larger is better.

< a​rticmine:monero.social > So there isn't much more we can claw back

< r​ucknium:monero.social > chaser: I just re-ran it with the limit to ring size 200. The optimum still goes to the maximum, 200. The way to produce results in the model more in favor of a fee increase is to increase the m multiplier in the model that affects the cost of node operators. Right now it is times two the estimated storage cost for the network.

< a​rticmine:monero.social > I was considering 64 for ease of transition from 16

< a​rticmine:monero.social > For ring size

< c​haser:monero.social > I see. I don't think though that tevador's proposal necessarily needs to be construed as the clawback. you can also think of it as an additional penalty term.

< c​haser:monero.social > Rucknium thanks for checking it! good to know.

< c​haser:monero.social > 60/64 already sounds quite large though, but good to know

< rbrunner > Would this get us into FCMP tx size territory, more or less?

< r​ucknium:monero.social > With ring size 200, the time to verify a block's worth of txs during normal tx volume is about 6 seconds. That starts to become a problem. Anyway, I think most people think ring size 200 is too higher, except for gingeropolous ;P

< r​ucknium:monero.social > too high*

< c​haser:monero.social > rbrunner: definitely

< r​ucknium:monero.social > IIRC, the latest estimated from kayabanerve say that a FCMP-sized tx would be about ring size 40

< c​haser:monero.social > n=60 2/2 is ~5300 B

< c​haser:monero.social > I recall 5500 B from Kayaba for 2/2 FCMP++

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

< a​rticmine:monero.social > My understanding for FCMP 2/2 was around 3099 bytes

< a​rticmine:monero.social > 3000 bytes

< a​rticmine:monero.social > This is the latest I heard

< c​haser:monero.social > huh. I think I remembered this, is this outdated? https://libera.monerologs.net/monero-research-lab/20240402#c357039

< a​rticmine:monero.social > Yes

< spackle > The scaling algorithm massively expands the potential of the verification time issue. ArticMine: do I recall correctly that you were considering setting the surge factor to 16?

< a​rticmine:monero.social > Yes

< a​rticmine:monero.social > The verification time issue needs parallel processing

< a​rticmine:monero.social > That is the only long term solution since CPU speed is not where the gains are. The gains are in number of cores

< k​ayabanerve:monero.social > Apologies for not being present. I wrote more code regarding FCMP++s, demoed the TX modifications, and we're following up with Veridise as necessary.

< k​ayabanerve:monero.social > 2 inputs is only a few hundred bytes larger than 1 input.

from meta.