<barthman132:matrix.org> @spirobel:kernal.eu: That video is over 4 months old, if that was the case. Then how did it take, so long for everyone to figure that out?

<spirobel:kernal.eu> @barthman132:matrix.org: most of the people that are into mining like to tinker with stuff and don't focus so much on the economics and which miner to run (as long as they feel its the one giving the most rewards). the rewards are not the end they are the means to buy more hardware to tinker with. To better understand this [... too long, see mrelay.p2pool.observer/e/9sTUlbgKRUFWWTFt ]

<spirobel:kernal.eu> to really make a dent in the hashrate the messaging needs to change: qubic is playing the middleman and is scamming miners. as long as they can get away with the info graphics that show supposedly higher rewards with qubic over directly mining monero it does not matter if they get called out on all the other lies.

<barthman132:matrix.org> Ah I see! If that is the case then it was only a matter of time it would’ve have imploded in on itself eventually. Because even according to Qubic themselves. The average Qubic miner isn’t making that much more than the average monero miner.

<longtermwhale:matrix.org> any factual analysis how much more XMR they mined due to selfish mining?

From direct numbers they lost more to selfish mining than they took

They optimized it a bit more recently but there is still a mismatch

<privacyx> Qubic mining hash rate in the last 12+ hours has been dropping significantly to around 1.3 Gh/S. They normal sit around 1.7-2.1 Gh/S

I now account all mining pools > 100 KH/s from miningpoolstats.stream/monero minus rplant.xyz

and ... ntminerpool.com which don't expose any API I know of

except via their QQ group?

nt one is top 9. so that's more important

oddly enough on blocks.p2pool.observer/pools "Unknown" is also top 9 :)

<rucknium> I updated the plot and numbers for the respends of txs invalidated from the 18-block reorg: monero-project/monero #10085#issuecomment-3313627068

<rucknium> Right after the 7-day txpool livetime expired, several more respending txs appeared.

so it's likely these txs were made and just had not widely broadcasted across the network?

can you get the height those txs were generated at?

<rucknium> Good question. You could analyze...

or lock height

<rucknium> You can get an idea of the time of tx construction by analyzing the heights of ring members.

that is a good chart, good job

right, locktime is not set usually in normal txs

<rucknium> Or, at least, the time that the ring ws first created an insetred into the shared ringDB, if it couldn't be broadcast at the time.

<ofrnxmr> I dont think so - theyd have expired in 3 days > <DataHoarder> so it's likely these txs were made and just had not widely broadcasted across the network?

<ofrnxmr> Probably more likely that the user/services just sent another tx that spent the now-unlocked output

<rucknium> Just a Base R plot. I like to use Base R plots when I need fine-grained control over plotting elements. ggplot is good for pretty plots, but the syntax can be annoying sometimes.

<servers.guru:matrix.servers.guru> Hey! How is the cubic situation these days? Did they give up yet?

They're in decline (both in price and in hashrate)

and in "hype"

<servers.guru:matrix.servers.guru> Is there still danger of reorg and such?

yes, but they haven't been selfish mining for a while

<servers.guru:matrix.servers.guru> I saw thst there was one ont he 14th

turns out, it brings more profit if you mine honestly :D

<servers.guru:matrix.servers.guru> Who would have thought!

<servers.guru:matrix.servers.guru> Thanks for the info. I'd rather avoid increasing required confirmations

<rucknium> @servers.guru:matrix.servers.guru: Were you impacted at all by the reorgs?

<servers.guru:matrix.servers.guru> @rucknium: I don't know really. Not that it was noticeable at least so.

<servers.guru:matrix.servers.guru> But I'd rather avoid to be impacted by it 😬

<ofrnxmr:xmr.mx> Ignorance is bliss, they say

<ofrnxmr:xmr.mx> offtopic, but If you lost $, thered probably have some legal case against qubic

Qubic's blocks up to epoch 179. irc.gammaspectra.live/324a89c016fe9b22/qubic-blocks-epoch179.csv

Epoch 179 blocks: 1204, orphans 77; Total 12869 blocks, 1133 orphans

<servers.guru:matrix.servers.guru> @ofrnxmr:xmr.mx: If I did. It's very little. As it didn't stick out. It's hard to tell because I lose many anyway due to price fluctuation.

<ofrnxmr:xmr.mx> Would he a txid that is present in invoices, but absent from the wallet

<rucknium> @servers.guru:matrix.servers.guru: I think the only way you could have lost money would be if received one of these transactions and still credited the customer's account: github.com/WeebDataHoarder/Monero-T…r/data/transactions/invalidated.txt

<servers.guru:matrix.servers.guru> @ofrnxmr:xmr.mx: Well, I wouldn't see it unless I specifically look for it i guess.

<servers.guru:matrix.servers.guru> @rucknium: Nice. Maybe I'll check if I have some time :)

<ofrnxmr:xmr.mx> @servers.guru:matrix.servers.guru: Now? Yeah. A couple days ago, i believe you'd have seen incoming txs pending for days

<servers.guru:matrix.servers.guru> I don't think there have been any pending for days. But I don't monitor the wallet or the orders at this point. They get completed or they get canceled and that's that.

<servers.guru:matrix.servers.guru> But it's unlikely I was impacted. It's only 115 tx in 18 blocks?

<servers.guru:matrix.servers.guru> That seems unlikely.

plus some in mempool, one?

<servers.guru:matrix.servers.guru> Maybe I'll find a big loss at the end of the month when doing accounting 😭

<servers.guru:matrix.servers.guru> I might actually spend some time to check the tx list :)

<rucknium> I have some very preliminary results from my testing of the latency of DNS resolvers serving the testpoints.moneropulse.xxx checkpoint TXT records.

<rucknium> I used 8 VPSes, 10 specified DNS resolvers, plus the default resolver of each machine.

<rucknium> I saw 7 of 7 (7/7) record consistency for most of the specified resolvers in 95 - 98% of checkpoint checks (every 2 minutes).

<rucknium> In the current draft protocol, you need 6/7 matching checkpoint records.

<rucknium> Quad9 (9.9.9.9) can be 60% and below. Avoid.

<rucknium> The machine's default DNS resolvers were as low as 60% and as high as 98%.

<rucknium> Probably, for consistency, mining pools and major merchants would want to specify a good DNS resolver with DNS_PUBLIC=tcp://RESOLVER_IP ./monerod because their machine's default resolver could have uneven performance.

<rucknium> @ofrnxmr:xmr.mx: Quad9 (9.9.9.9) seemed to have the worst performance, yet it is specified in docs.getmonero.org/interacting/monerod-reference/#p2p-network as an example config. I think this should be changed ASAP.

<rucknium> I will have to rerun the data collection for final detailed analysis since many of the scripts died after 24 hours. I need to add more error handling.

Quad9 is what I use :/ what do you recommend instead?

<rucknium> These seemed to work fine: "@1.1.1.1", # Cloudflare, "@8.8.8.8", # Google, "@64.6.64.6", # Vercara, "@77.88.8.8", # Yandex, "@86.54.11.1", # DNS3EU, "@94.140.14.14", # AdGuard, "@95.85.95.85", # Gcore, "@208.67.222.222", # OpenDNS, "@216.146.35.35" # Oracle

<rucknium> List originally sourced from en.wikipedia.org/wiki/Public_recursive_name_server

<rucknium> selsta: Quad9 also flags my moneronet.info and moneroconsensus.info as malicious and blocks them. I emailed them asking to take moneronet.info off the list, but no response.

<ofrnxmr:xmr.mx> I switched from quad9 because it blocks ruckniums domains

<ofrnxmr:xmr.mx> i switched from 8.8.8.8 because it seemed to serve cached entries occasionally

<ofrnxmr:xmr.mx> I am now using 1.1.1.1

<ofrnxmr:xmr.mx> monero-project/monero-docs #221/files

A local (or LAN) recursive DNS resolver would also perform relatively equal

as it directly queries each domain DNS servers

<ofrnxmr:xmr.mx> pr 221 uses 1.1.1.1 for the example. The moneropulse page has 8.8.8.8 and 1.1.1.1

there's some unbound unbound.docs.nlnetlabs.nl/en/latest/use-cases/home-resolver.html and pi-hole docs docs.pi-hole.net/guides/dns/unbound

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: Actually, i think the example here might not work. (DNS_PUBLIC in addition to --proxy). I think someone the other day was having issues until they dropped the env variable?

<ofrnxmr:xmr.mx> ^ > <@alfieedwards> I have run again without "DNS_PUBLIC=tcp://9.9.9.9" like before and monerod works without DNS warnings.

<ofrnxmr:xmr.mx> Hm. --proxy seems to ignore the env variable

<ofrnxmr:xmr.mx> 2025-09-24 17:03:33.100 I Using public DNS server(s): 1.1.1.1 (TCP) this line is printed when not using --proxy. Its not there when you are using --proxy. I also dont see any checkpoint related logs when using tor

<ofrnxmr:xmr.mx> So i wonder how @alfieedwards:monero.social is using tor. maybe torsocks?

reg dns, most of those resolvers have "unprotected" aka no safe browsing blocking. quad9 sucks and i would never use them but if you want resolving to work ie moneronet.info

$ dig +short @9.9.9.9 moneronet.info null

$ dig +short @9.9.9.10 moneronet.info95.217.143.178

9.9.9.10 / 149.112.112.10

<hbs:matrix.org> dns0.eu is also worth mentioning

<syntheticbird> @hbs:matrix.org: mrelay.p2pool.observer/m/monero.social/jHNAtJSxRwdLuSPVmUTrACgI.mp4 (stand_anthem_kneel_cross_eu_nato.mp4)

anyone remember when 4.2.2.2 was king

<321bob321> 8.8.8.8

most of us de-google our phones etc. then use google dns?

<321bob321> This is the way