<m​onerobull:matrix.org> reddit.com/r/monerosupport/comments…dk6v/ring_members_position_question

<m​onerobull:matrix.org> thinking about it for 1 second, probably complete nonsense

<m​onerobull:matrix.org> do ring memebers even have a position number?

I answered. He's been pretty annoying everywhere with this question.

They are ordered, yes. By chain age.

Internally, the list is of positive deltas from the preceding one.

<a​ntilt:we2.ee> 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.

"The most recent output" heuristic was a thing before, but I think the current decoy algorithm fixed it?

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.

Now, it might be that the decoy selection parameters need tweaking after all this time, I dunno.

need to repeatedly spend outputs that are 1 week old in order to see if they ever appear last?

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.

(assuming post RCT outputs(

That's also why if you spend very old outputs, they're 99.999% certain to be the first ring member.

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.

<r​ucknium:monero.social> MRL meeting in this room in two hours.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1189

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

Hello

<b​oog900:monero.social> Hi

<c​haser:monero.social> hello

<j​berman:monero.social> *waves*

<b​randon:cypherstack.com> hola

<v​tnerd:monero.social> Hi

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

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> surae: Do you want something added to the agenda?

<v​tnerd:monero.social> me: still working on lws-frontend subaddresses (primarily) among other things related to that frontend project

<b​randon:cypherstack.com> nope, just observin'

<j​berman:monero.social> 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: github.com/seraphis-migration/monero/pulls

<j​effro256:monero.social> Howdy

<r​ucknium:monero.social> 3) FCMP alpha testnet, stressnet, and public testnet planning.

<j​effro256:monero.social> 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

<a​ntilt:we2.ee> ⏳️

<r​ucknium:monero.social> 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

<j​effro256:monero.social> tobtoht: mentioned that he already got Carrot/FCMP++ transaction construction working in Feather wallet which is really cool IMO

<r​ucknium:monero.social> We know when the coding competition will end, so when might the alpha testnet start?

<j​effro256:monero.social> 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

<j​berman:monero.social> I think we can call the alpha testnet an alpha stressnet instead

<j​berman:monero.social> 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

<j​berman:monero.social> Main stressnet: I agree I think we can target for 1 month after the coding competition ends

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> I want alpha stressnet to hit problems first

<j​effro256:monero.social> 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

<j​berman:monero.social> to be clear, wasn't proposing doing that on the testnet. Was assuming it would be a throwaway stressnet like last one

Yes, for sure don't make regular Monero testnet blockchain too big

<r​ucknium:monero.social> I deferred to jeffro and jberman. jberman deferred to jeffro. Everyone is looking at jeffro256 👀

<j​effro256:monero.social> Okay you're proposing doing a throwaway network but not making a distinction between stressnet and non-stressnet at first?

<j​effro256:monero.social> At least for "alpha"

<j​effro256:monero.social> Yeah I'm good with that !

<j​berman:monero.social> It would be called "alpha stressnet" so distinct from non-stressnet

<j​effro256:monero.social> Carrot, without multisig nor pratical hardware device support, should definitely be ready (and hopefully a bit more polished) in 3 weeks

<j​berman:monero.social> (I've held off on discussing public testnet for now, because I think makes sense to settle on the stressnets first)

<j​berman:monero.social> Awesome so we're on a similar timeline basically :)

<j​effro256:monero.social> 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

<j​berman:monero.social> Proposing we target an alpha stressnet in 5 weeks then?

<r​ucknium:monero.social> 5 weeks sounds great to me

<r​ucknium:monero.social> Does this include the `monero-wallet-cli` and `monero-wallet-rpc` binaries?

<j​effro256:monero.social> Yes

<j​berman:monero.social> 5 weeks would be May 21st

<r​ucknium:monero.social> Anyone object to initiating the alpha stressnet on May 21st?

<r​ucknium:monero.social> I think that's settled. :D

Awsome

<r​ucknium:monero.social> Unless there are big unforeseen problems

<j​berman:monero.social> ACK/NACK on the date from jeffro I think would be good too

<j​effro256:monero.social> ACK on May 21st

<r​ucknium:monero.social> 4) Decide on publicising the method to find proxy nodes. monero-project/research-lab #126

<r​ucknium:monero.social> boog900 wanted to bring this up

<j​berman:monero.social> Wait hang on, we can set up targets for the other nets too

<r​ucknium:monero.social> Ok

<j​berman:monero.social> Proposing 1 month after competition ends for main stressnet

<j​berman:monero.social> August 27th

<j​berman:monero.social> whoops sorry, July 27th*

<j​effro256:monero.social> Will we need a whole month to setup?

<r​ucknium:monero.social> jberman: Sounds good to me.

<r​ucknium:monero.social> I don't know how long it will take to test and integrate the competition code

<j​berman:monero.social> 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)

<j​berman:monero.social> which could take 1-2 weeks

<j​berman:monero.social> 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?

<r​ucknium:monero.social> That sounds reasonable to me

<j​effro256:monero.social> 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

<j​effro256:monero.social> Although not setting the date until a couple days before sort of defeats the purpose of setting a date

<r​ucknium:monero.social> I think at least 2 weeks of notice for stressnet would be good.

<j​berman:monero.social> Sounds good to me, we can loosely say here we're targeting that proposed date at the latest, but may set it earlier

<j​berman:monero.social> Or just say we're targeting July for main stressnet without specifying the day

<j​berman:monero.social> Until we're ready to (with at least 2 weeks of notice)

<r​ucknium:monero.social> "Targeting July" sounds good

<j​effro256:monero.social> I think a vague-ish time period is fine for testing networks

<r​ucknium:monero.social> Are we ready to move on to the next agenda item?

<j​berman:monero.social> Last thing

<j​berman:monero.social> 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

<j​berman:monero.social> More conservatively we'd give that 6 months

<j​berman:monero.social> So perhaps we target Q4 for public testnet?

<r​ucknium:monero.social> Sounds good to me

<j​berman:monero.social> Alpha stressnet: May 21st

<j​berman:monero.social> Main stressnet: July

<j​berman:monero.social> Public testnet: Q4

<r​ucknium:monero.social> How much code auditing and mathematics review would be done by then? Nearly all?

<j​berman:monero.social> Should be all

<r​ucknium:monero.social> There is a nice symmetry about the dates. Getting one unit vaguer on each step.

<r​ucknium:monero.social> Which would give FCMP++ mainnet 2026. :P

<r​ucknium:monero.social> 4) Decide on publicising the method to find proxy nodes. monero-project/research-lab #126

<r​ucknium:monero.social> boog900

<b​oog900:monero.social> 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.

<b​oog900:monero.social> We do have other methods to tell apart these nodes, although we would be revealing the best one IMO.

<b​oog900:monero.social> 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.

<b​oog900:monero.social> Just want to get opinions from MRL before I make it public, does anyone disagree with making it public?

<j​berman:monero.social> No disagreement here

Sounds good.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> binary release version*

<j​effro256:monero.social> 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

<j​effro256:monero.social> Especially since it seems like a semi-smart coder could fix the issue relatively quickly

<d​oedl...:zano.org> [flip flop] lets focus on subnet deduplication impl

<b​oog900:monero.social> 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.

<j​effro256:monero.social> Well they can't fix many proxies within a small subnet, but they could fix the identifying issue

<j​effro256:monero.social> 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

<d​oedl...:zano.org> ??

<d​oedl...:zano.org> downsides?

<r​ucknium:monero.social> Can't un-ring a bell

<r​ucknium:monero.social> Ah, it has its own Wikipedia article: en.wikipedia.org/wiki/Unring_the_bell

<r​ucknium:monero.social> > In law, unring the bell is an analogy used to suggest the difficulty of forgetting information once it is known.

<d​oedl...:zano.org> dedup'ing subnets without revealing the tracing methodology - thats what I meant, of course

<d​oedl...:zano.org> are there any open questions on how to impl dedup'ing ?

<r​ucknium:monero.social> I don't think so. Just need someone who knows or can read the Monero netcode to implement it, AFAIK.

Yes, it may take some time until somebody comes around to do it

But still, that does not fully change the equation for me: more on the "plus" side of publishing the method

IMHO

<j​effro256:monero.social> 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

<b​oog900:monero.social> 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.

<d​oedl...:zano.org> From your research the method ca be guessed ? So why publish at all ?

<r​ucknium:monero.social> 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).

<r​ucknium:monero.social> Or I can push those item to next week instead

<c​haser:monero.social> I'm sure this can wait at least another week

<b​oog900:monero.social> 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.

<b​oog900:monero.social> yes

<r​ucknium:monero.social> 5) Franzoni & Daza (2022). "Clover: An anonymous transaction relay protocol for the bitcoin P2P network". moneroresearch.info/222

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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": cypherstack/churn #2

<r​ucknium:monero.social> That way, you don't have to just "trust me" on it.

<r​ucknium:monero.social> 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.

<b​randon:cypherstack.com> I did not see your review!

<b​randon:cypherstack.com> bedtime reading :)

<r​ucknium:monero.social> Ah, I should have contacted you directly. IIRC, I pinged Diego S. about it

<r​ucknium:monero.social> Stay with us, since I'm going to reference your work in the next agenda item, too :D

<d​iego:cypherstack.com> I did share it in internal chats

<r​ucknium:monero.social> Thanks, Diego

<j​effro256:monero.social> 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

<r​ucknium:monero.social> Sounds good. I will probably have something by next meeting.

<c​haser:monero.social> 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++

<r​ucknium:monero.social> 6) Yang, Xu, & Zhu (2025). "De-anonymizing Monero: A Maximum Weighted Matching-Based Approach." moneroresearch.info/260

<r​ucknium:monero.social> Thanks xmrack for finding this paper. It was posted just last week.

<r​ucknium:monero.social> I read the paper

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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".

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> IMHO

Funny how much research those rings attract :)

<r​ucknium:monero.social> The DM decomposition paper: Vijayakumaran, S. 2023, Analysis of CryptoNote Transaction Graphs using the Dulmage-Mendelsohn Decomposition moneroresearch.info/39

<c​haser:monero.social> rbrunner: no wonder, they're the weakest link in the chain :)

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> [waiting on people typing]

<j​effro256:monero.social> > 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.

<j​effro256:monero.social> 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?

<d​oedl...:zano.org> they do not measure their effectiveness - do they ??

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> But the way to defeat the technique is to have a better decoy selection algorithm, anyway.

<j​effro256:monero.social> <insert OSPEAD ad here>

<r​ucknium:monero.social> 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

<d​oedl...:zano.org> they do: p.12 ~2% and "Monero's current anonymity remains robust"

<r​ucknium:monero.social> > Experiment results reveal that the sampling algorithm plays a crucial role.

<r​ucknium:monero.social> ^ which is a point many papers make. I list those papers and quotes at the top of github.com/Rucknium/OSPEAD/blob/mai…Fully-Specified-Estimation-Plan.pdf

<d​oedl...:zano.org> @rucknium:monero.social what are the fringe cases - after fcmp++ ?

<r​ucknium:monero.social> That 2% gain over uniform random guessing is with xmrack 's data, who found similar gain using machine learning techniques.

<r​ucknium:monero.social> The major ones are in network privacy IMHO

<r​ucknium:monero.social> And post-quantum cryptography AFAIK

<r​ucknium:monero.social> 7) Release of OSPEAD HackerOne and CCS milestone submissions. Analysis of risk of new decoy selection algorithm without a hard fork. github.com/Rucknium/OSPEAD gist.github.com/Rucknium/fb638bcb72d475eeee58757f754acbee

<r​ucknium:monero.social> I have xmrack 's machine learning code working with the simulated old/new DSA ring data: github.com/Rucknium/Monero-Dataset-Pipeline

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> That's all on that update

<j​effro256:monero.social> Does this actually create real, signed ring MLSAG/CLSAG signatures ?

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> *machine learning part of xmrack 's code in that repository

<r​ucknium:monero.social> 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.

<j​effro256:monero.social> 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

<r​ucknium:monero.social> 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.

<j​effro256:monero.social> Ah

<j​effro256:monero.social> Okay I'm out of my depth now

<r​ucknium:monero.social> I use R to generate the simulated data: github.com/Rucknium/OSPEAD/blob/mai…yanalysis/R/monte-carlo.R#L122-L478

<j​effro256:monero.social> How long does that portion take?

<r​ucknium:monero.social> The R code? Well, I worked a little hard to make it faster :)

<r​ucknium:monero.social> About 5-10 minutes for 1 million rings and each of the ring member's antecedents.

<r​ucknium:monero.social> `m + m^2 = 272` columns of data.

<r​ucknium:monero.social> And I added decent documentation :D

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

<j​effro256:monero.social> Dang...

<r​ucknium:monero.social> 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.)

<r​ucknium:monero.social> 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 😅

<r​ucknium:monero.social> Which seemed clever and reasonable at the time.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> I also ignore "collisions" within a ring since I use draw with replacement. That decision shouldn't affect the results much.

<k​ayabanerve:matrix.org> 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.

<r​ucknium:monero.social> kayabanerve: Thanks. Good to know. I'm not bottlenecked by RNG in this task.

<k​ayabanerve:matrix.org> Well, not explicitly if bottlenecked, but burdened :p