12:24:55 hello good day, i am dealing with some buffer overflow, set watermark of buffer max size thingy in jt-grassies pool.c . Since i know there is a strict block limit size at any given time, is there a rpc call to the monerod that gives me that size wrt the current tip? 12:26:03 get_info 12:26:20 The limit is 2x the recent "average". 12:31:32 curl -L 192.168.0.152:28081/getinfo 12:31:49 is that it ? 12:31:52 "block_size_limit": 600000, 12:32:35 * slave_blocker hopes, and is thankfull 4 moneromooo... 12:34:00 Yes. Looks like it's already x2'd for you. 12:34:32 wow that was nice simple and easy :D 12:35:13 yes because the average would be given by : "block_size_median": 300000, 12:35:52 what about the block weight does that exceed the block size? 12:35:53 "block_weight_limit": 600000, 12:37:11 i mean could it exceed the block size? are thouse limits the same or is the weight strictly less or equal? 12:39:46 weight is basically size, with an extra bump in cases where a bulletproof would have extra bytes were it a linear proof. Weight is what is used as a block size limit. 12:40:06 I think "size" here is just backward compat. 12:46:00 great so i will use this as the MAXLINE : "block_weight_limit": 600000, 12:46:16 thx 15:01:24 MRL meeting in this room in two hours. 16:17:02 hum 16:19:43 another thing, how do i find out what the minimum tx size is? i searched online and 1,4 kb seems the min ( because this buffer deals only with block_template wich deals only with tx ids i want to divide 600000/(min tx size), and then multiply that by 32. whats the answer? 16:27:34 if i take 1500 as the min size for a tx, then 600000÷1500 = 400. then 400 *32 = 12800 . Grr thats not right need to know how to define the MAXLINE based on the block_size_median ... 16:29:56 slave_blocker: That is a good question for the #monero-dev room. This is the MRL room. 17:00:21 <0xfffc:monero.social> Hi everyone 17:00:26 Meeting time! https://github.com/monero-project/meta/issues/1213 17:00:30 1) Greetings 17:00:38 Hello 17:00:56 hello 17:01:12 hi 17:01:21 Hi 17:01:29 hi 17:01:33 *waves* 17:01:35

hi 17:02:10 hello 17:02:30 2) Updates. What is everyone working on? 17:02:55 <0xfffc:monero.social> Working on addressing reviews / comments on new tx relay v2 17:02:57 <0xfffc:monero.social> https://github.com/monero-project/monero/pull/9933 17:03:20 Howdy 17:03:35 finished brief rundown (20 lines) of scoring methods found in ~50 papers for today 17:03:46 me: Analysis of subnet deduplication for node peer selection as a countermeasure to spy nodes. I simulated a network with 90 percent unreachable (closed-port) nodes and found that honest reachable nodes would have 133 median inbound connections with the status quo algorithm and 182 median inbound connections with subnet deduplication. This would put more load on the honest reachable nodes. 17:04:46 Docs here: https://rucknium.github.io/xmrpeers/reference/gen.network.html 17:05:21 me: still working on cold/hot wallet stuff. I had to re-work a big part of the carrot_impl lib to get a clean solution for some problems, but I think I should be wrapping it up soon within the next couple of days 17:06:11 me: Finished FCMP++ scan_tx, an RPC endpoint to fetch paths by global output id, and worked on getting all tests to pass with the latest code 17:07:08 Me: fixed all remaining send tx issues with lws-frontend except priority fees, which requires Daemon+LWS api changes. Otherwise fees are correctly computed now, and txes can be split if there is a high number of destinations just like wallet2 17:07:47 3) FCMP++ & divisors. https://github.com/cypherstack/divisor_deep_dive 17:08:20 Is Liam Eagen here? xmrack invited him. 17:09:37 Any Cypher Stack staff here? There is a new document from them: 17:09:39 Goodell, B., Salazar, R., Slaughter, F., & Szramowski, L. (2025). A Further Review of the DL Gadget Of Interest. https://moneroresearch.info/268 17:09:46 hi 17:09:47

Rucknium: I’m not sure, they said they would be free but I havent seen them join 17:10:34 I read the new doc ^ and have some questions and comments. 17:11:15 Question and comment away 17:11:31 The divisors would use probabilistically checkable proofs (PCP). Does this open a new potential attack vector or does Monero already use this type of technique somewhere critical? 17:12:01 And does it make it harder to compute the N bit security of Monero's cryptography? 17:13:11 hello everyone, sorry about my delay 17:13:20 PCPs are not problematic on their own, it's just a description of what sort of algorithm it is. 17:14:01 like a sigma protocol just describes a 3-round interaction, a PCP just means "this is a proof which is probabilitically checkable" (and therefore should be parameterized so that probabilities of security problems are negligible) 17:14:03 On the Schwartz-Zippel Lemma discussion: Usually, mathematicians love to generalize things. The fact that the SZ Lemma has not been generalized to the multivariate case makes me think that it is very hard to generalize, or cannot be generalized, period. How solid is Bassa's alternative approach that substitutes for the SZ Lemma? 17:14:42 4.3.1 Developer watermarking 17:14:43 > This means that a malicious developer can insert additional points, or remove certain points, from a 17:14:45 statement. This won’t be detected if the proof remains valid, and the cryptographic size of G ensures that stashing a single random element in a divisor is essentially undetectable. 17:15:05 Check this paper. Maybe this malicious watermarking is already possible in RingCT: Guo, S. 2024, Secure Monero on Corrupted Machines with Reverse Firewalls. Paper presented at International Conference on Data Security and Privacy Protection. https://moneroresearch.info/245 17:15:29 Abstract: 17:15:31 > Monero is known as a cryptocurrency for its ability to provide greater anonymity. At its core is the RingCT protocol that can hide the sender and the amount of money in a transaction. However, the Snowden revelation alerts us that the implementation of cryptographic algorithms in practice might be substituted covertly which would result in a complete breach of the security of th e cryptosystem. In this work, we turn to evaluate the potential hazards of algorithm substitution attacks (ASAs) against the RingCT protocol and explore feasible countermeasures. In specific, we first present the ASA model for RingCT where the goals of adversary include diminishing sender anonymity and recovering the spending key, then propose concrete ASAs against RingCT protocol s that are undetectable in terms of the output of algorithms. Finally, we show how to thwart ASAs on RingCT protocols with reverse firewalls. 17:15:37 Re: Schwartz-Zippel: Generalizing to the multivariate case isn't hard. Bassa's work was insufficient in showing that the problem appropriately fits into that context, and the details of how it does so inform quantified assessments of probability of success 17:16:42 malicious watermarking is admittedly hard to defend against. at least in this case, it would be checkable if code were doing that, but it could lead to fingerprinting and more. just like developer choices in terms of payment IDs in the past could be used to split monero's anonymity pool into puddles 17:17:26 also, i believe we have nailed down some calculus problems in the specific divisor algorithms which don't impact completeness but impact soundness 17:17:57 Yes. I would be more concerned about accidental watermarks from custom implementations, but I don't know how likely custom implementations may be for this part of Monero's cryptography, deep in the system. 17:18:05 getting into greater detail about that is still a little premature; we are deriving all equations rigorously from scratch 17:19:10 Theorems 2 & 3 in the document: Shouldn't these be labeled as conjectures instead of theorems? 17:20:23 Yeah, that'd be more appropriate 17:20:49 although we have a proof of theorem 2 now 17:20:54 and theorem 3 is not far behind either 17:21:11 Great! 17:21:16 it would be shocking to me if these were not true conjectures 17:21:57 I agree, intuition dictates it. But might as well be certain 17:23:00 This is a self-directed comment to MRL, not really Cypher Stack: I finally looked at Eagen's divisor paper: 17:23:01 Eagen, L. 2022. Zero Knowledge Proofs of Elliptic Curve Inner Products from Principal Divisors and Weil Reciprocity https://moneroresearch.info/index.php/269 17:23:03 Eagen says that the argument for his divisors technique is similar to the argument for Bulletproofs++. However, over a year ago, Aaron Feikert (sarang) reviewed BP++ and said there were questions about its validity: https://moneroresearch.info/217 17:24:16 So, MRL assumed that Eagen's divisors were OK despite the BP++ work falling short. And there was not much action taken on backup plans. 17:25:10 The https://moneroresearch.info/index.php/269 link is broken I think btw 17:25:18 Does someone else have questions and comments about the latest divisor's analysis? 17:25:35 Thanks, should be https://moneroresearch.info/269 17:28:03 Papers and document relevant to FCMP are collected here by the way: https://moneroresearch.info/index.php?action=list_LISTSOMERESOURCES_CORE&method=subcategoryProcess&id=1 17:29:02 Would need more time to review the paper, but the general takeaway from it is the same as has been discussed in past meetings: divisors require more academic rigor and work and may fall short under further scrutiny, and CS appears to be continuing that work 17:31:23 "And there was not much action taken on backup plans." -> Luke was pretty clear on the backup from the start, which is that divisors could be swapped out in the impl. The vast majority of the meat of FCMP++ and code we've been working on is still useful in that backup scenario 17:33:00 I don't know if I would have been a +1 vote on the FCMP optimization competition timeline if I had investigated and thought about it more. Of course, cryptography is not my field, so I would tend to defer to others on those questions, anyway. And programming isn't my field either :) 17:33:35 Anyway, that is water under the bridge 17:34:27 Regarding the competition, i'm not shy to say the ban of the r/rust post was dramatic for reaching out potential competitors 17:34:39 I think in hindsight, maybe would have made sense to do a more general academic approach on divisors from the start with an open timeline, rather than the more piece-meal approach. Hindsight is 20/20 17:35:03 From what I understand now, Cypher Stack's review of Bassa's work has turned into much more: needing to prove things and make scientific progress. MRL is very thankful for that. 17:35:12 not xmrack fault (I think it was xmrack idr for sure), but it's been mostly our only card of reaching other communities 17:36:13 I think as long as CypherStack makes progress and does not declare defeat nothing is ultimately lost yet ... 17:37:39 surae, Freeman Slaughter , Luke Szramowski , Diego Salazar : Do you need anything specific from MRL at this time? 17:38:13 Give us dominos pizza gift cards, please and thank you. 17:38:17 To MRL: Is there specific action/decisions that MRL needs to take about divisors? Proposals? 17:39:24 I assume that if there were news about non-divisor FCMP implementation, it would appear 17:39:56 You mean from third parties? 17:39:59 Nothing from me. Sorry, will share as soon as I have news to share on non-divisor impl 17:40:22 Ah, no, our own alternative 17:42:54 so does the non-divisor FCMP implementation need its own audits etc? 17:43:15 Yes 17:43:47 It would have a different cryptographic construction and needs to be audited separately 17:44:18 Will some parts benefits from the prior audit? or is this audit "practically" done from scratch again? 17:48:14 AFAIU we would need security proofs with the new construction and a new audit for that component, but most of the prior non-divisors research should be unaffected (like GBP research). Pinging kayabanerve to clarify 17:50:33 More comments or questions on FCMP divisors? 17:52:36 SyntheticBird: A lot of non-membership-specific academic is reusable. If you look at https://moneroresearch.info/228, the SA/L proof doesn't have to be re-proved, the section 7 "composed proving system" doesn't have to be re-proved, and the general higher-level security properties of the system (section 8) don't have to be re-proved. We would basically just need to audit that the new non-divisor FCMP membership construction can prove the relation in section 5 17:56:24 4) Unit test for implementation of subnet deduplication in peer selection algorithm. https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/monero-peer-subnet-deduplication.pdf 17:56:45 Like I said in updates, I simulated a network with 90 percent unreachable (closed-port) nodes and found that honest reachable nodes would have 133 median inbound connections with the status quo algorithm and 182 median inbound connections with subnet deduplication. This would put more load on the honest nodes. 17:57:26 During last year's suspected black marble tx flooding, nodes with many connections had trouble keeping up with the blockchain. 17:57:54 what was total size of network? 17:58:17 I don't know if the projected increased load is something to really worry about. Anyway, the simulation assumes that all nodes update, which usually doesn't happen 17:58:54 Well, you can always limit the number of incoming connections with a parameter 17:59:50 With the 90 percent unreachable assumption, there would be 44,000 total honest nodes. That seems high, but some people who run reachable nodes report about 150 inbound connections, which would be roughly consistent with the 90% unreachable assumption, if everyone followed the status quo default peer selection algorithm and 12 outbound connections default. 18:00:31 0xfffc's work on the more efficient tx transmission protocol would help here 18:01:01 If nodes start limiting inbound connections, then other honest nodes would have to pick up the slack. 18:01:28 Now, the network is using spy nodes as a crutch. 18:01:44 Hopefully mostly people with weak systems, or limited bandwidth, would limit 18:01:56 Since those spy nodes are absorbing a lot of those connections that "should" be going to honest nodes. 18:02:57 <0xfffc:monero.social> Quick update, for anyone not in the loop: I am addressing the reviews and concerns about the code. No deal breaker. Hopefully the new implementation will be push in a day or two. 18:03:09 What is the current level of inefficiency? Name Ly how many times is the same transaction data, transmitted during transaction propagation and finally during propagation of the mined black ? 18:03:28 I think we will have to just try and see. Not bringing a better algorithm into service and continuing to connect to a lot of spy nodes can't be the solution :) 18:03:30 By the way, boog900 and my MoneroKon 2025 presentation on defeating spy nodes, which will include subnet deduplication analysis, is now scheduled for June 22. Abstract here: https://cfp.twed.org/mk5/talk/AE7CWF/ 18:04:01 Getting a handle on this will go a long way to help overburdened nodes 18:04:12 <0xfffc:monero.social> Congrats, looking forward to seeing it. 18:04:23 Over 90% of tx broadcasts are redundant 18:04:33 A full txpool makes it worse, because the node will re-broadcast unconfirmed transactions half a dozen times, at intervals. 18:05:10 Which is probably one reason why the spam last year was so tough on nodes. 18:05:43 rbrunner had an update on his investigations of the peer connection code, I think. 18:06:45 Yeah, found a sweet bug that made most connection retries basically a waste of time internally. Without that bug finding new peers works faster and with a better success rate 18:07:12 Thank you, rbrunner :) 18:07:29 We probably live with that bug for about 6 years :) 18:07:59 So an inefficiency of 10x to 20x 18:08:09 I suspected that the connection attempts were failing too quickly from what I saw in the logs, but I could not read the C++ code 18:08:40 Yes, finding it was a nice teamwork. I can give back thanks, Rucknium! 18:10:08 We can move on to the next agenda item unless there are more comments/questions on this one. 18:10:23 #9933 fits in nicely here. 18:10:55 5) Web-of-Trust for node peer selection. 18:11:14 flip flop: What did you find? 18:11:49 Brief rundown of peer scoring found in ~50 papers. References on request. 18:11:51 1) Data collection: 18:11:53 1a) Subjective scoring: node keeps track of /quality of service/ of its peers and never reveals its scores to others (bitcoin ban score, peerinfo_manager) Decay factors used to smooth. "Good scores" preferred to "Ban Score" metrics to avoid eclipse, DoS and defamation attack vectors. Reliable. Relatively low requiremets. 18:11:55 1b) Recommedation based (pgp, GossipTrust, EigenTrust): in addition to a), nodes poll their peers requesting their subjective scores. Authors point out that a well defined "good" init state should exist: then malicious collectives may be broken up by cross-checking. Otherwise lying nodes may break the system with 21%-40% malicious addresses. Some authors suggest data structures 18:11:57 or a parallel p2p network to store extensive reputation data. 18:11:59 1c) Data driven: in addition to b) compagnion apps are used to collect big data, querying regular nodes and building a graph represented by nodes, edges and flow metrics (bandwidth, timing). Machine learning is used to detect outliers. Authors tend to promote their own models avoiding self-criticism. Potentially very powerful (yet expensive). May not scale to many nodes. 18:12:01 2) Actions: 18:12:03 2a) The derived metrics may or may not inform /peer selection/: Some authors use scores to prioritize peers, gossip and ban others. 18:12:05 18:12:07 2b) At least three Authors design a PBFT based consusus algorithm centered around reputation scores (1b). Roles may be defined by reputation score, such as supernode, verifier, leader, witness, etc. One paper suggests a dual PoW and reputation-based PBFT consensus with variable weight. 18:12:09 18:13:54 (1c) seems not feasible given that Monero p2p graph edges are deliberately hidden. 18:14:29 How do we identify nodes? Just based up IP address? 18:14:47 Can we say that part of PR #9933 is a case of 1a)? 18:15:01 <0xfffc:monero.social> Yes. 18:15:16 absolutely! 18:16:38 <0xfffc:monero.social> It has a separate peer info management mechanism. Which I track every interaction. Missed, announced, received, send, etc. we can use that data to calculate a score. So far I am only using 70% rule. If they announce 100, but delivery fall less than 70, we drop them. 18:16:52 <0xfffc:monero.social> But the data is there, ready for other calculations. 18:16:56 two weeks ago, researchers mapped the net... i take this as viable 18:17:29 IMHO, systems that have been battle-tested in adversarial environments should be considered more seriously than those that have not. I am afraid of systems that would seem to work well in theory, but have hidden flaws that could blow the system apart. 18:17:31 <0xfffc:monero.social> There was concern from vtnerd to not add it, and integrate it to our existing limited scoring mechanism. Right now I am looking into this. 18:18:17 i was amazed to find this! no need to lobby any further... :) 18:18:32 0xfffc: Could you explain details of Monero's current limited scoring mechanism? 18:19:40 One issue I see is that some ISPs change dynamic IPs on residential connections with a frequency of under 4 hours. 18:19:55 Originally I thought it was a binary system: One bannable offense gets you banned. 18:21:04 <0xfffc:monero.social> That is the part I have started today. So my report will not be accurate. But I will write a doc and report send it to this group once I have (more) clear understanding. One of the big problems with our existing scoring is it is tightly integrated into low level networking code. 18:21:05 <0xfffc:monero.social> I wanted completely abstracted away. Taking that logic out of our low level networking code is the hassle. 18:22:14 >Failure Detection: Penalizes peers for: Unresponsive behavior 18:22:15 The intuition is to ban spy nodes, but 18:22:17 Wenjun Fan et. al [1] and [2] warn that a "good-score" is more effective -- given entries in white_list would be prioritized. 18:22:19 So called "defamation attacks"... not shure if relevant, adversary might try to eclipse "superodes": dos'ing its peers, then inject fake entries in superode's gray_list. 18:22:21 [1] The Security Investigation of Ban Score and 18:22:23 Misbehavior Tracking in Bitcoin Network 18:22:25 https://par.nsf.gov/servlets/purl/10407054 18:22:27 [2] Positive Reputation Score for Bitcoin P2P Network 18:22:29 "focusing on the peer’s behavior in relaying unique/new blocks and transactions." 18:22:31 https://drive.google.com/file/d/17S4N3eJvUePvO92ob_cIseeusQSMG0ly/view 18:22:49 <0xfffc:monero.social> We have score field. But we don’t use much IIRC. 18:22:49 <0xfffc:monero.social> And the bigger issue imho is its integration to our low level networking. Which means you should not and cannot touch it unless you are pretty familiar with our low level networking stack ( asio, etc ) 18:23:51 <0xfffc:monero.social> (9933 it does have other parts than peer info management mechanism ) 18:26:05 Would splitting this into two more single-thematic PRs be something? Might also speed up getting the better tx distribution through review and testing 18:26:39 Just brainstorming 18:27:00 <0xfffc:monero.social> Possible, might be even a good idea. But there is mutual dependency. You need 70% rule for tx relay v2. 18:27:29 @rucknium:monero.social you had a concern with Tx Relay v2 and D++ ? 18:27:51 <0xfffc:monero.social> I will talk to [boog900](https://matrix.to/#/@boog900:monero.social)about this though. 18:28:18 I suggested splitting the new code for accepting these messages from the code that initiates them. But the code that initiates is like 5% of it. 18:28:35 flip flop: I think the benefits outweigh the potential risks. I wrote a GitHub comment about it. 18:28:41 Initiates what? 18:29:06 thats what i thought, too 18:29:26 rbrunner: tx broadcasts. 18:29:45 pretty much the code in levin_notify 18:29:52 <0xfffc:monero.social> Separate peer info management mechanism, with accurate data for every interaction with the nodes, is something we can use a lot. Does that look like something useful to you [Rucknium](https://matrix.to/#/@rucknium:monero.social) 18:30:34 <0xfffc:monero.social> Let’s call it Scoring mechanism. Not peer management ( at this point ) 18:31:02 It was mostly about discovery of the p2p network's edges (connections between each node). And apparently the Zurich researchers were about to get a weekly estimate of that from just the white_list peer selection behavior (which could be changed, but the estimate is not very useful to an adversary, as it stands.) 18:31:05 <0xfffc:monero.social> Every missed, every send, every received, speed. Etc. 18:31:41 Here was my comment: https://github.com/monero-project/monero/issues/9334#issuecomment-2307824031 18:32:05 it possible to track block delivery, right? 18:33:07 <0xfffc:monero.social> In hypothetical scoring mechanism, absolutely. I don’t see why not. 18:33:07 <0xfffc:monero.social> We don’t want to keep the actual data ( that is huge ). We want to keep track of metadata. 18:33:09 0xfffc: IMHO, it could probably help if spy nodes are trying to save bandwidth by not relaying as many txs and blocks. 18:35:09 spy nodes could just not send any invs to save bandwidth, currently we only keep track of this info to stop nodes from advertising txs and then not responding with them when asked. 18:35:12 the 30 point window could be reduced by a 1-pole recursive filter. 18:36:51 <0xfffc:monero.social> This is one area I think we don’t use much. I have to talk to boog and other devs more. But data is gold. Once we had the data, we can detect behaviour or the peers. 18:37:22 <0xfffc:monero.social> And keeping that data is very simple. It is strange we don’t have more robust mechanism for that. 18:38:14 I somewhat disagree if I am honest, I think for now it can complicate the system. Once the structure is agreed on how this data is stored we can track more as needed. 18:38:26 Again, i think of good behavior a spy node might avoid. And scoring that. 18:39:28 <0xfffc:monero.social> Yes. The mechanism to keeping that data in code base is gonna be controversial. 18:39:29 <0xfffc:monero.social> Anyway, I am here in case anyone had any questions. Don’t want to monopolize the meeting time. 18:43:15 also vtnerd just suggested to put the current per-peer data that is kept in `peer_info_manager` inside the `connection_context` which i think is reasonable. 18:44:18 <0xfffc:monero.social> Yes. We have to add all those data to `connection_context`. 18:44:28 we already have other monero protocol stuff in there, not just underlying p2p protocol stuff. 18:46:20 i mean, a malicious entity could just act good to get in the good graces of the network, and then launch an attack of some kind, right? 18:46:40 personally i'd prototype stuff like scoring in a compagion app. we only need to reveal the data - taking action is a lot more complex and must be simulated 18:48:16

Rucknium: Liam messaged me back, there was a miscommunication with times and our MRL meeting conflicted with his Bitcoin conference talk. I’ll try to see if he can join sometime in the next few weeks. Sorry about that 18:49:25 xmrack: Sounds good. Thanks. Try to clarify the goals of his appearance so we know if Cypher Stack staff should be specifically invited. 18:50:03 i guess i'm just hoping to clarify what it is we're defending against. Spy nodes? lazy nodes? ddos? 18:51:07 gingeropolous: They can do that now without acting like honest nodes. Though, I would be concerned about an adversary manipulating the scoring system to lower the score of honest nodes. For example, showing even _higher_ bandwidth use than an honest node would. 18:52:36 for 9933, a sort of DoS. Nodes could advertise a tx and never send it leaving our node waiting for it until we re-request it after 30 seconds. 18:52:42 yeah. i mean, with 9933, it seems there's a need for some scoring system, because if you need to request txs from a peer, then you should drop peers that don't respond. 18:53:38 although now thinking about it, it should be windowed, i.e. should only take into account the last 100 txs. 18:54:41 and i feel like there's gotta be some middle ground between our current "blast all trasnactions everywhere all the time" and "lets just take a little sip of some data here, and some there" 18:55:31 efficiency and resilience are uh.... not the best bedfellows. 18:56:32 We can end the meeting now. Feel free to continue discussing items. Thanks everyone. 18:56:41 thanks 18:56:47 delicious meeting as always 18:57:16 thanks 18:57:39 <0xfffc:monero.social> Thanks everyone 18:57:42 thanks all! 18:58:25 this probably is the middle ground, we could go even further with protocols like erlay 19:00:36