13:36:39 Just to drop a paper: https://eprint.iacr.org/2022/1070 13:36:52 Post-quantum ring signatures with peer review 13:55:29 kayabanerve: Want to add to MoneroResearch.info? 13:57:32 I wonder how rigorous the ESORICS review process is. Hm. 19:18:14 Ooh that's neat, lattice-based ring signatures have been coming along the last few years 19:18:25 Might be also worth adding MatRiCT & MatRiCT+ 19:18:36 To the lit list 19:18:38 https://eprint.iacr.org/2019/1287.pdf 19:18:44 https://eprint.iacr.org/2021/545 19:21:11 Wasn't SIDH lattice based ? That got broken recently AIUI. Though might not apply here. 19:23:23 Nah, that supersingular isogeny stuff is based on a completely different hardness assumption 19:24:14 SIKE getting pwned on one core in an hour was pretty epic 19:46:30 Hey, it's post-quantum, nobody had said anything about pre-quantum! 19:47:42 Rucknium[m]: I'm still unsure how to tackle the huge difference between the empirical PDF from the transparent blockchains and the current gamma DSA in the first 2 hours or so: https://i.ibb.co/SsvyYdH/xmr-btc.png 19:52:43 tevador: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4274612#gistcomment-4274612 20:10:21 tevador: the xmr DSA is shifted 20 minutes because we have 10-block-lock (not a comment on your problem, but one thing to keep in mind) 20:12:41 that's not true, source code clearly says that the distribution is placed at the chain tip 20:15:10 actually, my chart is wrong because it doesn't take into account the "RECENT_SPEND_WINDOW" rule, but the discrepancy is too big to be explained by this 20:19:10 tevador: If the gamma selector would pick an output that is less than the 10 block lock, then it is re-allocated to the RECENT_SPEND_WINDOW section of the distribution due to fixes by jberman: 20:19:15 https://github.com/monero-project/monero/commit/da2955feaec3800baf34a446fda49ec482b2bbed 20:19:25 https://github.com/monero-project/monero/commit/84c52571ed6076a60c50b9a779e12fce2065325e 20:20:35 How to tackle the difference? Do you mean "how to fix the current decoy selection algorithm"? 20:21:36 Arguably, there are three levels of increasing complexity: 20:22:24 tevador: oh I guess I forgot about this PR https://github.com/monero-project/monero/pull/7821 20:24:05 1) Use a single, more appropriate and more flexible parametric probability distribution. I have demonstrated this with the Right Pareto Log-normal (rpln) distribution, which seems to be a more appropriate fit and is technically slightly more flexible since it has three parameters compared to gamma's two. 20:24:27 I'm even the one who wrote the comment explaining it... whoops 20:27:18 2) Use a mixture of parametric distributions. So, for example, let f_1 and f_2 be two parametric probability density functions (PDFs) and then the overall PDF could be f(x) = alpha * f_1(x) + (1 - alpha) * f_2(x). I do this here: https://github.com/Rucknium/OSPEAD/blob/main/images/dry-run/estimate-div-target/estimate-div-target-L_FGT-flavor-1.png 20:29:27 "Log-gamma + F Mixture" is such a mixture that mixes the Log-gamma and F (Fisher) distribution. Maybe this is easier to see the fitted distributions: 20:29:27 https://github.com/Rucknium/OSPEAD/blob/main/images/dry-run/estimate/estimate-L_FGT-flavor-1.png 20:31:23 3) Use a nonparametric estimate of the distribution through kernel density estimate. The main example of kernel density is this gem: https://github.com/Rucknium/misc-research/tree/main/Statistical-Monero-Logo 20:33:15 A nonparametric estimate is guaranteed to converge to the true distribution, whatever its shape (even if it is the Monero "M" logo), given sufficient sample size and "tuning parameter" appropriately chosen. For kernel estimation, the tuning parameter is the bandwidth. 20:34:51 ?? 20:34:54 For OSPEAD I have restricted myself to parametric distributions, which would include (1) and (2) above. The "P" in OSPEAD stands for "parametric". 20:37:17 This is because (1) nonparametric distributions can have greater risk of "overfitting" the true distribution and (2) it is much easier to drop a parametric distribution into the existing Monero code base. A nonparametric approach could be implemented with further research. 20:51:01 If the real-spend-age distribution of XMR is close to the BTC distribution, then our DSA is way off. The BTC data show that 50% of outputs are spent in ~7 hours or less. For our DSA it's over 30 hours. 20:51:13 This is the fixed plot btw: https://i.ibb.co/QHm2Tnw/xmr2-btc.png 20:51:45 includes the reallocated decoys 20:57:13 Nice to see an independent look at the problem. I arrived at your conclusion a year ago now. 20:58:58 https://ccs.getmonero.org/proposals/Rucknium-OSPEAD-Fortifying-Monero-Against-Statistical-Attack.html 21:00:32 However, Fig. 11 of Moser et al. shows a similar dicrepancy between the BTC and XMR data. 21:04:23 What is needed is a good estimate of Monero's current true spend distribution, which OSPEAD will provide. Looking at the other blockchains helps form modeling strategies, especially for dynamic risk, i.e. forecasting. 22:00:54 “nobody had said anything about pre-quantum!” LOL @mooo 22:01:06 Hmm, in terms of spend distribution representativeness, the question is which blockchain has most similar users, applications, and scale. 22:01:18 For example, Ethereum is probably not as representative because the DeFi applications drive some users to very frequent transacting to poke smart contracts, arbitrage instantaneous inefficiencies, etc. 22:01:30 TBH, I wouldn’t expect Bitcoin to be the closest. That ecosystem has a 5 years head start with a greater number of applications, and additional user demographics, e.g. institutional buy-in for Bitcoin probably orders of magnitude above that of Monero. 22:01:39 What about analysis of spend times in the Zcash transparent pool? Roughly the same age as Monero. Also targets privacy-focused applications and users. Also has less exposure than Bitcoin and Ethereum. 22:02:01 It’s not a perfect proxy, but it might be the least different of available data sets. 22:03:31 Zcash is rarely used as a means of payment. 22:04:13 More places around me that take Zcash than Monero :- P 22:04:16 According to payment processors 22:04:56 Regardless, the project profile difference between Zcash and Monero is probably less than Monero and Bitcoin 22:07:17 The reason I produced the data on BTC&BCH<C&DOGE was to see variability across time within each blockchain. 22:08:10 Makes sense, I wonder about interchain correlation too 22:08:20 I thought about DASH, too. But that requires some additional coding due to the coinjoins 22:08:31 Probably not worth the effort 22:08:47 isthmus: I covered that in the doc I linked 22:09:06 Moderated correlation with the tail-oriented summary statistics 22:09:19 Which link? Haven't been following the docs on mobile 22:09:19 3rd and 4th moments :) 22:11:10 This one: https://rucknium.me/html/spent-output-age-btc-bch-ltc-doge.html 22:11:18 Under "Cross-blockchain correlations of summary statistics across time" 22:14:20 The embodiment of the statistical concept of Kurtosis has been summoned 👀 22:19:08 :- P 22:19:19 Is there a control case for the forecasting? 22:19:27 Like just assuming next observation same as current observation 22:19:33 This is a great writeup btw 22:19:43 Upvote for the cross-chain analysis too 22:20:26 Yes. It is labeled "forecast.accuracy.naive.final.week" 22:20:46 Thanks :)