<ofrnxmr> Where is here? (im not complaining, just not sure what the arrow points to)

<rucknium> Back to me

<articmine> @rucknium:monero.social: I do not envy your situation. I only wish to thank and support you in these difficult times.

<gingeropolous> just reminding folks the ignore feature is fantastic

<interestingband:matrix.org> matrix.to/#/!toFcRZtpaiwiyapgVO:mat….org&via=monero.social&via=envs.net, was it published somewhere ?

<interestingband:matrix.org> monero-project/research-lab #145, "H(checkpoint_hash || key_image) < target * amount * (checkpoint_height - input_height)" considering that incentive for non attackers is almost 0 and an attacker may use specialized hardware for calculations of key images, I'm curious what is worst ratio between probal [... too long, see mrelay.p2pool.observer/e/jNus9bYKX1F5U2tE ]

<interestingband:matrix.org> matrix.to/#/!toFcRZtpaiwiyapgVO:mat….org&via=monero.social&via=envs.net, "That's why my advocacy is for a finality layer, ..."

<interestingband:matrix.org> monero-project/research-lab #135, ccs.getmonero.org/proposals/kayabaNerve-finality-layer-book.html, judging by description it's going to be a book mainly about BFT consensus implemntation

<interestingband:matrix.org> "Achieve finality in less than 20 minutes" it's too slow, can you name few successful projects that use this kind of "finality layer" ?

<interestingband:matrix.org> "Also included would be the role of Proof of Work in the remaining network, compared to its role currently." I doubt that you really understand what is the role of PoW now and what will be the role of PoW in case of migration to PoS

<interestingband:matrix.org> and it doesn't look like you understnad importance of it

<longtermwhale:matrix.org> I read somebody here talking about qubic earning "twice as much" due to selfish mining. Where to read a comprehensive analysis of this claim?

<longtermwhale:matrix.org> If impact on "normal" miners is that big we should also be wary about hashrate of normal miners dropping more due to economics.

<rbrunner7> The regularly publish "profitability updates" on their blog, e.g. this one: qubic.org/blog-detail/epoch-176-recap-general-profitability-update

<rbrunner7> I am not aware about any analysis done on "theoretical grounds", but I once mined Qubic for a day myself to see how many Qubic I actually receive, and also calculated from my hashrate what I would have gotten by mining Monero directly. It was back a while before Qubic's halving.

<rbrunner7> When I calculated my mining earnings using the then-current exchange fiat prices of QUBIC and XMR, I did earn almost twice as much mining Qubic.

<rbrunner7> I think it was something like USD 0.20 from direct XMR mining versus USD 0.40 by mining Qubic

<rbrunner7> Mind you, that was during a phase where my Qubic "miner" ran Xmrig only half the time

<longtermwhale:matrix.org> ok but that may be due to other reasons (cfb wanting to get rid of his qubic without crashing value to quickly)

<longtermwhale:matrix.org> it would be interesting to know how many more blocks they mined due to selfish mining and how they increased their profits that way (and then how much more they paid out)

<rbrunner7> Yeah, but as far as I could see their handling of the XMR they get is pretty much in the dark, with not even known who holds the keys to their XMR mining wallets

<longtermwhale:matrix.org> it would also lay the grounds on how important it is to prevent selfish mining. because if they really just make twice the money due to selfish mining, the economics are unbeatable

<longtermwhale:matrix.org> @rbrunner7: probably a belarussian with lots of qubic to give away

<rbrunner7> Maybe that's a misunderstanding. As a Qubic miner, you will be paid in $QUBIC. So the value of that coin decides how much you earn. As long as people believe in the value of that coin, and speculate it up because of their crazy AGI claims, they can afford to pay. Even with zero income from selfish mining, I would claim.

<rbrunner7> Of course it's completely unclear how much their own buying of their coin, using the mined XMR, influences the price of $QUBIC.

<rbrunner7> We are still in the crazy wild west phase of cryptocurrencies where if you have a credible story for your coin, you will attract the speculators which will, at least for some time, speculate the price up

<articmine> coinmarketcap.com/currencies/qubic

<rbrunner7> If only slightly credible, for the gullible

<articmine> It's being going down

<rbrunner7> Yeah, for a while already :)

<articmine> coinmarketcap.com/currencies/qubic

<rbrunner7> And they did pull through with their halving, which was a bit unexpected for me. The difference in profit between mining with Qubic and mining Monero, and maybe merge-mine Tari, went already considerably

<rbrunner7> I think there was a time where mining with them was three times more profitable

<rbrunner7> *went down already considerably

<rbrunner7> I am currently cautiously optimistic that they will miss their goal of achieving total mining dominace over Monero, with a hashrate that stays over 51% in a solid way, because mining with them it not that attractive anymore

<longtermwhale:matrix.org> > <@rbrunner7> Maybe that's a misunderstanding. As a Qubic miner, you will be paid in $QUBIC. So the value of that coin decides how much you earn. As long as people believe in the value of that coin, and speculate it up because of their crazy AGI claims, they can afford to pay. Even with zero income from selfish mining, I would claim.

<longtermwhale:matrix.org> there is no misunderstanding. they/him have qubic to give away. if dude wants to get rid of his qubic without crashing price, because people dont sell immediately, he found a perfect way to convert to XMR. interesting is just how much they also make on top due to selfish mining exactly. i dont see why dude would need to sell XMR to buy back his own coin which is going down in value.

<articmine> He is trying to prop up the price by burning Qubic

<articmine> Or at least that is what he claims

<rbrunner7> Hmm, I think they had Qubic to the tune of USD 300,000 on TradeOgre (known fact) because they used that exchange to switch XMR to QUBIC

<rbrunner7> Back when it was still online of course

<rbrunner7> But yeah, it's all pretty intransparent, and of course almost obscenely centralized, who knows for sure what exactly happens.

<longtermwhale:matrix.org> @rbrunner7: so there is evidence they convert it back?

<rbrunner7> Not sure, I never tried to actually track their (transparent) transactions and burnings. Burning addresses are known.

<rbrunner7> Not sure them having so much $QUBIC on TrageOgre is any evidence, but that exchange was one of the last ones with good XMR liquidity. They may use MEXC now? Not sure.

<helene:unredacted.org> they might not exchange it at all; after all, might be why they picked monero in the first place: to make it difficult to prove

<longtermwhale:matrix.org> if i put myself in the situation of this dude, my goal is to convert all the shitcoin to monero

<helene:unredacted.org> there's proof that they "burn" qubic, but it would be turbo profitable to keep an actual currency of value around and to give the speculation coin to miners

<longtermwhale:matrix.org> lets assume he has 100m$ in qubic, its impossible to just sell on CEX without crashing the value to near-0

<helene:unredacted.org> and pinky promise you sold the monero for the speculation coin

<rbrunner7> "if i put myself in the situation of this dude, my goal is to convert all the shitcoin to monero" That thought certainly has something :)

interestingband: Can you explain how specialized hardware would help in this case? Considering that key images are uniquely determined by the output key. You can't just "mine" for key images.

<articmine> @longtermwhale:matrix.org: ... but they can burn it

<articmine> .. and hope that the price goes up

You know what would be really worthwhile for us normies is a breakdown of the actual attack. It sort of feels like we don't yet fully understand it fully, which makes designing/ideating mitigations quite difficult as it seems a moving target. Maybe that is because the attackers don't really have an actual plan, other than to cause disruption, and are figuring it out on the fly?

Selfish mining is a well understood attack.

But it's leveraged through some sort of tokenomics inventive on their side isn't it? As I understand it, it's not just a straightforward selfish mining attack, which also explains why they don't want to just cause irreparable "damage" to Monero through consistent reorgs.

*incentive

@longtermwhale:matrix.org it's only miners getting paid more, until recently qubic was about 82% efficient when selfish mining (actually losing an edge)

They still aren't that high up but are at 90% efficiency. They need above 100% to actually earn more than they lose in attempts

<articmine> The attack has mutated from what was originally an attempted 51% attack using bribery to the current 51% attack

<articmine> Selfish mining attack.

The reorgs they caused were not 51% attacks. It was selfish mining + luck. They don't have 51%.

<articmine> They never did achieve 51%, but they did try. Hence the mutation to selfish mining

<articmine> This being said I would not dismiss the 51% attack threat

so it started as 51%^bribery, then to selfish-mining^bribery, and has now morphed to solely selfish-mining?

<articmine> This seems reasonable to me

Are all the Qubic miners are acting malevolently, or just out of curiosity to see how far their efforts will undermine a "rival"?

I guess both are malevolent, really

<articmine> It could be both

13:17:56 <midipoet> so it started as 51%^bribery (51% marketing for hype), then to selfish-mining^bribery (selfish mining/domination marketing for hype), and has now morphed to solely selfish-mining (direct attacks/big reorgs marketing for hype)

Technically, it's still a bribery attack since they are paying more per hash than the Monero network. Just not enough to attract 51% of miners.

<gingeropolous> i wonder how successful their deep chain re-orgs would be if we had a mechanism that adjusted difficulty based on orphan blocks. Though that would equally hit the honest miners

<gingeropolous> (i think these orphan diff considerations are part of many of the selfish mining mitigations)

<gingeropolous> also, i think the words right above the images here: blocks.p2pool.observer give some insight into the profitablity of their selfish mining

It would not change their attack success probability, it would just reduce the number of blocks produced per day.

<gingeropolous> in theory, wouldn't it reduce the rate that their private altchain grows?

<gingeropolous> highly probabale i don't have a full grasp on our diff adjustment calc :|

<gingeropolous> !_!

<gingeropolous> woops

yeah they are a bit more efficient now gingeropolous, still not above

<kill-switch:matrix.org> from conversation I observed yesterday (matrix.to/#/!qqRhJzAUfTJRpMHqIP:mat…a=monero.social&via=hackliberty.org) on Rabid Miner's discord, it would appear that they are not paying out miners more than what it's worth to mine XMR directly, at this point

The link doesn't work on IRC.

<kill-switch:matrix.org> boo

<kill-switch:matrix.org> here's a screenshot of the conversation i.postimg.cc/76TtZ5Cv/Screenshot-from-2025-09-18-19-58-45.png

<kill-switch:matrix.org> as the miners are facing large delays and do not get to observe the mining directly, there is lag time between getting fucked, and feeling it :)

So they should just start mining Monero directly, not via a known malicious pool.

what is that link actually

<kill-switch:matrix.org> well they in that example decided to use another qubic pool instead, which datahoarder pointed out to me is run on the same infrastructure

ah, link to channel, not picture

#monero-offtopic for IRC :)

<kill-switch:matrix.org> the first link? that is an autogenerated Share link from element, yeah

it's using old bridge so there is no easy linkage

jetski/QLI/minerlab etc. all use same backend and effective pool. it's all QLI

they are the "same" pool

only apool does different stuff, these pay directly in XMR

(they have their own infrastructure as well)

they are always getting the blame for "not updating fast" when ofc the rest of the pools are illusion of choice and managed by Qubic team directly

<kill-switch:matrix.org> one can speculate on why they are screwing over thier miners, but the rational options to pick from are... slim, I thnk

<spirobel:kernal.eu> imgix.ranker.com/list_img_v2/12909/…u1?w=817&h=427&fm=jpg&q=50&fit=crop here is an image of the conversation > <@kill-switch:matrix.org> here's a screenshot of the conversation i.postimg.cc/76TtZ5Cv/Screenshot-from-2025-09-18-19-58-45.png

<spirobel:kernal.eu> is there a list of all the qubic related pools?

one sec

nevermine.io qubic.li jetskipool.ai minerlab.io apool.io

(some have xmr subdomains for the xmr part)

nevermine/minerlab directly CNAME to qubic.li

jetski at least has a different IP pool set than qubic.li but has otherwise their infra

<spirobel:kernal.eu> we would put a sticky on the moneromining subreddit that these pools are likely to screw you over with this screenshot, maybe it will make the rounds

hey, apool pays in XMR. No idea how that differs from estimate, as they messages are all in chinese

they also at times moved to mine xmr directly without qubic cause they got screwed by them

<spirobel:kernal.eu> lets just put it out. I am sure more will come forward.

<spirobel:kernal.eu> what are save recommended pools to mine? maybe people just dont know. if its all collected in one spot they can make an informed decision

<gingeropolous> yeah noobs will often just select the pool with the highest hr

<gingeropolous> i really want to just start fiddling with these selfish mining mitigations

p2pool :)

some people have been pushing me to create a p2pool stratum that just mines to p2pool directly (as in, not pool, but directly behaves like p2pool, directly mining on it with the address)

<helene:unredacted.org> i can see why but it doesn't seem like a very good idea

indeed. though go-p2pool stratum already offers the ability to set any address via --user (and will produce shares for that)

+ subaddress support

that's mainly for my own testing and small friend networks where one runs that and others just trust them and set their address on miner user field

<spirobel:kernal.eu> reddit.com/r/MoneroMining/comments/…hich_pool_you_pick_qubic_pools_will maybe you guys can write something better / more official

<spirobel:kernal.eu> not even sure if the mining subbreddit is still used much. where do miners communicate usually?

discord :') or nowhere

<helene:unredacted.org> yeah most miners only care about the profit incentive, not really the coin

<helene:unredacted.org> those that do are few and rare, and those are the ones you'll find on the subreddits and such

<spirobel:kernal.eu> maybe their scheme is different than we thought. its not just marketing for their fake agi "mining" coin. aside from their selfish mining gimmick they could also make bank by selectively scamming miners on other pools.

<spirobel:kernal.eu> how did they get control over these pools? those are older ones, right?

14:31:57 <br-m> <spirobel:kernal.eu> how did they get control over these pools? those are older ones, right?

? they didn't gain control, these were qubic's own pools

they just added the XMR Qubic part later on

<spirobel:kernal.eu> interesting. is there a market for pools? do you think they built them up with this specific purpose or did they buy them from a different operator?

as I said QLI is specifically run by Qubic

and the others just use their infra, they aren't that big, besides apool

the others besides jetski have all other coins as well.

<spirobel:kernal.eu> what if their bursty hashrate is not just a result of selfish mining, but also them selectively scamming miners?

<spirobel:kernal.eu> their other story is similar: ai anna just has work sometimes ... which also gives them an excuse to condition people to the idea that their rewards + utilization will fluctuate

this is research lounge not collusion theories channel

Also - the payouts are shifted one week

So they use a different week to do payouts, which ofc, it's another abstraction layer

<spirobel:kernal.eu> Monero is the only coin that can absorb a lot of CPU hashrate. Anyone claiming higher rewards than just mining monero directly has to justify where the additional yield comes from.

<spirobel:kernal.eu> It might be that most market participants are not rational. their thought is: how can i get the most money for my cpu hashrate. they go to google and install the qubic miner or one of the multicoin miners (that uses qubic infra under the hood)

<spirobel:kernal.eu> that means they dont need to rent hashrate from datacenters. If their botnet of lets say less then rational CPUs owners is large enough they can just turn it off and on at will. This seems more realistic than them renting hashrate during bursts from datacenters

> Anyone claiming higher rewards than just mining monero directly has to justify where the additional yield comes from.

They don't, they pay in qubic and hope the burn just causes speculators to keep price up

or miners not selling

it's paper money, not direct payouts

+ their own qubic mining

my testnet node hasn't repro the issue ofrnxmr yet, hmm

<ofrnxmr:xmr.mx> Have to time it right

<ofrnxmr:xmr.mx> New checkpoint exists, node has not seen the new checkpoint yet, reorg the node below that checkpoint height

yeah, would be great if I could get my local node stuck but as always the debugging part makes the bugs flee away

so delaying dns updates would help in this case right?

<ofrnxmr:xmr.mx> No, it depends on if the node receives a new checkpoint that references an alt chain

<ofrnxmr:xmr.mx> fixing the logic of that massive if statement is probably the fix

yeah, I think I can manage that if I mine on my own node and delay checkpoint updates

what I don't understand is why that runs *twice* with different errors

<ofrnxmr:xmr.mx> oh, help to reproduce? Yeah

and lemme make sure I do NOT broadcast any found blocks via submit_block instantly

that will also help

hopefully I can trigger it

I am already generating orphans

yep I have a long orphan chain that I'm not disclosing

if other blocks grow now and checkpoint is set my node should enter the condition

ok, now I am, had to not reply to some requests

I have a selfish chain going up to 2837981 root at 2837970

there are 3 blocks now on the other side, so once a checkpoint is set that should trigger my node to fail

5 :)

irc.gammaspectra.live/1da3cdcbbaba891d/image.png

I have been banned by peers, good sign :)

IN TXT "2837971:3f2246b3a36804fa4220490bf2d25be0a2a57568337a04a65ca238a2b0bbcba5"

that should trigger my node once it fetches

2025-09-20 14:19:00.862 E Block recognized as orphaned and rejected, id = <753da5967f679b1a9dc90ab62fe5d6f2e7a8dfa67e5e075fc9add1c273c0027c>, height 2838008, parent in alt 0, parent in main 0 (parent <3f53cbc6887b7bf662a4d75e3c27f40a29604039dd66f14ed41367c444bfa94e>, current top <ff70c9898084423efff1f144f456ed4cabaad69145c09cfacbbea0092873f7ff>,

chain height 2837973)

I am stuck at 2837973

funnily that did not issue a ZMQ change of miner data

no, didn't trigger. I switched to alternate chain

<sneedlewoods_xmr:matrix.org> In order to test the DNS checkpoints on testnet you use a node which uses this PR monero-project/monero #10075 and you also need to change the testnet_dns_urls in src/checkpoints/checkpoints.cpp, right?

<sneedlewoods_xmr:matrix.org> If that's the case, can anyone share those urls again, please?

<ofrnxmr> No

<ofrnxmr> github.com/nahuhh/monero/tree/dns_testpoints-public

<ofrnxmr> Use this branch

<ofrnxmr> @datahoarder, it didnt get stuck?

nope

though I got well banned, waiting for unban :D

<ofrnxmr> What height are you on?

it switched fully to 2837973 (2837973 is the highest I had when bans happened)

<ofrnxmr> You should be unbanned in 5mins ruckniums and my nodes

I popped down to 64 now

<ofrnxmr> Check your own bans

yeah I just had mined some lingering blocks on top of that

<ofrnxmr> bans

I have priority nodes added

so those don't get banned

<ofrnxmr> priority and exclusive get banned too

yeah, but I restart. They are empty

I'll just leave monero offline for now

<ofrnxmr> after restart, if you dont have keep-alt-blocks, it should fix itself

<ofrnxmr> But the issue already happeend when you got stuck at 73

I have alt blocks, but I also popped blocks so that's fine

> But the issue already happeend when you got stuck at 73

the branch was at 70

and I was able to insert new blocks on top of it

p2pool had not switched to the shorter branch yet due to miner data not being sent or accepted for the lower chain

<ofrnxmr> yea but the longest chain is at 80+

2025-09-20 14:48:17.240 I Failed to connect to any, trying seeds

still somehow banned

hmm privatebin.net/?786d7dd5f27ea93e#6d…a7VZ8Nf1kLpcpHSkL9UuXYw611iB5sxv9rC

<sneedlewoods_xmr:matrix.org> received my first CHECKPOINT PASSED FOR HEIGHT 2838001 log, thx ofrn

still stuck even after connection at 2837965

f209b2797d0aaedee7a010833b79f8aabcdfa515a85e11ff5ebd64f5a06b0cdb afaik (actually '64)

last time I got stuck like this was when I made that 400-long altchain

then doing pop_blocks

but then I was pruned, now I am not

reset to previous data.mdb let's see if that works

"some people have been pushing me to create a p2pool stratum that just mines to p2pool directly" <- that's just a regular pool with extra steps

yeah, except no need to handle payouts

Unless they run their own nodes, they give away control of their hashrate

that's why I want to setup the p2pool WASM thing instead

at least that allows to run the stack "locally" and able to point to different monero nodes

just passes the control to the provided wasm and upstream monero nodes

sure the ban time is 5 minutes? I have waited one hour ofrnxmr :D

<ofrnxmr> DataHoarder: check your nodes bans

empty.

<ofrnxmr> Its 5mins when s checkpointing node bans a node that sends blocks that dont match

first thing I check on startup

from logs it establishes outgoing connections privatebin.net/?786d7dd5f27ea93e#6d…a7VZ8Nf1kLpcpHSkL9UuXYw611iB5sxv9rC

but connection aborts once data is sent

removed p2pstate.bin as well in case that was troubles

<ofrnxmr> Have you peered to ruckniums node?

--add-priority-node 185.141.216.147 --add-priority-node 208.123.187.228 --add-priority-node 208.123.187.151 --add-priority-node 194.58.47.153

I think that's the four of them

<ofrnxmr> missing Port?

logs show it's attempting connection on right port

defaults to 28080

lemme add them too

with port added, same ips still fail

<ofrnxmr> My browser doesnt like that paste website

might need to reload twice

<ofrnxmr> paste.debian.net for no js www.zerobin.net if you dont mind js

I need to afk so I

I'll leave it running

<rucknium> I see 89.233.207.111 banned for 77824 seconds on my node at 194.54.47.153.

<rucknium> I will unban

<ofrnxmr:xmr.mx> I wonder what the infraction was

<rucknium> Yes, I wonder that, too. I don't know if there is a way to check that after it has already happened.

<ofrnxmr:xmr.mx> i think the ban score only shows on lvl 2

<ofrnxmr:xmr.mx> Fwiw, my checkpointed unattacked nodes didnt ban the attacked node, the attacked node banned the unattacked ones for 86400 with a score of 10

Yeah that's probably a whole day+ ban

<syntheticbird> so mhm

<syntheticbird> yggdrasil support in monerod when?

<syntheticbird> dandelion++ love when everyone have inbound

<ravfx:xmr.mx> It werk

<ravfx:xmr.mx> But we need yggdandelion

<ravfx:xmr.mx> [200:a463:e8f8:b953:238c:7b5b:a7bb:9c6f]:18081/get_info

hey I got two peers :)

<rucknium> DataHoarder: I am trying to get an empirical estimate for how often nodes querying the moneropulse DNS records would get different responses from different domains, because of DNS latency.

I think ofrnxmr was running a script as well with that

<rucknium> Do you know if I specify different @{resolver_IP} in dig, is the response cached or do I get actually independent queries?

<ofrnxmr:xmr.mx> I used @{resolver_ip} in dig. I think the results are cached only when the ttl is wacky.

<ofrnxmr:xmr.mx> i cant say for sure if it returns live data on each query though. It does seem like it

it is cached from the resolver, rucknium

if they do

OR if your network/system hijacks DNS

you might want to do +https for DoH

that way it won't hijack

$ dig +https +dnssec +multi testpoints.moneropulse.ch TXT @1.1.1.1

you are then doing DNS over HTTPs

but yes, 1.1.1.1 is anycast so you may get answers from the same server or different one

there's a pool of these

<rucknium> Ok. What is "multi" in dig?

<rucknium> But not cached on my machine. So I am getting useful info.

that's for querying SOA records specifically

makes it multiline

artifacts of my general DNS server testing, I always add it now :D

<rucknium> So, multi just affects the output format

oh, seems it multilines RRSIG ones as well

yep.

+short might be useful for you

a fun thing you can do is figure out the "issuance" time of the RRSIG

<rucknium> DataHoarder: with dig -t TXT testpoints.moneropulse.de +dnssec +https I am getting

<rucknium> ;; Connection to 127.0.0.53#443(127.0.0.53) for testpoints.moneropulse.de failed: ALPN for HTTP/2 failed.

<rucknium> ;; no servers could be reached

you need to specify server

or run a DNS over HTTPS server locally

you aren't

<rucknium> Oh

<rucknium> ok

+https forces DNS over HTTPs

drop that if you want to query local records only

<rucknium> That makes sense. I will do default without +https and the other resolvers with +https

some might not have +https unless you specify the domain name btw, but most well known "easy" ip resolvers have an https cert given to their ip as well as long name

<rucknium> Now I have 1.1.1.1 (Cloudflare), 208.67.222.222 (OpenDNS), 8.8.8.8 (Google) and 9.9.9.9 (Quad9). Do those sound good? I want to use reasonable resolvers that users and especially mining pools & big merchants would use.

OpenDNS doesn't have ssl cert on 208.67.222.222, lemme see

use instead doh.opendns.com

doesn't work :D

so just query that one with +tcp

<rucknium> +tcp instead of +https?

nvm, they DO have a valid TLS cert

yes

it just fails the request for that one :D

tcp seems to work

also Yandex 77.88.8.8 (has +https)

they say they are no longer using their own dns, but google as upstream. so that's an example of a double cache :)

tbh many samples here as well :D en.wikipedia.org/wiki/Public_recursive_name_server

including filtered ones

if you make a script, might as well add samples

and just end up making a grid-style sequence

<rucknium> What do you mean sample? Yes, it's already a grid.

more samples* aka more dns servers

small/big ISPs

we have a recommended set, but how bad could it be to use a random one? though many ISP servers are only available to their customers

<rucknium> Combination of resolver & moneropulse domain is the grid. Then another grid layer on top of that when I deploy this to multiple VPSes

aha! yeah, getting how the results change based on region is interesting

<rucknium> The table in the wikipedia article says Yandex doesn't offer DNSSEC. That would screw things up, right?

it does offer it

<rucknium> Maybe I will take all resolves on the wikipedia table that meet the requirements.

$ dig +https +dnssec +multi testpoints.moneropulse.ch TXT @77.88.8.8

<rucknium> Ok. I guess I will try each one to check.

alibaba doesn't :D

wiki says tencent does

<rucknium> So far I'm seeing a surprisingly high amount of consistency across queries (at a given point in time), which is "good", but "suspicious".

but doesn't

note that field can mean different things

I say it has DNSSEC if it returns RRSIGs (signatures)

<rucknium> I haven't put the +htpps in there, but even if it's cached everything, still there's high consistency across the domains.

however, DNS resolvers verify these and just return a validated/not bit flag

I think that's what wikipedia list does, so you are trusting the dns server in the end

yeah +https is if you have some network-layer server that overrides any DNS queries

<rucknium> DataHoarder: Any way to check that directly?

you need the not +short output

then if answer header has ad

that means authenticated data

flags: qr rd ra ad;

<rucknium> Got flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

vs flags: qr rd ra;

yep

ad = authenticated data

<rucknium> with dig @1.1.1.1 -t TXT testpoints.moneropulse.de +dnssec

(and on top of that - returned RRSIG

<rucknium> So that means on this machine I don't have to use +https, really, since my DNS queries aren't intercepted.

yeah, just something to keep in mind for replicating results in weird networks

<rucknium> testpoints.moneropulse.de. 60 IN RRSIG TXT 13 3 60 20250922001302 20250919221302 34505 moneropulse.de. u1ZL4b9CdllC4MKP0xwQftd2sA485wyh2wOQBL2Kjbeomx8U0Xnadx4b XcKCzCbjZQ6t7eO+oP9aqVvXmjLaeg==

or if you have a system-wide VPN, that sometimes intercepts queries

<rucknium> Ok thanks.

that's the RRSIG signature, you may discard this or try to inspect the fields. there is issuance/expiration date as relevant

but this might be set in the past and future to take into account bad clocks

this is a fixed offset and if you can "guess" it you can get to-the-second accurate signature creation times

this tends to be

<rucknium> Never thought I'd learn this much about internet infrastructure. But here we are.

the expected clock skew on DNSSEC clients is set by RFC 4035 to 20 seconds, for making these signatures

they require no more than that skew

however, reality disagrees.

on your rrsig you can see it's backdated an extra hour or so :)

I have seen some out there with days

<rucknium> I wonder if the local machine's time was inaccurate enough, would monerod consider the DNSEC signature to be invalid.

monerod doesn't check DNSSEC afaik

it just looks at the AD flag

for RRSIG in order, type coverage, sigAlg, labelCount, original TTL, signature expiration, signature inception, keyTag, zone, signatureData

(yep you can get original TTL this way :D)

instead of the cache ttl

01:16:44 <br-m> <rucknium> Never thought I'd learn this much about internet infrastructure. But here we are.

That was also past me implementing dns-checkpointer and making all the checkboxes and tests pass, then testing it against reality