01:50:36 <neptune[m]> <secparam[m] "For what its worth, i'd cross ch"> Hey secparam, I've cross checked your analysis and found it to be correct. I also found two suggestions. Wrote it up: https://github.com/neptuneresearch/monero-ringmember-age-distribution
01:51:26 <neptune[m]> <jberman[m] "ya, I think more rigorous analys"> Did some plots for this too: https://github.com/neptuneresearch/monero-ringmember-age-distribution#v11-ringct-ringmember-age-distribution-1788720---1978433
01:52:39 <neptune[m]> > <@jberman:matrix.org> Got a similar result as you: peaks of either 11 or 12 blocks over different intervals going back to the time around when block density was factored in, with a smooth observed distribution.
01:52:39 <neptune[m]> > 
01:52:39 <neptune[m]> > To me, this suggests there isn't some issue with the decoy selection algo we're not seeing, and real spents are hidden well among the decoys
01:52:39 <neptune[m]> I agree it's smooth:
01:52:48 * neptune[m] uploaded an image: (20KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/YXuNongeuhCnPtoCBULgNLFC/v14rct.png >
01:52:58 <neptune[m]> ^ HF v14 (block 2210720-2402699) RingCT ringmember age distribution
02:29:24 <jberman[m]> Awesome work neptune. Agreed the 2 suggestions are useful to factor into the analysis
04:20:03 * jberman[m]  < https://libera.ems.host/_matrix/media/r0/download/libera.chat/559470a377c8e1d550d595766a7205e13363db2b/message.txt >
04:20:39 <jberman[m]> Code I added to blockchain_usage.cpp to get these values: https://paste.debian.net/1205083
17:02:40 <h4sh3d> We talked about a meeting regarding the tax chaining/binning/etc proposal that should be around now. Anyone around?
17:11:36 <moneromooo> I am here if needed.
17:21:57 <h4sh3d> hi moneromooo :)  I guess with the latest scope redefinition this meeting was not anymore needed
17:55:50 <gingeropolous> scope redefinition?
18:15:07 <h4sh3d> IIRC the tx chaining was removed no?
19:05:48 <gingeropolous> roight roight
20:51:51 <secparam[m]> <jberman[m] "secparam the thing I still bel"> So thats entirely possible. I'm by no means a statistical expert and all we did was plot the gamma distribution  stretched from a log plot to a linear.
20:53:20 <secparam[m]> That said,  the data from https://arxiv.org/pdf/1704.04299.pdf says that the mean should be about 1.8 days.
20:55:57 <secparam[m]> I don't think the mean is 1.8 days for the current decoy selection algorithm.  So either 1) somehow, its actually still 1.8 days 2) monero decided to use a different mean for some reason  3) (and this is what worries me) the decoy selection algorithm is supposed to do what the paper says (after all, it does use the same rate and shape) BUT there's a major bug
20:56:31 <secparam[m]> In particular,  the paper is using a gamma fit to a LOG PLOT of TX times. So it would be necessary to stretch the distribution back out to use it in production.  
21:02:31 <secparam[m]> The net result of this, if that's true, is that you are actually selecting decoys WAY WAY faster than baseline spending rates.
21:23:05 <jberman[m]> I think the issue is in thinking that the peak == mean. Pretty sure the mean block height would be calculated like this:
21:23:05 <jberman[m]> Numerator: for every block height, take frequency * block height, then sum all that up
21:23:05 <jberman[m]> Denominator: for every output, take block height and sum it up
21:23:05 <jberman[m]> This would give you the mean block height. But the median is probably a more useful metric given the long tail
21:23:30 <jberman[m]> In data I have locally, I checked what percentile the first output of the 1300th block falls under, and found it was between 47% and 56% depending on the interval.
21:23:30 <jberman[m]> That would concur with the expectation that ~50% of outputs fall below 1300 blocks, and ~50% of outputs are above 1300 blocks
21:26:14 <jberman[m]> My initial reasoning for thinking the expectation was off is because you would likely observe on-chain spikes or humps 1300 blocks out if the decoy selection algorithm is missing that outputs are more likely to spent that far out (the real spents would push up the observed frequencies around there). I don't think the on-chain data would be smooth if an issue like this were present
21:32:06 <jberman[m]> * Denominator: sum up each unique block height in the range (don't sum for every output)
21:34:55 <jberman[m]> Something like the pink graph is what I think the on-chain data would look like if that were accurate: https://oxfamblogs.org/fp2p/wp-content/uploads/2019/03/global-income-distn-1974.png
22:03:03 <gingeropolous> secparam[m], you mean fig 11, re: "LOG PLOT of TX times"
22:10:17 <secparam[m]> gingeropolous:  yep, fig 11.   And the surrounding text. It was fit to a log plot.  Confirmed with the authors. 
22:11:49 <secparam[m]> But i agree, if the entire thing is smooth, then it's far less likely this is actually happening.
22:16:40 <secparam[m]> And just to make a point, if you do take the given gamma distribution with the shape and rate specified in the paper, you get https://www.wolframalpha.com/input/?i=gamma+distribution++shape+%3D+19.28++scale+%3D+%281%2F1.61%29
22:18:50 <secparam[m]> Which has the mean we'd expect ( shape/rate = about 12).   I don't know how to possibly square that with the papers claim that the mean is 1.8 days. the CDF doesn't match.