06:53:07 https://www.reddit.com/r/monerosupport/comments/1k0dk6v/ring_members_position_question/ 06:55:59 thinking about it for 1 second, probably complete nonsense 06:56:37 do ring memebers even have a position number? 07:27:20 I answered. He's been pretty annoying everywhere with this question. 07:28:27 They are ordered, yes. By chain age. 07:28:47 Internally, the list is of positive deltas from the preceding one. 11:44:47 The question is not so stupid after all. [ But amounts are irrelevant here. ] The thinking error is, an attacker does not know the age and has to guess. So the implication " pick #15 and you r done !1!! " greps attention, but that's about it. 12:23:05 "The most recent output" heuristic was a thing before, but I think the current decoy algorithm fixed it? 12:48:56 It did, but if you can't design an unbias experiment and try to send txes with a newly funded test wallet, you'll often get that hit, and not realize it's due to the bias of being newly funded, which the adversary does not know, but the tester does. 12:50:35 Now, it might be that the decoy selection parameters need tweaking after all this time, I dunno. 13:15:41 need to repeatedly spend outputs that are 1 week old in order to see if they ever appear last? 13:23:06 The decoy set is independent from the output you send (beyond collision prevention). You don't have to spend outputs, just generate plenty of rings and see what age the members are. 13:23:23 (assuming post RCT outputs( 13:24:06 That's also why if you spend very old outputs, they're 99.999% certain to be the first ring member. 13:25:20 And is why at some point my naive self wanted to always pick a random old out if the out you spent wasn't old. It seems good at first glance. But statistics. 15:00:43 MRL meeting in this room in two hours. 17:00:14 Meeting time! https://github.com/monero-project/meta/issues/1189 17:00:21 1) Greetings 17:01:05 Hello 17:01:10 Hi 17:01:18 hello 17:01:37 *waves* 17:01:38 hola 17:01:54 Hi 17:03:02 2) Updates. What is everyone working on? 17:03:35 me: I submitted two talk proposals to MoneroKon. One on spy nodes with boog900 and one on OSPEAD. Also working on applying xmrack 's machine learning code to the analysis of OSPEAD deployment risk without a hard fork. 17:03:51 surae: Do you want something added to the agenda? 17:04:12 me: still working on lws-frontend subaddresses (primarily) among other things related to that frontend project 17:04:13 nope, just observin' 17:06:25 me: continuing with serialization of an FCMP++ blinds cache (for saving the expensive divisor calculations in the wallet cache early on so that wallets can construct FCMP++'s nearly instantaneously at tx construction time), nearly done, then working on addressing jeffro's PR comments over here: https://github.com/seraphis-migration/monero/pulls 17:06:31 Howdy 17:08:14 3) FCMP alpha testnet, stressnet, and public testnet planning. 17:08:39 me: working on supporting all smaller `wallet2` features for Carrot txs as I see issues crop up. Examples: cold signing protocol, the superfluous main tx pubkey issue, scanning from transaction prefixes, payment proofs, etc 17:10:55 ⏳️ 17:11:25 Tentatively, I think stressnet could commence two months after alpha testnet starts and/or one month after the FCMP++ coding competition ends, whichever is later 17:11:26 tobtoht: mentioned that he already got Carrot/FCMP++ transaction construction working in Feather wallet which is really cool IMO 17:12:10 We know when the coding competition will end, so when might the alpha testnet start? 17:12:44 A stressnet before the competition ends might be helpful for us to figure a baseline for speed earlier in development and focus on non-cryptography related issues 17:13:20 I think we can call the alpha testnet an alpha stressnet instead 17:14:24 On alpha stressnet: I think I can have my FCMP++ side of things ready within the next 3 weeks. I'd defer to jeffro on Carrot timeline for settling on a date 17:14:24 Main stressnet: I agree I think we can target for 1 month after the coding competition ends 17:16:50 To make it clear: I want some distance between alpha stressnet and "public" stressnet because it is harder to coordinate fixes on the fly with many community people running nodes. 17:17:09 I want alpha stressnet to hit problems first 17:17:48 The problem with doing stressnet on the testnet is that future nodes have to download a bunch of bloat that isn't relevant anymore for future HFs 17:18:49 to be clear, wasn't proposing doing that on the testnet. Was assuming it would be a throwaway stressnet like last one 17:19:10 Yes, for sure don't make regular Monero testnet blockchain too big 17:20:05 I deferred to jeffro and jberman. jberman deferred to jeffro. Everyone is looking at jeffro256 👀 17:20:17 Okay you're proposing doing a throwaway network but not making a distinction between stressnet and non-stressnet at first? 17:20:36 At least for "alpha" 17:20:41 Yeah I'm good with that ! 17:21:36 It would be called "alpha stressnet" so distinct from non-stressnet 17:22:14 Carrot, without multisig nor pratical hardware device support, should definitely be ready (and hopefully a bit more polished) in 3 weeks 17:22:24 (I've held off on discussing public testnet for now, because I think makes sense to settle on the stressnets first) 17:23:13 Awesome so we're on a similar timeline basically :) 17:23:29 But view-only wallets, background sync, cold signing, transaction proofs, and basically all the other features I can think of off the top of my head should be ported to Carrot where needed within that timeframe 17:23:48 Proposing we target an alpha stressnet in 5 weeks then? 17:24:01 5 weeks sounds great to me 17:25:02 Does this include the `monero-wallet-cli` and `monero-wallet-rpc` binaries? 17:25:34 Yes 17:25:37 5 weeks would be May 21st 17:26:30 Anyone object to initiating the alpha stressnet on May 21st? 17:28:24 I think that's settled. :D 17:28:50 Awsome 17:29:00 Unless there are big unforeseen problems 17:29:05 ACK/NACK on the date from jeffro I think would be good too 17:29:14 ACK on May 21st 17:29:41 4) Decide on publicising the method to find proxy nodes. https://github.com/monero-project/research-lab/issues/126 17:29:43 boog900 wanted to bring this up 17:30:00 Wait hang on, we can set up targets for the other nets too 17:30:12 Ok 17:30:22 Proposing 1 month after competition ends for main stressnet 17:30:41 August 27th 17:30:53 whoops sorry, July 27th* 17:31:04 Will we need a whole month to setup? 17:31:07 jberman: Sounds good to me. 17:31:47 I don't know how long it will take to test and integrate the competition code 17:32:56 If the competition doesn't yield an improvement to helioselene, it may make sense to implement downloading tree elems for the tree cache instead of rebuilding the tree (or spending time on my end trying my hand at helioselene optimization too) 17:33:04 which could take 1-2 weeks 17:33:51 So 1 month would give time to both implement the code and/or do that^, and then 2 weeks of lead time for announcing the next stressnet / preparing binaries? 17:35:05 That sounds reasonable to me 17:35:18 Maybe we should wait to set the date, then. If the competition goes well results-wise and the code is trivially integratable, and assuming we already have a good working alpha stressnet, we may only need a couple days between competition end and new network start 17:35:57 Although not setting the date until a couple days before sort of defeats the purpose of setting a date 17:36:26 I think at least 2 weeks of notice for stressnet would be good. 17:36:29 Sounds good to me, we can loosely say here we're targeting that proposed date at the latest, but may set it earlier 17:37:31 Or just say we're targeting July for main stressnet without specifying the day 17:37:57 Until we're ready to (with at least 2 weeks of notice) 17:38:13 "Targeting July" sounds good 17:38:17 I think a vague-ish time period is fine for testing networks 17:39:00 Are we ready to move on to the next agenda item? 17:39:09 Last thing 17:39:16 On public testnet: ideally this will run after all code is ready and merged (which means audited and reviewed). If we really push, I think we can complete all that 3 months after the main stressnet round of changes 17:39:34 More conservatively we'd give that 6 months 17:40:01 So perhaps we target Q4 for public testnet? 17:41:48 Sounds good to me 17:42:44 Alpha stressnet: May 21st 17:42:44 Main stressnet: July 17:42:46 Public testnet: Q4 17:42:48 How much code auditing and mathematics review would be done by then? Nearly all? 17:43:10 Should be all 17:43:56 There is a nice symmetry about the dates. Getting one unit vaguer on each step. 17:44:13 Which would give FCMP++ mainnet 2026. :P 17:44:37 4) Decide on publicising the method to find proxy nodes. https://github.com/monero-project/research-lab/issues/126 17:44:44 boog900 17:45:17 I think allowing people to see for themselves just how clear it is these nodes are proxies is more beneficial than keeping the method hidden. The fact they have used the same IPs that are known bad for years tells me they cannot change easily and even if they did constantly updating a banlist is not a good solution. 17:45:18 We do have other methods to tell apart these nodes, although we would be revealing the best one IMO. 17:45:20 I think at some point the method needs to be released for transparency anyway, we did tell the whole network to ban 40% of the reachable node's IPs. 17:45:22 Just want to get opinions from MRL before I make it public, does anyone disagree with making it public? 17:46:30 No disagreement here 17:46:37 Sounds good. 17:47:28 It sounds good to me, especially if subnet deduplication can get into the next binary release. But even if it doesn't, it's ok to disclose. 17:47:37 binary release version* 17:47:46 Did we decide that all the proxies originate from one entity? If not, some might change, even if others don't. There might be a psychological element that once they know how we trace them, then they finally get off their asses on do something about it 17:48:18 Especially since it seems like a semi-smart coder could fix the issue relatively quickly 17:49:47 [flip flop] lets focus on subnet deduplication impl 17:50:03 we haven't, IMO there are at most 2 entities as the nodes from the subnet blocks have slightly different behaviour than nodes from single IPs. The single IPs use a random public node, the subnet blocks use their own node. 17:50:05 Well they can't fix many proxies within a small subnet, but they could fix the identifying issue 17:51:15 We can focus on dedup'ing subnets without revealing the tracing methodology. Also, to be clear, I'm not totally against disclosure, but there's some downsides to doing so, and the downsides are irrevocable 17:51:46 ?? 17:52:12 downsides? 17:52:24 Can't un-ring a bell 17:53:28 Ah, it has its own Wikipedia article: https://en.wikipedia.org/wiki/Unring_the_bell 17:53:28 > In law, unring the bell is an analogy used to suggest the difficulty of forgetting information once it is known. 17:53:49 dedup'ing subnets without revealing the tracing methodology - thats what I meant, of course 17:55:22 are there any open questions on how to impl dedup'ing ? 17:57:19 I don't think so. Just need someone who knows or can read the Monero netcode to implement it, AFAIK. 17:57:39 Yes, it may take some time until somebody comes around to do it 17:58:00 But still, that does not fully change the equation for me: more on the "plus" side of publishing the method 17:58:05 IMHO 17:58:24 At least with subnet dedup implemented, people could drop the banlist if they're uneasy about it and get *most* of the spy nodes eliminated 17:58:42 Another thing to add is that these nodes are not that effective against monerod. They have 75% of the IP:ports, 40% of the IPs but only make an average 15% of the outbound connections. Although we can't take back the method once public, I still think that allowing more people to see the method should lead to more of a push to impl real fixes. 18:01:43 From your research the method ca be guessed ? So why publish at all ? 18:01:47 We have a reservation from jeffro256 to disclosure right now. Can we return to this next week? (Maybe I am being selfish since I have three Rucknium-themed items left on the agenda). 18:02:27 Or I can push those item to next week instead 18:02:29 I'm sure this can wait at least another week 18:04:11 I found it by sending different requests to these nodes, I think it is unlikely for someone unfamiliar with the P2P protocol to find it. 18:04:13 yes 18:04:22 5) Franzoni & Daza (2022). "Clover: An anonymous transaction relay protocol for the bitcoin P2P network". https://moneroresearch.info/222 18:04:36 boog900 and I have been looking more into this paper. IMHO, the paper doesn't meet the appropriate standard for seriously considering deploying Clover on the Monero network. Maybe it's a good protocol, but the paper doesn't prove and/or provide enough evidence for that hypothesis. 18:04:54 Question to the group: Would you like me and/or boog900 to write a technical review of Clover, like I did Goodell, Salazar, & Slaughter (2024). "Uniformly Most Powerful Tests for Ad Hoc Transactions in Monero": https://github.com/cypherstack/churn/issues/2 18:05:00 That way, you don't have to just "trust me" on it. 18:05:14 Two big issues I see right now are 1) Lemma 2 seems to have wrong assumptions, 2) They seem not to be measuring macro-averaged precision, which is what the Dandelion++ papers do. Instead, they may be using single-node precision, which makes less sense in the problem context. 18:05:18 I did not see your review! 18:05:32 bedtime reading :) 18:06:08 Ah, I should have contacted you directly. IIRC, I pinged Diego S. about it 18:06:35 Stay with us, since I'm going to reference your work in the next agenda item, too :D 18:06:39 I did share it in internal chats 18:06:55 Thanks, Diego 18:09:30 Yeah I'd read that ! Especially since it gets brought up so often as an alternative to D++ and has a lot of nice nominal properties, assuming that it actually works 18:10:13 Sounds good. I will probably have something by next meeting. 18:10:20 I think your criticism of the CS churn paper was well-founded, perhaps such a piece about Clover would encourage the authors to improve the paper, and maybe get it to a point where Monero is confident enough to use it instead of D++ 18:10:59 6) Yang, Xu, & Zhu (2025). "De-anonymizing Monero: A Maximum Weighted Matching-Based Approach." https://moneroresearch.info/260 18:11:24 Thanks xmrack for finding this paper. It was posted just last week. 18:12:04 I read the paper 18:12:14 TL;DR: The paper tries a new graph-based attack on Monero user privacy. It's not very effective because 1) it doesn't have a good way to get initial edge "weights", i.e. the initial probability that a ring member is a real spend and 2) even when it does have good weights, the new technique doesn't add much more predictive power. 18:12:27 They suggest a "maximum weighted matching" (MWM) technique to try to re-construct the true transaction graph. I think this may be similar or identical to the "maximal matching" idea in a draft MRL research bulletin by Surae and Sarang that was never completed: "Disclosure Attacks and Privacy on Blockchains". 18:12:43 As I understand it, they start with initial probabilities that each ring member is the true spend (i.e. weights on the edges of the possible tx graph). Then they use an algorithm to figure out what is the most likely true tx graph. They use a new approximation algorithm from a 2022 paper, because trying a traditional algorithm would be computationally infeasible for the Monero blockchain. 18:13:04 But it looks like they don't get much additional predictive power, beyond what their initial probability weights give them. The closest thing to a head-to-head comparison is an F1-score of 0.8362 for the original guess-newest heuristic that Moser et al. (2018) use, which increases to 0.8400 when they add the MWM technique. IMHO, they should have had more comparisons. 18:13:17 isthmus speculated that the MAP Decoder attack, enabled by the OSPEAD estimates, could be used for initial weights for this type of analysis, increasing its power. IMHO, the results from this paper suggest that isthmus's fear may have been unfounded after all. 18:14:19 This just adds to the evidence that graph analysis at current ring size isn't very effective. Other evidence in the DM decomposition paper and my analysis of adding the DM decomposition to the flooding attack. 18:14:23 IMHO 18:14:42 Funny how much research those rings attract :) 18:15:18 The DM decomposition paper: Vijayakumaran, S. 2023, Analysis of CryptoNote Transaction Graphs using the Dulmage-Mendelsohn Decomposition https://moneroresearch.info/39 18:17:56 rbrunner: no wonder, they're the weakest link in the chain :) 18:19:12 Two other minor complaints: They say that spending patterns of output age are stable over time, but it's not true IMHO. If you look at transparent coins like BTC, BCH, LTC, and DOGE, the distributions change a lot from week to week. 18:19:14 My second minor complaint is that they make a strange choice for setting the initial probability weights. They sat it to just the value of the gamma or pareto probability distribution, when they should be considering the ratio of the decoy distribution (which is gamma) and the real spend, like the MAP Decoder does. 18:21:50 [waiting on people typing] 18:22:03 > They sat it to just the value of the gamma or pareto probability distribution, when they should be considering the ratio of the decoy distribution (which is gamma) and the real spend, like the MAP Decoder does. 18:22:04 Do you feel like that would have a meaningful impact on their research, perhaps tip in into being "slightly useful" category at determining true spends over what data is already in the weights? 18:22:19 they do not measure their effectiveness - do they ?? 18:24:12 jeffro256: Maybe. AFAIK, they didn't publish their code. It could be "interesting" to re-run their technique with OSPEAD/Map Decoder. But it would not be a good use of time to re-implement their technique from scratch. 18:25:04 But the way to defeat the technique is to have a better decoy selection algorithm, anyway. 18:26:10 18:27:27 They measure effectiveness against three datasets: the Moser et al. (2018) real txs that were de-anaonymized using the zero-decoy technique. xmrack 's testnet/stagenet txs that he generated and wrote his own paper about, 3) A set of completely sythetic datasets that they generated to test sensitivity of their results to ring size and decoy selection algorithm 18:28:02 they do: p.12 ~2% and "Monero's current anonymity remains robust" 18:28:27 > Experiment results reveal that the sampling algorithm plays a crucial role. 18:29:32 ^ which is a point many papers make. I list those papers and quotes at the top of https://github.com/Rucknium/OSPEAD/blob/main/CCS-milestone-1/pdf/PRIVATE-OSPEAD-Fully-Specified-Estimation-Plan.pdf 18:30:37 @rucknium:monero.social what are the fringe cases - after fcmp++ ? 18:30:41 That 2% gain over uniform random guessing is with xmrack 's data, who found similar gain using machine learning techniques. 18:30:59 The major ones are in network privacy IMHO 18:32:04 And post-quantum cryptography AFAIK 18:32:15 7) Release of OSPEAD HackerOne and CCS milestone submissions. Analysis of risk of new decoy selection algorithm without a hard fork. https://github.com/Rucknium/OSPEAD https://gist.github.com/Rucknium/fb638bcb72d475eeee58757f754acbee 18:32:31 I have xmrack 's machine learning code working with the simulated old/new DSA ring data: https://github.com/Rucknium/Monero-Dataset-Pipeline 18:32:37 I'm having a computational scaling problem at the moment. 10,000 rings works without errors, but it appears to create overfitting. When I try to increase it to 1 million, it is taking 12 hours and counting. This is on one of the powerful MRL research computing machines. 18:32:56 That's all on that update 18:34:00 Does this actually create real, signed ring MLSAG/CLSAG signatures ? 18:34:59 jeffro256: xmrack 's code does. What I'm doing is simulating rings and the rings of their one-hop antecedent txs, then feeding the data directly into the machine learning part. 18:35:19 *machine learning part of xmrack 's code in that repository 18:36:50 I just did a few updates to get things working with current Python module versions, and using .csv files instead of Python's Pickle file format. 18:36:55 Without knowing anything else about that pipepline, perhaps this could be a target for optimization. `wallet2` transaction creation in general is very slow and unoptimized, and will be noticeable for the large numbers of transactions that you're simulating 18:38:09 I'm not directly using the wallet2 tx construction code in that repo for what I'm doing right now. The slowdown is in the ML analysis part. 18:38:22 Ah 18:38:57 Okay I'm out of my depth now 18:39:32 I use R to generate the simulated data: https://github.com/Rucknium/OSPEAD/blob/main/CCS-milestone-2/decoyanalysis/R/monte-carlo.R#L122-L478 18:40:29 How long does that portion take? 18:41:38 The R code? Well, I worked a little hard to make it faster :) 18:41:40 About 5-10 minutes for 1 million rings and each of the ring member's antecedents. 18:42:41 `m + m^2 = 272` columns of data. 18:43:18 And I added decent documentation :D 18:43:48 We can end the meeting here. Thanks everyone. 18:43:58 Dang... 18:45:28 The slow part was the intra-ring sorting by age, which was xmrack 's convention. (I'm not sure how much it affects the ML analysis, but I wanted to stick to his work.) 18:46:35 The other slow part (labor time, not computational) was the technical debt I put myself in when I wrote the initial version that used a 3-dimensional array 😅 18:46:56 Which seemed clever and reasonable at the time. 18:51:44 R doesn't use a crypto-secure RNG by default. It uses Mersenne Twister as default. AFAIK, that would be a lot faster than a crypto-secure RNG. 18:53:01 I also ignore "collisions" within a ring since I use draw with replacement. That decision shouldn't affect the results much. 19:08:51 Rucknium: If you're bottlenecked by RNG, there's much faster options. Anything premised on the AES round function will be hardware accelerated to all hell. 19:10:30 kayabanerve: Thanks. Good to know. I'm not bottlenecked by RNG in this task. 19:13:43 Well, not explicitly if bottlenecked, but burdened :p