This is why it is absolutely -- absolutely -- critical to have a decoy selection algorithm that mimics the real spend age distribution as closely as possible.

Since you need other transactions to select decoys from blocks with the same frequency as real users and thereby provide "camouflage" for the real spends.

Two answer your two question, in summary, when the decoy selection algorithm greatly diverges from the real spend age distribution, then user privacy is threatened. One of the ways that Moser et al. (2018) was able to do Monero tracing was by exploiting this divergence.

There are several academic papers that point this out, too. I link them in my CCS proposal, within this sentence: "Much academic ink has already been spilled regarding the importance of having a good DSA."

Ahem, "To answer your two questions..." I meant

thanks for these explanations. the publications you referenced in your CCS are definitely way over my head, so if those could otherwise answer my questions, sorry.

No problem. In a way, your line of questioning was aimed at a true vulnerability in Monero. Or, more accurately, what would be a true vulnerability if the decoy selection algorithm is not designed well. But anyway, there is a fix, and the fix is OSPEAD. Or, at least a partial fix.

I was meaning to aim not at identifying vulnerabilities but rather at quantifying/parametrizing anonymity sets. but it's an interesting discussion anyway.

how correct would it be then to say the following?

Alice's privacy depends on how well her use of Monero blends in with others' use. in a parallel world where there's *no* mandatory cool-down period, if she spends the output she got from Bob in the block after the output was created, there's a fair chance this will be the only inclusion of that output in that block (also depending on how good the DSA is). and, as a function of the recent use of the chain, it is possible to give

probabilistic estimations of how long she has to wait until N transactions use that output as a decoy.

Assuming out of the blue that the first spend is always the real spend kinda leads to a paradox, doesn't it? If everyone assumes by default that the first spend is always "the most suspicious", then all Alice has to do is wait for someone else to include her output in a ring first. But once everyone figures out this "trick", then the initial assumption that the first spend is the most likely real spend becomes useless - thus making the possibility

of spending right away "safe" again

"it is possible to give probabilistic estimations of how long she has to wait until N transactions use that output as a decoy." Yes, this is very possible. However, with a good DSA there is no benefit to waiting a specific amount of time unless Alice feels the need to transact in a way that is completely out of line with everyone else -- as we discussed before, spamming is detectable in the aggregate.

Go with the flow and blend in.

Has anyone considered how/if quick successive spends is an issue for zec?

As long as it's z2z I can't think how it's a big issue

Maybe number of inputs or something

sers! o/

oops, wrong channel...

<Rucknium[m]> "No problem. In a way, your..." <- Speaking of which, I got my first prototype of prediction on Master of my `tsqsim`. I have a baseline algo, which just shows the previous truth value as a prediction, and it was already beaten by a simple linear regression predictor:... (full message at libera.ems.host/_matrix/media/r0/do…acc0fb952b2c58841843b48b21a07663593)

More to come. I will absolutely need to integrate Rcpp (R integration with C++), as only in R there are readily available algos, that we need.

I will make some self-developed very basic algos like ARMA and ARIMA, but in the end it's not about redesigning the wheel here.

The true value of my simulator lies in its experiment setup capabilities, not in the algos themselves.

* and in scalability.