Hey @Inge- yep, the example you mentioned is the main takeaway that is user-actionable.

Since (public spend key) = g^(private spend key) and Shor’s algorithm breaks the discrete log problem, a hypothetical quantum adversary could extract a wallet’s spend key from public addresses.

Details in section 3.1 here: github.com/insight-decentralized-co…/master/writeups/technical_note.pdf

We should assume that massive OSINT surveillance is underway to collect any/all Monero addresses posted on Reddit/Twitter/etc. While mostly harmless now (excluding dusting attacks) thanks to stealth addresses, that database would be very useful in the future to anybody that can leverage Shor’s algorithm.

Since subaddresses all share the same private spend key, that means that users who include retroactive deanonymization by quantum computers should use a separate account/wallet if they’re going to post an address publicly.

Most of the other recommendations are protocol upgrades that would need to be implemented by developers rather than end users.

s/computers should/computers in their threat model should

who is around today?

I'm still here

Hi Isthmus :P

If nobody else is joining, I'll just brief the happenings of last week (that I know of).

moneromooo has opened a bunch of pull requests to deal with the sybil peers currently attacking the network.

The main detection and deterent work is done through pr #6936. Some more review on all of these would definitely help.

"attacking" presumes intent. Could be spies. Could be research. Could be a monitoring tool.

(I feel obliged to point this out, because Insight has built some community-funded open-source tooling that monitors which tip organic nodes are on to alert if a global consensus fault occurs, such as a large portion of nodes that stall in syncing, or are on a different tip)

Not saying we shouldn't ban them, just noting in the interest of transparency that there are other use cases that result in this behavior, and I am occasionally behind them :- P

We actually had nodes like this up in Monero for a month to analyze propagation time, but that was last year

The basic functionality is that upon receiving a block the node checks if another peer it is connected to is also capable of relaying it.

Monitor/research nodes are fine as long as they are fully capable nodes

These spy nodes are not

Adding monitoring to the vanilla node is much easier than writing such spy node. They don't just drop transactions, they also try to poison peer lists.

they do?

In some cases, research nodes *cannot* relay blocks, since experimental results are completely invalid/useless if measurements perturb the system under observation

they only point to each other in peer lists

the plot thickens

haha

they also embed IPv4 inside IPv6 to get around /16 filtering

also host 7 nodes on one host

Can somebody privately send me a few IPs from this network? I have some ideas for passive countersurveillance that could elucidate their function

so, if this is a problem over clearnet (where at least ips can be compiled into a list and blocked), couldn't it become a big issue if they switch to tor/i2p ?

Isthmus: gui.xmr.pm/files/block.txt

perf, thanks

if they're faking block height, 'tis not a stretch to imagine they might start faking peer ids, if they already don't

github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md talks about this

> The design is intended to maximize privacy of the source of a transaction by broadcasting it over an anonymity network, while relying on IPv4 for the remainder of messages to make surrounding node attacks (via sybil) more difficult.

7 nodes on one host, that's interesting...

but that's my point, doesn't it actually end up hurting our chances? if we can't filter by peer id (easily fakeable?) or ip (it's tor), what prevents this guy/group with 100+ servers from faking hundreds of peers ids over tor, and connect aggressively to other onion nodes they know are not part of their group?

either i'm missing something or the damage could actually be greater

Yea @kayront that's a good point. At least it's harder (not impossible!) on Tor to pull off attacks like sybil or ecllipse that require specific network topolog.

*topology

is it though? my node can find other .onions just fine it seems, by design of course

others can find mine too

Oh, maybe not. I'm not super tor-savvy

Depends what it's for. If for DoS, you can spin up a lot of nodes, yes. If for mapping txes to IPs, no.

it wouldn't be an issue until/if some greater-than X number of nodes is relaying through tor afaics. it's the same problem we have atm but seemingly accidentally and potentially (!) magnified

yeah moneromooo, i'm thinking DoS here

Oh yea DoS is just a numbers game, regardless of clearnet or tor

18:20 <Isthmus> 7 nodes on one host, that's interesting... <-- moo fixed it here monero-project/monero #6939

yes Isthmus, i brought it up because it seems that there might actually be bigger risk of accidentally DoSing the network (way more txs being tarpitted by evil nodes than now) by trying to make it safer against IP linkage

by using tor (many operators making that choice)

tor, i2p, wtv

As a follow-up to last week's discussion on the unlock_time removal, I have opened this issue: monero-project/research-lab #78 to gather more opinions/use-cases

does anybody else have something to share?

Just ran some batch whois on the AHP's and they are almost exclusively from Canada and France

With a few in UK

Of course that could just be their VPN endoints, need to go deeper

thought they were all on OVH networks

OVH SAS yea

seems to be it for today, have a good week :)

Oops I tabbed out

I do have one quick preliminary update

One of the Insight Fellows put together an MVP for analyzing empirical uniformity of fields on the Monero blockchain

For a given field X (e.g. fee) we look at EVERY value on the blockchain, and perform statistical tests

One of which searches for duplicates/collisions (that are more frequent than birthday expectations)

Some interesting results, running over data from n3ptune, are reuse of encrypted payment IDs, transaction public keys, and stealth addresses

Oh, here's the project descrition: github.com/Mitchellpkt/crypto_field_stats_tests

*description

(that's all from me)

Isthmus: what does the "Pass all tests?" column means? It only has a sense when uniformity is expected that's why for line 2-3 it says "no"?!

...and it's expected in the note