06:09:22 <dukenukem> Revuo Monero Issue 246: August 17 - 26, 2025. https://www.revuo-xmr.com/weekly/issue-246/
12:50:46 <m-relay> <j​ohn_r365:monero.social> https://matrix.monero.social/_matrix/media/v1/download/monero.social/ZrFCHYzhVouaixpRosrZXXwT
12:50:59 <m-relay> <j​ohn_r365:monero.social> https://matrix.monero.social/_matrix/media/v1/download/monero.social/ZWqGYiwdapggJkalkIhJkDVk
12:51:59 <m-relay> <j​ohn_r365:monero.social> CfB tweet: https://x.com/c___f___b/status/1960127265012142271
12:52:24 <m-relay> <j​ohn_r365:monero.social> I know this is old by ~13 hours, but I'm just catching up on news. Is it correct that Qubic are acting "ethically" with their re-orgs to avoid causing problems with exchanges?
12:53:45 <m-relay> <s​yntheticbird:monero.social> there is no ethics behind it
12:57:40 <m-relay> <s​hortwavesurfer2009:monero.social> Low latency things are affected most. Think exchanges and stuff like that. But the regular peer-to-peer economy isn't necessarily all that affected by this. Because it takes you longer to get products shipped in the mail, then it does to get confirmations.
13:00:16 <m-relay> <m​onerobull:matrix.org> Gate the type of exchange to send contract killers after you if you fuck with them
13:01:01 <m-relay> <m​onerobull:matrix.org> right now there is no big company with nearly infinite money on his ass, just some monero people
13:01:23 <m-relay> <m​onerobull:matrix.org> if he fucks over an exchange they could sue him into the ground
14:46:48 <m-relay> <a​lexandre:uii.pt> not so much for in person transactions tho
14:53:39 <m-relay> <f​iatdemise:matrix.org> I remember for a couple days before applying correct settings, someone was running the miner on the XMRChat server. Qubic is open source. Just throwing out an idea that it might be worthwhile to look for vulnerabilities. Would be hilarious if we could take over some Qubic miners. https://github.com/qubic
15:00:50 <m-relay> <o​frnxmr:xmr.mx> I remember that :P
15:01:54 <m-relay> <o​frnxmr:xmr.mx> I dont think qubic's node is publicly accessible. Their miners dont have to run nodes either
15:03:58 <DataHoarder> their miners are closed source in C# and just connect to a websocket run by pools
15:04:09 <DataHoarder> which for xmr case, point to stratum
15:19:46 <m-relay> <f​iatdemise:matrix.org> The only have 1 node?
15:23:18 <DataHoarder> qubic node != computor != pool
15:23:27 <DataHoarder> a qubic node can exist without being a computor
15:23:35 <DataHoarder> and multiple "computors" can exist in one node
15:29:39 <DataHoarder> their miner program effectively listens on a websocket for instructions, including downloading random binaries by provided URL and instantly executing them on the local computers
15:29:58 <DataHoarder> from what was observed these were xmr or their qubic actual miners
16:26:13 <m-relay> <r​brunner7:monero.social> Downloading random binaries and execute them on its own ... say again, which class of programs this reminds me of :)
16:31:25 <m-relay> <o​frnxmr:xmr.mx> Windows update /s
16:32:58 <binaryFate> Binaries for v0.18.4.2 are now available at https://www.getmonero.org
16:45:02 <n1oc> vtnerd full-time 2025 q3 is now fully funded! https://ccs.getmonero.org/proposals/vtnerd-2025-q3.html @luigi1111
17:02:16 <m-relay> <s​yntheticbird:monero.social> finally
17:02:18 <m-relay> <s​yntheticbird:monero.social> congrats
17:04:17 <nioc> thx n1oc
17:06:48 <m-relay> <s​yntheticbird:monero.social> thx n1oc
17:40:29 <m-relay> <j​effro256:monero.social> Vulnerability disclosure report: https://github.com/monero-project/monero/issues/10059
17:46:52 <m-relay> <r​ucknium:monero.social> Thanks, jeffro256 . Was this found by a HackerOne report, or in FCMP wallet re-factoring? If you run your own node locally, the privacy impact is zero, right?
17:48:02 <DataHoarder> unless someone is inspecting your network, I guess
17:48:19 <DataHoarder> how does this interact with pruned trusted nodes? do these make upstream calls?
17:49:31 <m-relay> <r​brunner7:monero.social> 7 year old bug? That's a bit disheartening how long this survived.
17:51:06 <m-relay> <r​ucknium:monero.social> DataHoarder: IIRC, wallets always request pruned versions of txs. Pruned nodes never need to ask unpruned nodes for data to serve wallet requests.
17:51:26 <m-relay> <j​effro256:monero.social> This was pointed out by jberman to me in a DM. It baffled me, so I dug a bit deeper to find out how it actually works (or doesn't lol) and what triggers it. Then I made a PR to get rid of it. I would ask jberman , but I bet he saw it doing wallet work for FCMP++. If you run your own node locally, there could be a privacy impact really only if someone had a packet inspection softwa<clipped message>
17:51:27 <m-relay> <j​effro256:monero.social> re running on your machine without your consent. If using a trusted remote node, with SSL, then someone can inspect packets over the network. If using a trusted remote node with SSL, but without key authentication, someone could MitM your SSL connection and listen to the packets that way.
17:52:08 <m-relay> <j​effro256:monero.social> DataHoarder: yeah it's the exact same with pruned nodes, trusted or untrusted
17:52:13 <DataHoarder> 👍
17:54:44 <m-relay> <j​effro256:monero.social> I need to double check, but if you're running a bootstrap wallet in GUI, I think someone rando with public RPC available gets your outgoing tx history
17:55:01 <m-relay> <j​effro256:monero.social> B/c your bootstrap node will pass the RPC request on to a random node
17:55:34 <m-relay> <j​effro256:monero.social> I wonder if the LionLink spy nodes got spoonfed tx histories this way
17:56:16 <m-relay> <o​frnxmr:monero.social> ofrnberman
17:56:34 <m-relay> <j​berman:monero.social> It was in logs that ofrnxmr  shared when debugging another bug in FCMP++ fwiw
17:57:27 <m-relay> <j​effro256:monero.social> Nice
17:57:44 <m-relay> <b​oog900:monero.social> is this bug always triggered on a wallets second load after being restored?
17:59:15 <m-relay> <j​effro256:monero.social> If you look at the second paragraph of the technical explanation section, it has some more details. You have to have restored the wallet keys file as well, not just the wallet cache. But if you restored the wallet keys file, then yes, it will trigger every time
18:00:49 <m-relay> <r​ucknium:monero.social> From moneronet.info , it seems that the spy nodes in the LionLink AS don't have RPC enabled, but Digital Ocean and Hetzner ones do.
18:01:49 <m-relay> <r​ucknium:monero.social> By the way, I enabled downloading the node table there as a CSV file.
18:02:57 <m-relay> <b​oog900:monero.social> yeah I didn't understand if the wallet had to be saved in a weird state for it to be hit or not
18:13:36 <m-relay> <j​effro256:monero.social> sgp_: just continuing the convo here for cleanliness. As for whether or not it has been exploited, since it it a data leak, it is more or less impossible to know whether it has been exploited unless the exploiters tell us it has. However, any basic packet inspection software would pick up this data leak if it was recording. So, if you're using an untrusted remote node for RPC, the<clipped message>
18:13:37 <m-relay> <j​effro256:monero.social> n the answer is: probably.
18:15:36 <m-relay> <j​effro256:monero.social> Due the the Ciphertrace leaked video, we know that their spy nodes are at least monitoring the RPC endpoints for transaction submission (`/sendrawtransaction`), I don't know why they wouldn't also be monitoring the `/gettransactions` endpoint
18:54:46 <m-relay> <m​onerobull:matrix.org> Remote nodes turn out to be a privacy nightmare #503
18:57:06 <m-relay> <p​lowsof:matrix.org> cc moneromooo , who asks that we add "this is probably a spy node" when adding a remote node via the cli
19:29:21 <m-relay> <l​m:matrix.baermail.fr> Rucknium: moneroconsensus.info causes some kind of memory leak/cpu high usage on client side if you zoom out/init makes the browser try to refresh the image for every zoom %. Had to restart my computer :d
19:29:48 <m-relay> <l​m:matrix.baermail.fr> Rucknium: moneroconsensus.info causes some kind of memory leak/cpu high usage on client side if you zoom out/in. It makes the browser try to refresh the image for every zoom %. Had to restart my computer :d
19:38:17 <m-relay> <o​frnxmr:monero.social> #alwayshasbeen
19:46:12 <m-relay> <l​m:matrix.baermail.fr> that was fast !
19:47:53 <m-relay> <r​ucknium:monero.social> Louis-Marie: Sorry. Maybe I need to set `execOnResize = FALSE` https://github.com/rstudio/shiny/issues/2373
22:38:35 <m-relay> <k​arakter:envs.net> it would be funny for if the server gets compromised
22:38:43 <m-relay> <k​arakter:envs.net> it would be funny if the server gets compromised
22:40:15 <m-relay> <m​onerobull:matrix.org> send out some malware that bricks the $10k servers, oopsie
22:46:18 <m-relay> <k​arakter:envs.net> that would kill rented rigs business