00:00:23 You can use peerlists to get a rough idea. It only lists those who accept external connections though. 00:00:37 google answers 1330 https://monerohash.com/nodes-distribution.html 00:00:37 One of the pools keeps a count, I dunno which one though. 00:02:21 also xmr.to has a node page somewhere 00:02:47 https://community.xmr.to/network/ 00:03:23 I believe that 1330 is the number of nodes that allow incoming connections 00:04:03 well not all of them as it doesn't pick up mine for a while although it used to 00:04:42 doesnt fluffypony live in south africa? I may have found his house :p 00:05:15 I believe he lives on planes. 00:06:21 that one shown is not him 00:06:47 interesting map anyway 03:10:06 The original view/spent key idea is broken, but there is another way to do opt-in spend detection: https://github.com/monero-project/research-lab/issues/58#issuecomment-581090326 03:10:29 First idea could be gamed by someone holding only the view key to artificially lower the apparent balance 03:10:53 but by using PRNGs for all non-signing MLSAG/CLSAG scalars (very carefully), the remaining scalar must correspond to the spend 03:11:31 A non-compliant or malicious wallet with full spend authority can always refuse to participate in this and fail to report a spend, but that was always a problem with these opt-in approaches 03:12:06 Advantage: no changes to tx structure, no distinguishability 03:12:23 Disadvantage: not suitable for audit (a convenience feature only) 03:13:00 Possibly-an-advantage: reduces reliance on RNG 03:15:06 It would require retooling of the plumbing, since the MLSAG/CLSAG routines would require public data unique to signatures/transactions to avoid issues with scalar repetition and transaction reconstruction 03:24:30 CLSAG is oddly familiar to the RMLSAG bullshit I came up with back in march 2018 03:26:23 orly 03:26:59 I thought it was an unsolvable but maybe the hidden insight is here 03:27:42 It's key aggregation across multiple bases, which requires auxiliary linking tags (not used for spend detection) 03:28:30 If you're reading the current preprint, note that the security model has been improved 03:29:05 dont worry Ill never understand it :) 03:29:17 Because it's one aggregated key, you get away with a single set of scalars and an extra linking key per key vector dimension 03:29:37 so the scaling of a `d`-LRS goes from O(n*d) to O(n+d) 03:29:58 Usual tx is a 2-LRS; with timelocks it's a 3-LRS 03:46:32 lmao I think it's the damn domain separation that solved it 03:49:03 gahhh such a simple method 😩 03:51:57 ? 03:52:10 You mean the aggregation coefficients? 03:52:49 I couldn't figure out how to prevent key cancellation without requiring d*d auxiliary linking tags 03:54:38 It does the trick 05:39:42 oh maybe it's the shared base that works so well 06:40:20 Yeah pretty sure RMLSAG is a d-linkable generalization of CLSAG. Will post my old PDF tomorrow for my ego 19:29:34 it's pretty cool that randomrun discovered CLSAG independently, which is actually useful for Monero. https://www.pdf-archive.com/2020/02/02/untitled-pdf-document/untitled-pdf-document.pdf