17:00:27 Meeting time! https://github.com/monero-project/meta/issues/1480 17:00:31 1. Greetings 17:00:36 hello 17:00:39 hello 17:00:43 hi 17:00:46 waves 17:01:19 hello! 17:01:22 Greetz 17:01:25 hi 17:02:29 Hola 17:02:32 2. Updates. What is everyone working on? 17:02:37

Hello 17:03:02 followups to FCMP++ integration PR's 17:03:11 me: More Nyx eclipse attack defense analysis. 17:03:31 SoP research: https://github.com/Fountain5405/monerosim/blob/sop-research/docs/20261028_mrl_status.md , antiproxy research: https://github.com/Fountain5405/monerosim/blob/progress-brief/README.md 17:03:41 Hello 17:04:22 Hi 17:05:14 long time no see 17:05:32 (spectating) 17:06:39 3. get_tx_key/check_tx_key doxes sender in 2-out tx (https://github.com/monero-project/monero/issues/11586). 17:07:18 Is @jeffro256:monero.social here? 17:09:31 Anything to discuss on this item for now? 17:10:55 Howdy sorry 17:11:19 Yes , the spec and the impl are ready for review 17:11:24 I'll drop links rn 17:11:52 Spec: https://github.com/jeffro256/carrot/pull/16 17:12:01 impl: https://github.com/monero-project/monero/pull/9559 17:12:35 If @tevador is here, I'd like to ask whether he sees any incompatibilities of these changes w/ Jamtis 17:13:39 Maybe not, but good review from any parties would be appreiated 17:13:45 My bad for the likely uninformed question, but what was the trade-off for the chosen fix, again? Was there an option found to not slow down scanning or remove Janus attack protection? 17:15:36 Good question. InProofs still work for incoming payments. OutProofs still work for external outgoing payments. There is also InProofs possible for selfsends, but they take on a different form. I.e. they leak to the verifier whether the enote is internal. 17:16:48 Ah, good to know, thanks. So essentially, the only disadvantage is with self-sends (?) 17:17:22 Yes 17:18:21 Which IDK how often InProofs/Outproofs are used for self-sends, but I'd like to preserve most of the UX if possible even if I never use it 17:18:50 But yeah the main difference is for internal enotes only: no OutProofs, and InProofs look different. 17:19:05 https://xkcd.com/1172/ 17:20:11 Although not explicitly recommended by the spec, nothing prevents you from making external enotes to yourself in >2-out txs and having both OutProofs and InProofs like toay 17:20:20 today 17:20:21 The possible UX impact is a cryptographic audit trail when you have a self-send somewhere in the trail? Can you still get the full trail with the Carrot view keys? 17:20:55 Define "full trail" 17:21:31 I get some XMR. I self-send one or more times. I send it back out to someone. 17:21:50 W/o tx-specific secrets, or a new way to derive tx-specific secrets from your permanent account secrets, then outgoing information is lost, besides total amount per tx 17:21:56 Does the lack of outproofs for self-sends affect me? 17:23:13 If you are giving up view-balance secret anyway, then no. The change in PR 16 is moot 17:23:35 You can always make OutProofs for external enotes 17:23:56 Even if they go to yourself 17:24:27 As in, an external wallet also controlled by you? 17:24:41 Thanks for coming up with the work-around. Seems like a good outcome. 17:25:22 @jpk68:matrix.org: Any wallet: current wallet, other wallet held by you, or other entity with unknown key material 17:26:00 Same situation as current. Any "OutProof" you verify doesn't actually mean that the funds left custody of the person making an OutProof 17:27:55 More on this item? 17:30:19 hi, completely forgot this week. Update at end. 17:31:35 4. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). FCMP++ Integration Audit Overview (https://github.com/seraphis-migration/monero/issues/294). Network upgrade [... too long, see https://mrelay.p2pool.observer/e/9ILC6LgLSklQRXZr ] 17:32:06 integration PR's are ready for review, followups implemented 17:33:18 we're fielding quotes for the integration audit and discussing them internally, I think we should have final quotes and discussion by next week 17:34:06 > <@interestingband:matrix.org> FCMP todo list: spec for it (no single spec), formal verificaiton of spec (most audits are just not reproducible "opinions"), ref implementation, performance testing (benchmark of ref implementation under simulated load), done; No idea what is a purpose of the meeting if 1 person can do it all with AI instead of bunch of humans walking in circles for few years; 17:34:06 @interestingband:matrix.org wants to do all this too, so nice 17:34:36 One q, what is expected timeline for it all at the moment including date for the actual hardfork ? 17:35:26 @jberman: ok 17:35:51 personally hoping all code is ready Q1. reviews would help move things along rather than trying to redo everything your way 17:38:54 My approach is indepnedent on what others are doing and it's the only way to get the best result that I would be ok myself. 17:39:07 ok 17:39:17 Btw, there is likely a way to use bulletproofs++ like instead of generalized bulletproofs and it allow 50% smaller membership proofs 17:39:28 I have PoC and it looks feasible, but proven yet formally 17:39:51 IIRC Aaron had some reservations on BP++ 17:39:58 And there is little difference to verify formal proof with generalized bulletproofs or bulletproofs++ as proving system 17:40:04 but that does sound interesting 17:40:27 This may be best to discuss separately 17:40:50 @sgp_: ok 17:41:30 imo would be interesting for a followup fork fwiw 17:42:44 More on this item? 17:42:59 If we wait on perfect unproven solutions indefinitely, then no one gets FCMPs. Better to do what we've done in the past, which is: move forward, then replace modules with more efficient alternatives. There's a lot more work in doing a FCMP-style hardfork for Monero then just the BP code 17:43:57 some real numbers for what is likely feasible 17:43:57 https://mrelay.p2pool.observer/p/vbPv6LgLOEc0dnZP/1.txt (code snippet, 5 lines) 17:46:19 @jeffro256: Need to start doing a wait calculation for FCMP https://en.wikipedia.org/wiki/Interstellar_travel 17:48:34 5. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). 17:49:09 If implementing FCMP++ becomes 1.4% easier each annum, then in 600 years we can implement FCMP++ in under a second 17:50:51 we released beta stressnet v3.1 which included the inflation patch for the 24 hour fork window, GUI fixes from the latest upstream code, faster scanning, and some DoS prevention. Still some followup GUI issues to check up on (@selsta fixed one, and some potential connection issues) 17:52:39 Stressnet is not very stressful at the moment. Maybe you could even say it's relaxed. I could start spamming soon, but I want to hear specific objections and things to look for in logs. 17:53:12 2 things I'm planning to do in the next week: 1) review tx relay v2 logs during the high stress period of v3 beta, and 2) review / integrate @tevador's relative lock impl 17:53:34 @jeffro256: (the point is that current isn't proven, it doesn't even have a spec to prove, but once you have it, proving small change is easy, once you have full setup) 17:53:41 I think its good being relaxed atm, since the db would be massive if not. I think we shoukd organize / plan when to stress it, and when to not. Basically doing sonewhat controlled tests 17:54:00 I still saw the last stress on oxblocks that we have an unusually high amount of alt chains 17:54:20 So probably something to look at the next time we do it 17:54:41 theres also stressnet.moneroworld.com , if anyone wants to run a datascraper on their node 17:54:41 ack 17:54:44 @jeffro256: (and privacy leak in carrot is an example of what wasn't proven in it, after your changes it's still unproven, it's just that you addresses discovered so far edge cases) 17:55:49 @ofrnxmr: https://github.com/seraphis-migration/monero/issues/508 17:55:59 @ofrnxmr: A lot of that was me when my internet went out for unrelated reasons, but my miner would try mining immedately after it came back online 17:57:38 I will wait to start spamming at least until after @jberman:monero.social "review[s] tx relay v2 logs during the high stress period of v3 beta" 17:57:59 @jeffro256: (and my initial goal was to verify/prove what is written so far, bulletproofs++ addon is just a discovery in the process) 18:02:52 6. Share or Perish (selfish mining mitigation) (https://github.com/monero-project/research-lab/issues/146). 18:03:35 @gingeropolous:monero.social: Do you want to explain what the bot found? 18:04:32 sims are ongoing. i posted a link at the top. i can copypasta again. im kinda in another meeting. basically so far SoP defeats the classic selfish miner. the bot figuring out ways to attack SoP brings down the efficacy somewhat. 18:05:08 and the recent finding indicates that a real network, one with multiple honest mining nodes, may push the equation towards the attacker. 18:06:32 Since you posted, I skimmed this https://github.com/Fountain5405/monerosim/blob/sop-research/docs/20261025_sop_mdp_notes.md and https://github.com/Fountain5405/monerosim/blob/sop-research/scripts/sop_mdp.py 18:06:54 I doubt that the bot did a real MDP, but I could be wrong. 18:07:26 well any direction is appreciated. Anything i can feed the bot to get it to do whats expected. 18:07:39 And this one https://github.com/Fountain5405/monerosim/blob/sop-research/docs/20261028_mrl_status.md 18:08:01 This seems wrong to me: 18:08:01 > Exact MDP (a lower bound only) and a tabular learner could not beat the hand-written family 18:08:28 Exact MDP should be an upper bound. It should be the optimal strategy by the adversary. 18:08:56 And the python script didn't import any MDP solver libraries. 18:10:25 word, thanks. 18:10:25 @gingeropolous: I don't speak bot language. 🤷 18:12:23 I guess I can write some notes about my current state of thinking. 18:13:20 That should be helpful to humans, too. Anything else on this item? 18:14:30 7. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260). p2p: increase white_list size and change connection selection algorithm (https://github.com/monero-project/monero/pull/11527). 18:14:40 i will update the the note for today. I can't think of anything else - im just trying to gather data to support inclusion at some point. Does anyone have any other thoughts on what needs to be proved before its used? 18:16:30 @ofrnxmr:monero.social: Do you want to discuss your proposed patches? 18:16:35 p2p without any weight for nodes is doomed to fail by design, since all nodes are equal 18:16:46 No idea why you are wasting time on white list change, it's pointless 18:16:58 https://observer.monerodevs.org/ 18:17:16 @interestingband:matrix.org: It fixes this specific attack. It's not pointless. 18:17:24 There is an approach for p2p layer around nodes based on their weight which should be linked to their mining capabilites, all other nodes should be connected via them. Done. 18:17:31 It doesn't fix any attack 18:17:53 It's the same pointless approach as OSPEAD for decoy selection 18:18:07 The simulation proves it fixes the Nyx attack. 18:19:17 Your simulation is far from reality then, bcs monero should work with any anonymous network 18:19:57 Solution to problems with decentralized network: make it centralized. Nice. > <@interestingband:matrix.org> There is an approach for p2p layer around nodes based on their weight which should be linked to their mining capabilites, all other nodes should be connected via them. Done. 18:20:05 Not the same thing, but the 101s drop replacement i spoke about at last meeting (not implemented) would add some metric of weighting to whether peeer connections are dropped (instead of random selection). My series does test-before-evict as well 18:21:41 The change makes the attack harder, but as @interestingband:matrix.org: points out its difficult to determine which nodes to select and why. The node weight isn't anymore centralized than the mining process 18:22:37 most nodes do not mine and a lot of miners don't run nodes 18:22:43 Otoh, most nodes arent mining so Im not sure how that would work 18:22:44 Yes 18:23:13 Chainalysis would just need to run a small miner to get an advantage over normal nodes 18:23:38 i've tasked the bots with a similar thing, current progress here: https://github.com/Fountain5405/monerosim/blob/progress-brief/README.md 18:23:41 Or insert adversary 18:23:43 is mining hash cheaper than renting ips? who knows 18:23:53 chainanalysis just needs to convince everyone to switch to ipv6 and it's the same issue 18:24:25 My patch definitely isn't meant to solve all network sybil issues. It's just a simple, quick patch to prevent major network disruption if an adversary decides to use the Nyx cookbook soon. 18:25:17 Yes, I support the pr for that reason. Just pointing out that it's dicey without ipv4 scarcity 18:26:29 @rucknium:monero.social do you want to share the prelim results of the recent sims? 18:26:47 Yes. Do you want to explain what you patches do? 18:26:47 @vtnerd: on the topic of expensive addressing and communication protocol against sybil attacks. monero p2p over meshtastic would be a blast for common people and a bummer for adversaries. 18:26:55 your* 18:27:12 meshtastic bandwidth is likely too little. 18:27:27 true 18:27:29 Yeah our current network security relies on addresses being limited, I don't think PoW is the answer though 18:27:35 sadness then 18:27:58 @jeffro256: You don't get it; it's about being clear about who is partiicpant and who is not, and assumptions of the decentralized "game". And centralized way is what you all are doing by relying on ipv4 subnet. 18:28:33 Recently, 10% of Tor exit nodes were acting maliciously. Then the Tor project just removed them from the directory. Monero can't do that. 18:29:02 * Bucket whitelist into into 256 buckets of 16 > <@rucknium> Yes. Do you want to explain what you patches do? 18:29:02 * bucket graylist into 256 buckets of 32 18:29:02 * dedup by /16 instead of /24 18:29:02 * test peers before evicting from whitelist 18:29:02 * one outbound peer per netgroup (IPv4 /16, IPv6 /32)[... more lines follow, see https://mrelay.p2pool.observer/e/nMCU6rgLd3BQR2l4 ] 18:29:03 https://mrelay.p2pool.observer/m/monero.social/GhoppdPTvEWjboMUjtJSAYCb.png (outbound-adversaries-unreachable-status-quo-rucknium-ofrnxmr.png) 18:29:38 ^ Here the Nyx attack eclipse results. The first two you've seen before. The bottom one is @ofrnxmr:monero.social 's patch. 18:29:42 I didn't specify anywhere any assumption about underlaying network cleanet, tor, i2p. The approach with explicit weight linked to hashrate works with any network. 18:30:21 It's stochastic, so just one run with one unreachable node doesn't show the large-sample average. 18:30:39 @rucknium: This is if the attacker has each node in a separate /24 18:30:48 Yes 18:31:13 Results look different if we concentrate the nodes, and likely different still if the ratio of goodto bad is less in our favor 18:31:31 Now, when the attacker has 10 nodes in each /24. (Well, not "each" /24. But 10 per /24. Same number of adversary nodes total (1000) ) 18:31:44 https://mrelay.p2pool.observer/m/monero.social/KHVpHqaNQGCdnZwBDqFICZwG.png (outbound-adversaries-unreachable-status-quo-rucknium-ofrnxmr-10per.png) 18:32:17 In this scenario, even the unpatched node does OK after a while because it has @rbrunner7:monero.social 's subnet deduplication logic. 18:33:20 @jeffro256: And alternative p2p layer can be active in parallel with what is active atm, with explicit share of resources between them. This way you get benefits of both at the cost of 1/N resource per each channel of communication. LOL 18:33:52 I'd say with the scenarios we have reviewed, my patch and @ofrnxmr:monero.social 's patch perform roughly the same. But @ofrnxmr:monero.social 's patch intends to handle more diverse adversary strategies, AFAIK. 18:35:24 What are the assumptions of your model for simulation, and what is proven in your simulation ? or it's just statistics for different strategies ? 18:35:32 It is reassuring that an adversary really needs to have IP addresses in separate subnets to perform the attack. Thanks to @gingeropolous:monero.social for helping patch a bug in monerosim to allow us to test the 10per-subnet scenario. 18:36:09 @interestingband:matrix.org: I explain that in the PR description: https://github.com/monero-project/monero/pull/11527 18:36:59 I assume that the adversary is carrying out the Shi et al. (2026) Nyx eclipse attack. There are other possible attacks, of course, that I don't model in the simulation. 18:37:12 "TL;DR: An adversary with 1,000 or more IP addresses under its control ..." this part is solved with p2p based on weight linked to hashrate 18:37:24 and then miners has weight, non miners has to rely on some miners or be a miner 18:37:26 done 18:37:31 whole PR can be wiped 18:38:43 for a well-funded adversary hashrate isn't as expensive as we'd want it to be. trust me im a believer in PoW solves all the things but .... 18:38:46 I solve it in fewer lines. 18:39:12 Nah, it's the only mechanism to protect network and consensus: contribute to hashrate 18:39:46 <321bob321> Ruck sent you dm 18:40:00 or rely on someone who does 18:40:27 > or rely on someone 18:40:37 it's pointless to have p2p network disconnected from consensus 18:40:56 Possible paths I see are: 1) My PR is reviewed and merged. 2) @ofrnxmr:monero.social make a PR and gets it reviewed and merged. 3) combination of both. 4) Do nothing. 5) Some other solution is developed. 18:41:16 5 18:41:19 There are clearly downsides to prioritize by hashrate lol. But if you really want to propose this idea then write it up instead of interrupting 18:41:50 and all prev options are not an option at all since they are analysed in the context of all monero components 18:41:50 @rucknium: Ours arent mutually exclusive, mine can easily revert some of the changes from yours if mine is to be accepted later 18:42:16 @sgp_: I will 18:42:17 its much more lines than yours, of course, since it solves multiole issues that can arguably land on their own 18:43:20 @sgp_: And I'm not just interrupting, I've already said how to implement it so that both ways can coexist at the same time in backward compatible way 18:44:07 @vtnerd: @vtnerd:monero.social: I welcome you to review my PR on GitHub: https://github.com/monero-project/monero/pull/11527 18:44:13 I mean, monero doesnt typically like when you do 20 things in a single pr, so i might just start upstreaming certain commits that fix actual bugs, or fix bad behavior 18:46:36 Anything else on this item for now? 18:46:58 @rucknium: What are the downsides of bigger lists ? Why not have it bigger or smaller ? 18:47:40 "The defense scenario simulation increased the white_list size limit from 1,000 to 10,000. The limit was set arbitrarily. To be effective, the value in the simulation just needed to exceed the total count of the sum of honest and adversary nodes." So that constant is just a number to "fix" one attack scenario in your simulatio [... too long, see https://mrelay.p2pool.observer/e/lq7Y6rgLU0s3MXUz ] 18:47:44 Bigger list would mean slower performance in routines that operate on the list. 18:47:50 Basically blind bit flip 18:48:35 How many hours has been wasted on that ? LOL 18:49:13 This research team that has written multiple papers about eclipsing the Monero network has suggested increasing the white_list size for over a year. 18:49:57 Simpler fixes are better than complex fixes, ceteris paribus. 18:49:58 Mine increases the size because its not reasonable to bucket peers with a small 1000 whitelist 18:50:43 @rucknium: Those ppl successfully wasted time in a spirit of academic research with their useless formalism. That's the most important part of academic research that should not be adopted by MRL. 18:50:58 white = 256 * 16 = 4096, gray he 256 * 32 = 8192. Iirc bitcoin is 256 * 64 = 16384 18:51:05 Mine ^ 18:51:20 This attack is very practical and not just hypothetical (formal) at all. 18:51:53 I'll end the meeting here. We can continue discussing after.