15:02:31 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in two hours
16:48:10 <m-relay> <c​haser:monero.social> Rucknium  thank you for your relentless work! I've just had time to finish the paper now, minus the appendices.
17:00:24 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/1015
17:00:32 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:00:46 <m-relay> <v​tnerd:monero.social> Hi
17:00:50 <rbrunner> Hello
17:01:08 <m-relay> <a​rticmine:monero.social> Hi
17:01:41 <m-relay> <c​haser:monero.social> hello
17:01:45 <m-relay> <0​xfffc:monero.social> Hi
17:01:50 <jberman> *waves*
17:03:12 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:03:35 <m-relay> <u​ntraceable:monero.social> hi
17:03:44 <m-relay> <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
17:03:58 <m-relay> <v​tnerd:monero.social> Me: completed LWS remote scanning, looking at how to stress test it to ensure its faster than local only
17:05:24 <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
17:06:39 <m-relay> <r​ucknium:monero.social> 3) Potential measures against a black marble attack https://github.com/monero-project/research-lab/issues/119
17:08:45 <m-relay> <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.
17:09:34 <m-relay> <r​ucknium:monero.social> Did chaser  have any thoughts on the document?
17:10:05 <m-relay> <c​haser:monero.social> yes, just a sec. what is the latest prospective timeline for FCMP deployment?
17:10:45 <m-relay> <r​ucknium:monero.social> jberman: is the 1.5 years estimate to mainnet the best guess now?
17:10:46 <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.
17:11:52 <m-relay> <r​ucknium:monero.social> selsta: How would the Monero Project accomplish the inefficiency fix?
17:12:01 <m-relay> <c​haser:monero.social> selsta: you're talking about the many-input transaction stress, right?
17:12:01 <jberman> I'd say we're on target for fcmp's and now it's ~1.3 years to mainnet maybe faster
17:12:19 <m-relay> <r​ucknium:monero.social> I agree with you that monerod has not performed as well as hoped with the recent tx volumes
17:12:44 <m-relay> <a​rticmine:monero.social> So we have to make the daemon inefficiency part of a HF for larger ring size
17:12:53 <selsta> rucknium: we need devs to find a way to reproduce the issue in a local test setting and then work on a fix
17:13:10 <jberman> I think selsta's assessment is fair there also. We need hands to focus on improving daemon inefficiencies
17:13:27 <m-relay> <r​ucknium:monero.social> spackle wanted to run a benchtest network. Maybe he could help organize something.
17:13:57 <selsta> the problem is that some bugs require a large amount of connections to reproduce which makes it more difficult in a local network
17:14:01 <m-relay> <r​ucknium:monero.social> I would be willing to help, too.
17:14:12 <m-relay> <a​rticmine:monero.social> As far as the scaling design a ring 64 or 60 can be accommodated with a 4x increase in fees.
17:14:13 <m-relay> <a​rticmine:monero.social> The fee increase can be optionally reversed with FCMP
17:14:14 <selsta> c​haser: many-input tx can trigger this out of memory issue, yes
17:15:37 <m-relay> <r​ucknium:monero.social> Would setting up a testnet with many cheap VPSes be a good way to start testing?
17:15:49 <m-relay> <a​rticmine:monero.social> We would use a 400000 / 800000 byte reference transaction weight. Depending on the fees
17:15:54 <m-relay> <c​haser:monero.social> selsta: I see. do you also imply there are also other things that can trigger it?
17:16:25 <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
17:16:51 <rbrunner> Sounds like a good idea
17:16:53 <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.
17:17:04 <selsta> this is the github issue for the out of memory issue: https://github.com/monero-project/monero/issues/9317
17:17:07 <jberman> I would probably start by spinning up many local testnet daemons and stress testing, instead of going VPS route first
17:17:23 <m-relay> <a​rticmine:monero.social> I can proceed with the scaling design to accommodate both up to ring 64 and a future FCMP
17:17:38 <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
17:18:11 <jberman> I think it's a reasonable theory that should be reproducible
17:18:11 <m-relay> <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.
17:18:16 <rbrunner> It says something about the complexity of the code if such a theory stays a theory for some longer time :)
17:19:12 <m-relay> <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.
17:19:32 <m-relay> <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?
17:20:34 <jberman> yes: https://github.com/monero-project/monero/issues/9334
17:21:06 <m-relay> <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" https://github.com/monero-project/monero/issues/9334
17:22:06 <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.
17:22:43 <selsta> in my opinion both of these bugs would be critical to fix before we can increase the ring size significantly
17:23:15 <m-relay> <a​rticmine:monero.social> So if I understand correctly the same approach can be used for mined blocks
17:23:35 <rbrunner> And well, it's possible that much larger rings would trigger problems that we are not yet aware at all
17:24:04 <m-relay> <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?
17:24:32 <m-relay> <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.
17:24:39 <m-relay> <v​tnerd:monero.social> That proposal will probably have minimal effects on tx propagation time, unless some of the timers are removed
17:25:33 <m-relay> <0​xfffc:monero.social> I am onboard.
17:26:10 <jberman> the rw lock was the stab at the solution to nodes falling behind, wondering how that's going / if that issue was reproduced: https://github.com/monero-project/monero/pull/9181
17:27:26 <selsta> jberman: problem is that we are not able to reproduce the issue locally
17:27:30 <selsta> so unclear if the rw lock helps
17:28:04 <m-relay> <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.
17:28:15 <m-relay> <0​xfffc:monero.social> Exactly as selsta explained it.
17:28:46 <jberman> got it
17:29:02 <m-relay> <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.
17:29:35 <m-relay> <0​xfffc:monero.social> If we had that performance suite, rw-lock fix would be trivial and much simpler work.
17:30:04 <m-relay> <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.
17:30:55 <m-relay> <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.
17:32:31 <m-relay> <r​ucknium:monero.social> Thanks, 0xfffc . Do you want to try to organize some things together to get a benchmark testnet running?
17:33:00 <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.
17:33:19 <m-relay> <0​xfffc:monero.social> P.S. 
17:33:21 <m-relay> <0​xfffc:monero.social> https://github.com/0xFFFC0000/benchmark-project/blob/main/benchmark_project.cpp
17:33:23 <m-relay> <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)
17:34:19 <rbrunner> Sounds quite ambitious. And may have different performance characteristics, worst case.
17:34:34 <m-relay> <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). 
17:34:35 <m-relay> <0​xfffc:monero.social> But available to talk and share my view 24/7 on matrix until then.
17:35:07 <m-relay> <0​xfffc:monero.social> ( code is extremely ugly. It is just a draft )
17:35:08 <m-relay> <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?
17:35:56 <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.
17:36:22 <m-relay> <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. )
17:37:42 <m-relay> <r​ucknium:monero.social> I will put this benchmark testnet idea on next week's MRL agenda to encourage progress :)
17:37:55 <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
17:38:13 <rbrunner> Probably ...
17:38:48 <m-relay> <r​ucknium:monero.social> Any other comments about monerod performance and black marble flood defense?
17:39:08 <m-relay> <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. (https://github.com/monero-project/research-lab/issues/119#issuecomment-2131169865). it makes one of the simplifications in Rucknium's paper more realistic, and I wonder what everyone thinks of it.
17:40:13 <m-relay> <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.
17:40:28 <m-relay> <a​rticmine:monero.social> The clawback is currently at 80%
17:40:51 <m-relay> <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.
17:40:52 <m-relay> <a​rticmine:monero.social> I don't see much room there
17:42:44 <m-relay> <a​rticmine:monero.social> An option for large number of outputs is to require a higher minimum node relay fee
17:42:48 <m-relay> <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.
17:42:57 <m-relay> <a​rticmine:monero.social> For those outputs
17:43:46 <m-relay> <c​haser:monero.social> I agree, but the sentiment seems to be that monerod bottlenecks may make a larger ring size fork nonviable.
17:44:32 <m-relay> <c​haser:monero.social> that doesn't mean there won't be another actor who realizes this advantage
17:44:59 <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.
17:45:29 <m-relay> <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.
17:46:38 <m-relay> <r​ucknium:monero.social> We may have some FCMP updates
17:46:42 <m-relay> <r​ucknium:monero.social> 4) Research Pre-Seraphis Full-Chain Membership Proofs https://www.getmonero.org/2024/04/27/fcmps.html
17:47:23 <m-relay> <c​haser:monero.social> oh, I see
17:49:07 <m-relay> <r​ucknium:monero.social> Anything to discuss about FCMP at this meeting?
17:49:52 <jberman> the Veridise statement of work is signed and they are onboarded
17:50:19 <m-relay> <r​ucknium:monero.social> Excellent
17:51:47 <m-relay> <r​ucknium:monero.social> Any other business?
17:51:51 <m-relay> <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?
17:53:00 <m-relay> <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.
17:53:29 <m-relay> <c​haser:monero.social> got it, thanks
17:54:26 <m-relay> <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)?
17:55:21 <m-relay> <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?
17:56:41 <m-relay> <a​rticmine:monero.social> It is currently at 80% of the size gain over 2/2 tx per output
17:57:11 <m-relay> <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.
17:57:42 <m-relay> <a​rticmine:monero.social> So there isn't much more we can claw back
18:00:22 <m-relay> <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.
18:00:33 <m-relay> <a​rticmine:monero.social> I was considering 64 for ease of transition from 16
18:00:49 <m-relay> <a​rticmine:monero.social> For ring size
18:01:41 <m-relay> <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.
18:02:11 <m-relay> <c​haser:monero.social> Rucknium thanks for checking it! good to know.
18:02:36 <m-relay> <c​haser:monero.social> 60/64 already sounds quite large though, but good to know
18:03:16 <rbrunner> Would this get us into FCMP tx size territory, more or less?
18:03:39 <m-relay> <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
18:04:04 <m-relay> <r​ucknium:monero.social> too high*
18:04:05 <m-relay> <c​haser:monero.social> rbrunner: definitely
18:04:48 <m-relay> <r​ucknium:monero.social> IIRC, the latest estimated from kayabanerve  say that a FCMP-sized tx would be about ring size 40
18:04:49 <m-relay> <c​haser:monero.social> n=60 2/2 is ~5300 B
18:06:19 <m-relay> <c​haser:monero.social> I recall 5500 B from Kayaba for 2/2 FCMP++
18:07:19 <m-relay> <r​ucknium:monero.social> We can end the meeting here. Thanks everyone.
18:09:50 <m-relay> <a​rticmine:monero.social> My understanding for FCMP 2/2 was around 3099 bytes
18:10:06 <m-relay> <a​rticmine:monero.social> 3000 bytes
18:10:53 <m-relay> <a​rticmine:monero.social> This is the latest I heard
18:10:57 <m-relay> <c​haser:monero.social> huh. I think I remembered this, is this outdated? https://libera.monerologs.net/monero-research-lab/20240402#c357039
18:12:04 <m-relay> <a​rticmine:monero.social> Yes
18:12:16 <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?
18:12:32 <m-relay> <a​rticmine:monero.social> Yes
18:13:04 <m-relay> <a​rticmine:monero.social> The verification time issue needs parallel processing
18:14:11 <m-relay> <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
18:16:41 <m-relay> <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.
18:16:43 <m-relay> <k​ayabanerve:monero.social> 2 inputs is only a few hundred bytes larger than 1 input.
18:43:20 <m-relay> <s​gp_:monero.social> Rucknium: what value do you use for r, the number of real user outputs
19:01:46 <m-relay> <s​gp_:monero.social> Do you have the dataset for the average transactions T?
19:09:19 <m-relay> <s​gp_:monero.social> if I'm reading your code correctly, this datatable: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/code/tradeoff-output-index.R#L225 (yes I know I can run it)
19:15:21 <m-relay> <r​ucknium:monero.social> sgp_: Do you want me to output some data for you? The set of transactions `T` is the transactions in blocks between heights 3077201 (February 5, 2024) and  3097307 (March 3, 2024). It's indicated near to top of the file you linked.
19:19:17 <m-relay> <s​gp_:monero.social> On second thought I'll just run the programs myself; it'll be good R practice
19:22:02 <m-relay> <r​ucknium:monero.social> Run `tradeoff-output-index.R` first. Then `tradeoff-optimal-fee-ring-size.R` . Set your working directory in R to `misc-research/tree/main/Monero-Black-Marble-Flood/pdf` to output the tables and images in the right directories.
19:22:25 <m-relay> <r​ucknium:monero.social> I mean `misc-research/Monero-Black-Marble-Flood/pdf`
19:23:56 <m-relay> <s​gp_:monero.social> yup, thanks