^ Here is an analysis of the evolution of the distribution of spent output age on BTC, BCH, LTC, and DOGE.

Source code here: github.com/Rucknium/OSPEAD/tree/mai…ral-Blockchain-Age-of-Spent-Outputs

Thanks to xmrack for early feedback, gingeropolous for server administration, and CCS donors for the storage required for the intermediate data processing on the research computing server.

The analysis of the transparent blockchains helps inform statistical modeling choices for improving the Monero decoy selection algorithm.

The main surprises in the analysis are:

1) The age distribution is quite unstable from week to week. In general I expected a sort of gradual evolutionary trend over time. The instability probably is caused by exchange rate volatility. Moser et al. (2018) claimed that the Monero real spend age distribution was stable over time. I didn't believe it when I read it and I definitely don't believe it now after analyzing the major transparent UTXO means-of-payment

blockchains.

Therefore, we (I) need to pay close attention to dynamic risk. OSPEAD is static in nature -- that is what the "S" in the acronym stands for.

2) There was not a strong correlation across blockchains in the mean nor standard deviation of the age distributions. However, there was a substantial correlation for the skewness and kurtosis, which correspond to the 3rd and 4th statistical moment of distributions. This makes some sense since skewness and kurtosis describe what is happening in the tails of distributions.

When there is cryptosphere-wide volatility in the cryptocurrency exchange rates, it is likely for old coins of all blockchains to "wake up" and participate in speculative activity in exchanges. I expected to see the correlations in the means, too, however.

Some things that were not surprising to me:

1) There is a daily cycle in the data. This probably corresponds to the sleep-wake cycle. Ronge et al. (2021) "Foundations of Ring Sampling" also noticed this in BTC. See their Figure 4.

2) I chose to test just two fitting distributions for simplicity at this stage: Log-gamma (lgamma) and Right-Pareto Log-normal (rpln). lgamma is what Moser et al. chose to fit. lgamma has just two parameters. rpln has three. Therefore, rpln is inherently more flexible than lgamma. In general, rpln fit the empirical distributions better.

3) In the forecasting step, taking the "interval" of 8 weeks as the forecasted distribution tended to perform better than just taking the most recent (i.e. last) week or doing more sophisticated forecasting. I think the sophisticated forecasting can be improved. I just took a standard forecasting technique with default options at this stage for demonstration purposes.

If changes in the age distribution are mostly caused by exchange rate volatility, then forecasting will have high inherent difficulty since forecasting the age distribution would be almost equivalent to forecasting exchange rate volatility, which is obviously difficult (see efficient market hypothesis).

My guess is that Monero transactions are slightly less likely to respond to exchange rate volatility compared to BTC/BCH/LTC/DOGE given that Monero is listed on fewer exchanges, but I think Monero still responds somewhat strongly to exchange rate volatility.

Any comments or questions are welcome.

Excellent. Is the data about the mean/median/std etc. available in a raw format? Some of the charts are too tiny to be readable.

tevador: I could post it. Right now it is in R data format. Would you like CSV format?

Any human-readable format is fine. Thanks!

For example, the BTC median is a line close to 0 with a single spike in 2018. I'd like to see a zoomed in version.

Ok. Just a few moments...

Overall, the median appears to be the most stable marker, apart from short periods of instability. But it may be just due to different relative ranges of the y-axis.

tevador: CSV files are in

Let me know if the format is OK

Perfect, thanks.

Meeting in 40 minutes

<Rucknium[m]> "^ Here is an analysis of the..." <- 🚀

<Rucknium[m]> "rucknium.me/html/spent-..." <- Woah

meeting time monero-project/meta #725

1. greetings

hello

Hello

Hi

Hi

Hi

hello

2. updates, what's everyone working on?

Published my X25519 code, now I'm back to updating the Jamtis specs.

me: finished legacy balance recovery for my seraphis library, started unit testing it

As mentioned above, an analysis of the evolution of the distribution of spent output age on BTC, BCH, LTC, and DOGE:

Source code here: github.com/Rucknium/OSPEAD/tree/mai…ral-Blockchain-Age-of-Spent-Outputs

I have just been reading a lot about the different zero knowledge schemes and I started scanning the blockchain (BP and so forth) in Rust now.

Nothing research related on my end, looking out for things that need doing to make sure the hard fork goes smooth (pool update, PR review, etc)

jberman[m]: btw, it should be possible to hook up the seraphis lib to do balance recovery with the current chain, with a bit of work; might be an interesting project (which would be a good proof of concept for a future real wallet)

3. discussion

noted :)

Did anything jump out already from that spent output age evolution that would give hints how to change something for Monero?

Or is still early days?

Looks interesting, in any case.

I had a look at Rucknium[m]'s excellent write-up. I'd try to fit some simpler PDF function as opposed to a very complex one. A shifted Pareto is one option. It's basically a power function. Might be enough just to fit the general trend.

So basically it's outlining the final step, which is forecasting.

We want to get a sense of the variability of other blockchains so we can know what sort of risk profile we may be facing from the forecast step.

What was the trend? Was, in your gut feeling, variability high or low?

tevador: Thanks for the feedback. Right now the general direction I'm heading in is to test out some mixture distributions to have some flexibility. Basically, combine two or more parametric distributions. And then _maybe_ add something to account for the 24-hour cycle, like a periodic Laplace distribution.

But the final decision is going to be determined by the performance, taking into account to not overfit

Unfortunately I do not have the "documentation" published yet, but here is an image of some distributions fit according to the loss function criteria in what I published above: github.com/Rucknium/OSPEAD/blob/mai…imate-div-target-L_FGT-flavor-1.png

^ This is a "dry run" based on the old Moser et al. (2018) data for demonstration purposes

And it displays the ratio so that it's clearer how well the distributions fit

I am working on the "documentation" for the chart

rbrunner: Variability in the spent output age distribution for those 4 blockchains was higher than I expected.

Ok, interesting

Which means that the "dynamic risk" for a static Monero decoy selection algorithm would be higher if Monero's distribution is similarly unstable

The "S" in OSPEAD stands for Static, so a fully dynamic DSA is pushed off for further research. But it is important to know the risk rather than ignore it.

All my ducks are in a row for OSPEAD. "Just" need to write it up, present it to the review panel, and then do the necessary estimations.

hmm, any other questions/comments/topics people want to bring up?

By the way, a while ago I paused the project to estimate the effect of minexmr's increased pool fee on their share of hashpower, but I want to go back to it eventually. I have mostly settled on a model and I was waiting on more data, i.e. more time to pass. The preliminary results suggested very little effect, if any.

And now they will close :)

Yes, but if nanopool takes their role....we may want to put more effort into trying to resolve the challenges of tevador 's anti-pool proposal.

So far it doesn't look good: miningpoolstats.stream/monero

Or, anti-centralized pool. Pro-p2pool :)

UkoeHB: Yes, I would like to help developing the wallet (or what is needed) for Seraphis so we could have a working full prototype asap. How is the overall project being coordinated and how exactly I could help?

Any question concerning Seraphis with the word "exactly" in it is still quite risky ...

not too much coordination so far, I'm just trying to finish the library so I can hand it off

here are some proposed changes to the Jamtis key hierarchy: gist.github.com/tevador/50160d160d2…52ae02eb3d17024#gistcomment-4259423

yes I still need to look at that (on vacation and focusing on legacy integration)

Yeah, I see it is a bit vague now but someday maybe it will be reality :p

Also I'd like to remove "certified addresses" from the main specs. It's better to move it to the future invoice specs. I hope UkoeHB hasn't implemented it yet :P

a good starting point is to look at unit tests and get an understanding how the library is put together

tevador: Nice. I will start participating on this discussion soon.

Becomes a bit more complex with X25519

tevador: I only implemented core features

UkoeHB: Ok!

this is what I'm using for unit tests github.com/UkoeHB/monero/blob/6272b…rc/seraphis/jamtis_core_utils.h#L60

btw, my proposed change has one extra key

yeah

UkoeHB: are you using Blake2b or Keccak?

blake2b github.com/UkoeHB/monero/blob/6272b…/seraphis/sp_hash_functions.cpp#L60

cool

ok I think we can wrap it up here, thanks for attending everyone

given the existence of multiple implementations of the decoy selection algorithm, can you unambiguously identify which algorithm produced an arbitrary ring?

Thank you for the work guys :)

hyc: Any such identification, if possible, would be probabilistic, not deterministic.

if not, then seems to me you can't make any deterministic conclusions about any particular ring. and, in that case it's a strength to have multiple implementations, not a single uniform implementation in all wallets.

A bit more precise: if a certain DSA always "skipped" certain ranges of blocks and you observed that a ring chose more than one ring member from that interval of skipped blocks (must be more than one since one could just a be the real spend), then you could deterministically rule out a particular DSA.

However, all the good DSAs do not skip blocks.

anyway, this seems to me a strong argument against enforcing a single algorithm at consensus layer

it depends how different the alogs are. openmonero's was so different from wallet2's that txs could be tied to that implementation with what seemed to me a solid degree of accuracy to me when I eyeballed it searching for txs, though I never ran any sort of statistical tests. I could also make a solid guess as to an openmonero user spending change from a prior tx (tx A -> tx B, both use clearly non-standard implementation) since

so few people used that algo

I’d argue for a single DSA at consensus level. As jberman described, giving wallet designers choice can lead to anonymity puddles. hyc I’ve been thinking about creating a small dataset of 3-4 different DSAs to see how well an unsupervised learning algo could cluster different wallets.

I believe you shouldn't be able to use txextra or rings to gather metadata (aside from perhaps coinbase tx)

2c

To add: probabilistically distinguishing DSAs sounds weak, but in certain cases we could be literally talking about 99.999% probability. I think with ring size even as low as 11 you could reject the null hypothesis that a uniformly-selected ring was selected from the specified Log-gamma distribution with 1 - machine_precision probability with a Kolmogorov-Smirnov test.

I will have to find the bit of code I wrote.

By the way, the K-S test is somewhat weak since it is very general. A while ago I found a few gamma-specific tests that had a statistical power (i.e. capability of distinguishing distributions) of 50% greater than the K-S test.

You can check the references here: cran.r-project.org/package=gofgamma

Monero's current DSA is a slight modification of the gamma distribution, so I'm not sure if the tests would be valid.