You can use peerlists to get a rough idea. It only lists those who accept external connections though.

google answers 1330 monerohash.com/nodes-distribution.html

One of the pools keeps a count, I dunno which one though.

also xmr.to has a node page somewhere

I believe that 1330 is the number of nodes that allow incoming connections

well not all of them as it doesn't pick up mine for a while although it used to

doesnt fluffypony live in south africa? I may have found his house :p

I believe he lives on planes.

that one shown is not him

interesting map anyway

The original view/spent key idea is broken, but there is another way to do opt-in spend detection: monero-project/research-lab #58#issuecomment-581090326

First idea could be gamed by someone holding only the view key to artificially lower the apparent balance

but by using PRNGs for all non-signing MLSAG/CLSAG scalars (very carefully), the remaining scalar must correspond to the spend

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

Advantage: no changes to tx structure, no distinguishability

Disadvantage: not suitable for audit (a convenience feature only)

Possibly-an-advantage: reduces reliance on RNG

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

CLSAG is oddly familiar to the RMLSAG bullshit I came up with back in march 2018

orly

I thought it was an unsolvable but maybe the hidden insight is here

It's key aggregation across multiple bases, which requires auxiliary linking tags (not used for spend detection)

If you're reading the current preprint, note that the security model has been improved

dont worry Ill never understand it :)

Because it's one aggregated key, you get away with a single set of scalars and an extra linking key per key vector dimension

so the scaling of a `d`-LRS goes from O(n*d) to O(n+d)

Usual tx is a 2-LRS; with timelocks it's a 3-LRS

lmao I think it's the damn domain separation that solved it

gahhh such a simple method 😩

?

You mean the aggregation coefficients?

I couldn't figure out how to prevent key cancellation without requiring d*d auxiliary linking tags

It does the trick

oh maybe it's the shared base that works so well

Yeah pretty sure RMLSAG is a d-linkable generalization of CLSAG. Will post my old PDF tomorrow for my ego

it's pretty cool that randomrun discovered CLSAG independently, which is actually useful for Monero. pdf-archive.com/2020/02/02/untitled…-document/untitled-pdf-document.pdf