has anyone ever calculated the distribution of the time it takes for a new Monero output to be used as a decoy 1, 2, 3, ..., n times?

chaser: its most likely a poisson distribution, youd have to estimate the time constant, which usually the average number of events (outputs in this case) per unit time (essentially an average rate of outputs)

this would be essential to know to reason about Monero's privacy

when Alice sends XMR to Bob, (ring size)^(number of transactions in the chain backward that are unrelated to Bob) is a sensible estimation of Alice's anon set from Bob's perspective. but so far I haven't seen such an estimation for when after Alice *receives* XMR from Bob. ("on average, how long does Alice have to wait before spending this output to have an anon set of N from the perspective of Bob?")

im not a cryptographer i wish i could answer your question better

I don't think that's a cryptography question.

i dont know enough about how blockchain works and the background material to answer confidently

chaser: The framing of your question doesn't really make sense to me. Why is the anon set only those transactions that have used the target output in a ring _before_ the real spend, and not after?

The anon set is the set from before and after the real spend, since the real spend is (hopefully) unknown with certainty.

<chaser[m]> "has anyone ever calculated the..." <- This would be fairly easy to calculate, but it doesn't answer the question you want answered.

If we just take the gamma distribution with the currently-used parameters and ignore how the "density" of spends over time fluctuates, it's a pretty easy calculation. Probably easiest to simulate it, but it can be determined analytically as well with a bit of calculus.

<Rucknium[m]> "chaser: The framing of your..." <- because I'd like to treat the worst-case scenario as the base line in this estimation. the worst case is that Alice spends that XMR as soon as possible and therefore the first ring inclusion is the real spend. the mandatory cool-down period soothes this to some degree, but its effect is limited.

<Rucknium[m]> "This would be fairly easy to..." <- why?

I don't see how that is a "worst case" when the decoy selection algorithm can select such an output as a decoy as well.

With a smart(er) decoy selection algorithm, there is no such thing as a worst case.

Rucknium[m]: let's work in a condition where there's no mandatory cool-down period. Alice spends the output in the block after it was created. the algo *can* select that output as a decoy for other transactions, but that is not guaranteed. since I'm talking about a worst case scenario, I assume it won't be used as a decoy in that block.

I do see value in talking about a worst case because with this we can tell what's the minimum expected level of privacy Monero provides

How is it worst case if an observer cannot determine if that selected output is a real spend or not?

A smart decoy selection algorithm will "re-spend" an output in the first block available in proportion to the proportion of users who re-spend an output in the first block available.

In other words, what makes the first possible block special and not the second?

<Rucknium[m]> "How is it worst case if an..." <- it's worst-case exactly for that reason -- the observer assumes it is the real spend, and his assumption in this case is right. the longer Alice leaves the output alone, the more ring inclusions it gains. this is countered by the force that Alice is a human being with a finite lifetime and she wants to transact.

Then the observer is incorrect 10 out of 11 times, roughly. That's not a concern.

If Alice repeatedly spends on the first block available -- again and again -- then yes that could be a concern since then her behavior is out of step with the rest of the blockchain. That in some ways is how we showed that this summer's transaction volume anomaly was likely due to a single actor.

"Question 2(b): Is the source one or more entities? Analyzing spend time distributions"

^ That's the section of the paper that I contributed to the most

We say to Alice: Don't foolishly re-spend in the first block possible repeatedly since your behavior might seem anomalous, attracting attention.

But that goes for pretty much any repeated pattern (re-spending exactly 1000 blocks later, etc.)

<Rucknium[m]> "A smart decoy selection algorith..." <- this is interesting. two questions:

1) to what degree is this currently the case?

2) is this mechanism not vulnerable to reflexivity? i.e. such a proportion came to be early in the DSA's lifetime, and now everyone's transactions look like that, but the real macro behavior is not like that, and whoever can ascertain the difference between the two can tell decoys away from the real input?

Which is why churning remains on the list of open questions, since it can be tricky:

chaser: This is pretty much my entire project -- to overhaul the decoy selection algorithm

<Rucknium[m]> "Then the observer is incorrect 1..." <- could you elaborate why?

Say that with some probability P a typical Alice spends her output in the first block available. Ok great.

We take that information and bake it into the decoy selection algorithm

So the decoy selection algorithm selects an output from the first block available with probability P * (M -1) where M is the ring size. 11 at the moment. In other words, it does M-1 selections, where each time an output in that first block is selected with probability P

So for every time a typical Alice spends an output in the first available block, other transactions have included an output from the first available block a total of (1-M) times, on average.

I mean, M-1