16:41:33 Hey @Inge- yep, the example you mentioned is the main takeaway that is user-actionable. 16:41:33 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. 16:41:33 Details in section 3.1 here: https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/writeups/technical_note.pdf 16:41:33 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. 16:41:33 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. 16:41:34 Most of the other recommendations are protocol upgrades that would need to be implemented by developers rather than end users. 16:42:10 s/computers should/computers in their threat model should 16:42:10 Isthmus meant to say: Since subaddresses all share the same private spend key, that means that users who include retroactive deanonymization by quantum computers in their threat model should use a separate account/wallet if they’re going to post an address publicly. 17:00:32 who is around today? 17:03:18 I'm still here 17:03:41 Hi Isthmus :P 17:05:34 If nobody else is joining, I'll just brief the happenings of last week (that I know of). 17:06:36 moneromooo has opened a bunch of pull requests to deal with the sybil peers currently attacking the network. 17:09:18 The main detection and deterent work is done through pr #6936. Some more review on all of these would definitely help. 17:09:50 "attacking" presumes intent. Could be spies. Could be research. Could be a monitoring tool. 17:09:50 (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) 17:10:52 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 17:11:05 We actually had nodes like this up in Monero for a month to analyze propagation time, but that was last year 17:11:33 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. 17:12:29 Monitor/research nodes are fine as long as they are fully capable nodes 17:12:35 These spy nodes are not 17:13:27 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. 17:13:39 they do? 17:13:43 In some cases, research nodes *cannot* relay blocks, since experimental results are completely invalid/useless if measurements perturb the system under observation 17:13:49 they only point to each other in peer lists 17:13:50 the plot thickens 17:14:08 haha 17:14:50 they also embed IPv4 inside IPv6 to get around /16 filtering 17:15:02 also host 7 nodes on one host 17:15:05 Can somebody privately send me a few IPs from this network? I have some ideas for passive countersurveillance that could elucidate their function 17:15:19 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 ? 17:15:48 Isthmus: https://gui.xmr.pm/files/block.txt 17:15:55 perf, thanks 17:16:06 if they're faking block height, 'tis not a stretch to imagine they might start faking peer ids, if they already don't 17:17:48 https://github.com/monero-project/monero/blob/master/ANONYMITY_NETWORKS.md talks about this 17:17:59 > 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. 17:20:24 7 nodes on one host, that's interesting... 17:20:31 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? 17:20:53 either i'm missing something or the damage could actually be greater 17:21:34 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. 17:21:45 *topology 17:22:20 is it though? my node can find other .onions just fine it seems, by design of course 17:22:27 others can find mine too 17:22:54 Oh, maybe not. I'm not super tor-savvy 17:22:56 Depends what it's for. If for DoS, you can spin up a lot of nodes, yes. If for mapping txes to IPs, no. 17:23:05 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 17:23:15 yeah moneromooo, i'm thinking DoS here 17:23:37 Oh yea DoS is just a numbers game, regardless of clearnet or tor 17:23:43 18:20 7 nodes on one host, that's interesting... <-- moo fixed it here https://github.com/monero-project/monero/pull/6939 17:26:03 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 17:26:25 by using tor (many operators making that choice) 17:26:30 tor, i2p, wtv 17:30:25 As a follow-up to last week's discussion on the unlock_time removal, I have opened this issue: https://github.com/monero-project/research-lab/issues/78 to gather more opinions/use-cases 17:31:50 does anybody else have something to share? 17:32:46 Just ran some batch whois on the AHP's and they are almost exclusively from Canada and France 17:32:48 With a few in UK 17:33:16 Of course that could just be their VPN endoints, need to go deeper 17:33:34 thought they were all on OVH networks 17:33:40 https://usercontent.irccloud-cdn.com/file/Rk4XNFdl/image.png 17:33:54 OVH SAS yea 17:39:32 seems to be it for today, have a good week :) 17:43:48 Oops I tabbed out 17:43:52 I do have one quick preliminary update 17:44:31 One of the Insight Fellows put together an MVP for analyzing empirical uniformity of fields on the Monero blockchain 17:45:01 For a given field X (e.g. fee) we look at EVERY value on the blockchain, and perform statistical tests 17:45:33 One of which searches for duplicates/collisions (that are more frequent than birthday expectations) 17:45:45 https://usercontent.irccloud-cdn.com/file/KlsJnUJn/image.png 17:46:09 Some interesting results, running over data from n3ptune, are reuse of encrypted payment IDs, transaction public keys, and stealth addresses 17:46:28 Oh, here's the project descrition: https://github.com/Mitchellpkt/crypto_field_stats_tests 17:46:34 *description 17:46:45 (that's all from me) 18:07:53 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"?! 18:09:00 ...and it's expected in the note