00:00:14 Where is here? (im not complaining, just not sure what the arrow points to) 00:04:33 Back to me 01:57:26 @rucknium:monero.social: I do not envy your situation. I only wish to thank and support you in these difficult times. 02:15:47 just reminding folks the ignore feature is fantastic 03:27:20 https://matrix.to/#/!toFcRZtpaiwiyapgVO:matrix.org/$bggl3QbjfwLDkycG0G2iSPpdN-dGdTJXTGM7yaUF8KY?via=matrix.org&via=monero.social&via=envs.net, was it published somewhere ? 03:29:58 https://github.com/monero-project/research-lab/issues/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 https://mrelay.p2pool.observer/e/jNus9bYKX1F5U2tE ] 03:54:52 https://matrix.to/#/!toFcRZtpaiwiyapgVO:matrix.org/$gMbsUERKkqvfUGQLisLZBcopEsJzDLkBnk1UsG1CBf0?via=matrix.org&via=monero.social&via=envs.net, "That's why my advocacy is for a finality layer, ..." 03:58:26 https://github.com/monero-project/research-lab/issues/135, https://ccs.getmonero.org/proposals/kayabaNerve-finality-layer-book.html, judging by description it's going to be a book mainly about BFT consensus implemntation 03:59:10 "Achieve finality in less than 20 minutes" it's too slow, can you name few successful projects that use this kind of "finality layer" ? 04:00:16 "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 04:00:37 and it doesn't look like you understnad importance of it 08:16:15 I read somebody here talking about qubic earning "twice as much" due to selfish mining. Where to read a comprehensive analysis of this claim? 08:18:18 If impact on "normal" miners is that big we should also be wary about hashrate of normal miners dropping more due to economics. 09:12:13 The regularly publish "profitability updates" on their blog, e.g. this one: https://qubic.org/blog-detail/epoch-176-recap-general-profitability-update 09:13:38 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. 09:14:22 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. 09:15:14 I think it was something like USD 0.20 from direct XMR mining versus USD 0.40 by mining Qubic 09:16:15 Mind you, that was during a phase where my Qubic "miner" ran Xmrig only half the time 09:16:25 ok but that may be due to other reasons (cfb wanting to get rid of his qubic without crashing value to quickly) 09:16:25 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) 09:17:42 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 09:18:19 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 09:18:57 @rbrunner7: probably a belarussian with lots of qubic to give away 09:20:00 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. 09:20:57 Of course it's completely unclear how much their own buying of their coin, using the mined XMR, influences the price of $QUBIC. 09:22:47 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 09:23:05 https://coinmarketcap.com/currencies/qubic/ 09:23:10 If only slightly credible, for the gullible 09:23:27 It's being going down 09:23:35 Yeah, for a while already :) 09:23:39 https://coinmarketcap.com/currencies/qubic/ 09:24:47 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 09:25:02 I think there was a time where mining with them was three times more profitable 09:25:31 *went down already considerably 09:27:20 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 09:28:55 > <@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. 09:28:55 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. 09:30:17 He is trying to prop up the price by burning Qubic 09:30:43 Or at least that is what he claims 09:30:46 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 09:31:02 Back when it was still online of course 09:32:28 But yeah, it's all pretty intransparent, and of course almost obscenely centralized, who knows for sure what exactly happens. 09:34:14 @rbrunner7: so there is evidence they convert it back? 09:37:23 Not sure, I never tried to actually track their (transparent) transactions and burnings. Burning addresses are known. 09:42:22 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. 09:45:22 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 09:46:34 if i put myself in the situation of this dude, my goal is to convert all the shitcoin to monero 09:47:07 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 09:47:25 lets assume he has 100m$ in qubic, its impossible to just sell on CEX without crashing the value to near-0 09:47:27 and pinky promise you sold the monero for the speculation coin 09:50:30 "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 :) 09:56:41 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. 10:13:35 @longtermwhale:matrix.org: ... but they can burn it 10:14:05 .. and hope that the price goes up 10:49:10 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? 10:58:19 Selfish mining is a well understood attack. 11:07:05 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. 11:07:19 *incentive 11:10:23 @longtermwhale:matrix.org it's only miners getting paid more, until recently qubic was about 82% efficient when selfish mining (actually losing an edge) 11:11:05 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 11:14:15 The attack has mutated from what was originally an attempted 51% attack using bribery to the current 51% attack 11:14:57 Selfish mining attack. 11:14:58 The reorgs they caused were not 51% attacks. It was selfish mining + luck. They don't have 51%. 11:16:33 They never did achieve 51%, but they did try. Hence the mutation to selfish mining 11:17:36 This being said I would not dismiss the 51% attack threat 11:17:56 so it started as 51%^bribery, then to selfish-mining^bribery, and has now morphed to solely selfish-mining? 11:18:25 This seems reasonable to me 11:18:44 Are all the Qubic miners are acting malevolently, or just out of curiosity to see how far their efforts will undermine a "rival"? 11:18:55 I guess both are malevolent, really 11:20:46 It could be both 11:21:32 13:17:56 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) 11:21:41 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. 11:22:06 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 11:22:37 (i think these orphan diff considerations are part of many of the selfish mining mitigations) 11:23:35 also, i think the words right above the images here: https://blocks.p2pool.observer/ give some insight into the profitablity of their selfish mining 11:23:40 It would not change their attack success probability, it would just reduce the number of blocks produced per day. 11:25:16 in theory, wouldn't it reduce the rate that their private altchain grows? 11:26:03 highly probabale i don't have a full grasp on our diff adjustment calc :| 11:26:50 !_! 11:26:52 woops 11:28:03 yeah they are a bit more efficient now gingeropolous, still not above 11:29:22 from conversation I observed yesterday (https://matrix.to/#/!qqRhJzAUfTJRpMHqIP:matrix.org/$EQQBjx-j9Oghf-51neTG2762MKaOmxW2EV8oyEWWzss?via=matrix.org&via=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 11:31:35 The link doesn't work on IRC. 11:31:43 boo 11:32:08 here's a screenshot of the conversation https://i.postimg.cc/76TtZ5Cv/Screenshot-from-2025-09-18-19-58-45.png 11:33:08 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 :) 11:33:59 So they should just start mining Monero directly, not via a known malicious pool. 11:34:28 what is that link actually 11:34:39 well they in that example decided to use another qubic pool instead, which datahoarder pointed out to me is run on the same infrastructure 11:34:50 ah, link to channel, not picture 11:34:54 #monero-offtopic for IRC :) 11:34:59 the first link? that is an autogenerated Share link from element, yeah 11:35:04 it's using old bridge so there is no easy linkage 11:35:37 jetski/QLI/minerlab etc. all use same backend and effective pool. it's all QLI 11:35:42 they are the "same" pool 11:35:54 only apool does different stuff, these pay directly in XMR 11:36:07 (they have their own infrastructure as well) 11:36:43 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 11:37:24 one can speculate on why they are screwing over thier miners, but the rational options to pick from are... slim, I thnk 11:45:57 https://imgix.ranker.com/list_img_v2/12909/2812909/original/food-prospectors-ate-gold-rush-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 https://i.postimg.cc/76TtZ5Cv/Screenshot-from-2025-09-18-19-58-45.png 11:49:19 is there a list of all the qubic related pools? 11:49:36 one sec 11:50:14 nevermine.io qubic.li jetskipool.ai minerlab.io apool.io 11:50:23 (some have xmr subdomains for the xmr part) 11:50:33 nevermine/minerlab directly CNAME to qubic.li 11:51:01 jetski at least has a different IP pool set than qubic.li but has otherwise their infra 11:52:34 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 11:54:00 hey, apool pays in XMR. No idea how that differs from estimate, as they messages are all in chinese 11:54:31 they also at times moved to mine xmr directly without qubic cause they got screwed by them 11:55:22 lets just put it out. I am sure more will come forward. 11:56:48 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 11:58:11 yeah noobs will often just select the pool with the highest hr 11:59:18 i really want to just start fiddling with these selfish mining mitigations 12:15:06 p2pool :) 12:15:53 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) 12:17:34 i can see why but it doesn't seem like a very good idea 12:18:13 indeed. though go-p2pool stratum already offers the ability to set any address via --user (and will produce shares for that) 12:18:17 + subaddress support 12:18:45 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 12:18:53 https://www.reddit.com/r/MoneroMining/comments/1nlwn3z/be_careful_which_pool_you_pick_qubic_pools_will/ maybe you guys can write something better / more official 12:19:49 not even sure if the mining subbreddit is still used much. where do miners communicate usually? 12:22:02 discord :') or nowhere 12:27:34 yeah most miners only care about the profit incentive, not really the coin 12:27:52 those that do are few and rare, and those are the ones you'll find on the subreddits and such 12:31:18 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. 12:31:57 how did they get control over these pools? those are older ones, right? 12:32:59 14:31:57 how did they get control over these pools? those are older ones, right? 12:33:20 ? they didn't gain control, these were qubic's own pools 12:33:35 they just added the XMR Qubic part later on 12:36:54 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? 12:40:03 as I said QLI is specifically run by Qubic 12:40:15 and the others just use their infra, they aren't that big, besides apool 12:40:31 the others besides jetski have all other coins as well. 13:15:09 what if their bursty hashrate is not just a result of selfish mining, but also them selectively scamming miners? 13:17:35 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 13:19:12 this is research lounge not collusion theories channel 13:19:36 Also - the payouts are shifted one week 13:19:51 So they use a different week to do payouts, which ofc, it's another abstraction layer 13:21:00 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. 13:22:55 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) 13:27:15 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 13:29:21 > Anyone claiming higher rewards than just mining monero directly has to justify where the additional yield comes from. 13:29:21 They don't, they pay in qubic and hope the burn just causes speculators to keep price up 13:29:24 or miners not selling 13:29:32 it's paper money, not direct payouts 13:30:11 + their own qubic mining 13:44:15 my testnet node hasn't repro the issue ofrnxmr yet, hmm 13:46:43 Have to time it right 13:47:13 New checkpoint exists, node has not seen the new checkpoint yet, reorg the node below that checkpoint height 13:47:14 yeah, would be great if I could get my local node stuck but as always the debugging part makes the bugs flee away 13:47:34 so delaying dns updates would help in this case right? 13:48:35 No, it depends on if the node receivesĀ a new checkpoint that references an alt chain 13:49:05 fixing the logic of that massive if statement is probably the fix 13:49:08 yeah, I think I can manage that if I mine on my own node and delay checkpoint updates 13:49:25 what I don't understand is why that runs *twice* with different errors 13:49:34 oh, help to reproduce? Yeah 13:50:02 and lemme make sure I do NOT broadcast any found blocks via submit_block instantly 13:50:07 that will also help 13:52:41 hopefully I can trigger it 13:54:08 I am already generating orphans 14:00:15 yep I have a long orphan chain that I'm not disclosing 14:00:32 if other blocks grow now and checkpoint is set my node should enter the condition 14:09:58 ok, now I am, had to not reply to some requests 14:13:13 I have a selfish chain going up to 2837981 root at 2837970 14:13:43 there are 3 blocks now on the other side, so once a checkpoint is set that should trigger my node to fail 14:13:57 5 :) 14:14:39 https://irc.gammaspectra.live/1da3cdcbbaba891d/image.png 14:15:53 I have been banned by peers, good sign :) 14:17:51 IN TXT "2837971:3f2246b3a36804fa4220490bf2d25be0a2a57568337a04a65ca238a2b0bbcba5" 14:18:01 that should trigger my node once it fetches 14:19:35 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 , 14:19:35 chain height 2837973) 14:20:47 I am stuck at 2837973 14:21:24 funnily that did not issue a ZMQ change of miner data 14:22:00 no, didn't trigger. I switched to alternate chain 14:26:11 In order to test the DNS checkpoints on testnet you use a node which uses this PR https://github.com/monero-project/monero/pull/10075 and you also need to change the testnet_dns_urls in src/checkpoints/checkpoints.cpp, right? 14:26:11 If that's the case, can anyone share those urls again, please? 14:31:30 No 14:32:17 https://github.com/nahuhh/monero/tree/dns_testpoints-public 14:32:18 Use this branch 14:37:51 @datahoarder, it didnt get stuck? 14:37:57 nope 14:38:05 though I got well banned, waiting for unban :D 14:38:16 What height are you on? 14:39:10 it switched fully to 2837973 (2837973 is the highest I had when bans happened) 14:39:15 You should be unbanned in 5mins ruckniums and my nodes 14:39:20 I popped down to 64 now 14:39:27 Check your own bans 14:39:31 yeah I just had mined some lingering blocks on top of that 14:39:32 bans 14:39:37 I have priority nodes added 14:39:46 so those don't get banned 14:40:00 priority and exclusive get banned too 14:40:34 yeah, but I restart. They are empty 14:40:41 I'll just leave monero offline for now 14:41:05 after restart, if you dont have keep-alt-blocks, it should fix itself 14:41:20 But the issue already happeend when you got stuck at 73 14:41:22 I have alt blocks, but I also popped blocks so that's fine 14:41:27 > But the issue already happeend when you got stuck at 73 14:41:31 the branch was at 70 14:41:39 and I was able to insert new blocks on top of it 14:42:09 p2pool had not switched to the shorter branch yet due to miner data not being sent or accepted for the lower chain 14:42:11 yea but the longest chain is at 80+ 14:48:32 2025-09-20 14:48:17.240 I Failed to connect to any, trying seeds 14:48:38 still somehow banned 14:49:39 hmm https://privatebin.net/?786d7dd5f27ea93e#6ddbBEhUta7VZ8Nf1kLpcpHSkL9UuXYw611iB5sxv9rC 15:02:40 received my first CHECKPOINT PASSED FOR HEIGHT 2838001 log, thx ofrn 15:04:12 still stuck even after connection at 2837965 15:05:30 f209b2797d0aaedee7a010833b79f8aabcdfa515a85e11ff5ebd64f5a06b0cdb afaik (actually '64) 15:08:40 last time I got stuck like this was when I made that 400-long altchain 15:08:51 then doing pop_blocks 15:08:56 but then I was pruned, now I am not 15:11:28 reset to previous data.mdb let's see if that works 15:28:50 "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 15:29:44 yeah, except no need to handle payouts 15:29:57 Unless they run their own nodes, they give away control of their hashrate 15:29:57 that's why I want to setup the p2pool WASM thing instead 15:30:25 at least that allows to run the stack "locally" and able to point to different monero nodes 15:31:05 just passes the control to the provided wasm and upstream monero nodes 15:45:11 sure the ban time is 5 minutes? I have waited one hour ofrnxmr :D 15:52:12 DataHoarder: check your nodes bans 15:52:18 empty. 15:52:27 Its 5mins when s checkpointing node bans a node that sends blocks that dont match 15:52:30 first thing I check on startup 15:53:07 from logs it establishes outgoing connections https://privatebin.net/?786d7dd5f27ea93e#6ddbBEhUta7VZ8Nf1kLpcpHSkL9UuXYw611iB5sxv9rC 15:53:14 but connection aborts once data is sent 15:53:36 removed p2pstate.bin as well in case that was troubles 15:53:36 Have you peered to ruckniums node? 15:53:52 --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 15:54:00 I think that's the four of them 15:54:07 missing Port? 15:54:15 logs show it's attempting connection on right port 15:54:20 defaults to 28080 15:54:51 lemme add them too 15:55:53 https://privatebin.net/?7919f4956cd7e977#GxEoc1A31xKtowKNtF6vKPGXeEAkgFqh5RDmam9iDDMF 15:56:00 with port added, same ips still fail 16:01:03 My browser doesnt like that paste website 16:01:16 might need to reload twice 16:01:21 paste.debian.net for no js www.zerobin.net if you dont mind js 16:01:50 https://paste.debian.net/hidden/65a5149e/ 16:10:42 I need to afk so I 16:10:49 I'll leave it running 16:34:30 I see 89.233.207.111 banned for 77824 seconds on my node at 194.54.47.153. 16:35:24 I will unban 16:35:32 I wonder what the infraction was 16:35:58 Yes, I wonder that, too. I don't know if there is a way to check that after it has already happened. 16:37:18 i think the ban score only shows on lvl 2 16:38:24 Fwiw, my checkpointed unattacked nodes didnt ban the attacked node, the attacked node banned the unattacked ones for 86400 with a score of 10 16:45:12 Yeah that's probably a whole day+ ban 17:14:15 so mhm 17:14:23 yggdrasil support in monerod when? 17:14:59 dandelion++ love when everyone have inbound 17:16:04 It werk 17:16:04 But we need yggdandelion 17:16:04 http://[200:a463:e8f8:b953:238c:7b5b:a7bb:9c6f]:18081/get_info 19:45:39 hey I got two peers :) 22:42:30 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. 22:42:51 I think ofrnxmr was running a script as well with that 22:43:26 Do you know if I specify different @{resolver_IP} in dig, is the response cached or do I get actually independent queries? 22:44:35 I used @{resolver_ip} in dig. I think the results are cached only when the ttl is wacky. 22:45:39 i cant say for sure if it returns live data on each query though. It does seem like it 22:45:46 it is cached from the resolver, rucknium 22:45:47 if they do 22:45:58 OR if your network/system hijacks DNS 22:46:32 you might want to do +https for DoH 22:46:37 that way it won't hijack 22:47:03 $ dig +https +dnssec +multi testpoints.moneropulse.ch TXT @1.1.1.1 22:47:11 you are then doing DNS over HTTPs 22:47:56 but yes, 1.1.1.1 is anycast so you may get answers from the same server or different one 22:48:00 there's a pool of these 22:48:16 Ok. What is "multi" in dig? 22:48:42 But not cached on my machine. So I am getting useful info. 22:49:06 that's for querying SOA records specifically 22:49:09 makes it multiline 22:49:21 artifacts of my general DNS server testing, I always add it now :D 22:49:41 So, multi just affects the output format 22:49:45 oh, seems it multilines RRSIG ones as well 22:49:49 yep. 22:50:39 +short might be useful for you 22:51:57 a fun thing you can do is figure out the "issuance" time of the RRSIG 22:52:25 DataHoarder: with dig -t TXT testpoints.moneropulse.de +dnssec +https I am getting 22:52:29 ;; Connection to 127.0.0.53#443(127.0.0.53) for testpoints.moneropulse.de failed: ALPN for HTTP/2 failed. 22:52:29 ;; no servers could be reached 22:52:38 you need to specify server 22:52:47 or run a DNS over HTTPS server locally 22:52:49 you aren't 22:52:52 Oh 22:52:55 ok 22:53:02 +https forces DNS over HTTPs 22:53:14 drop that if you want to query local records only 22:53:44 That makes sense. I will do default without +https and the other resolvers with +https 22:54:22 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 22:55:59 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. 22:56:23 OpenDNS doesn't have ssl cert on 208.67.222.222, lemme see 22:56:38 use instead doh.opendns.com 22:56:56 doesn't work :D 22:56:59 https://support.opendns.com/hc/en-us/articles/360038086532-Using-DNS-over-HTTPS-DoH-with-OpenDNS 22:57:06 so just query that one with +tcp 22:57:24 +tcp instead of +https? 22:58:09 nvm, they DO have a valid TLS cert 22:58:11 yes 22:58:27 it just fails the request for that one :D 22:58:32 tcp seems to work 22:59:18 also Yandex 77.88.8.8 (has +https) 23:00:32 they say they are no longer using their own dns, but google as upstream. so that's an example of a double cache :) 23:01:00 tbh many samples here as well :D https://en.wikipedia.org/wiki/Public_recursive_name_server 23:01:04 including filtered ones 23:03:41 if you make a script, might as well add samples 23:03:53 and just end up making a grid-style sequence 23:04:26 What do you mean sample? Yes, it's already a grid. 23:04:41 more samples* aka more dns servers 23:04:46 small/big ISPs 23:05:13 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 23:05:22 Combination of resolver & moneropulse domain is the grid. Then another grid layer on top of that when I deploy this to multiple VPSes 23:05:52 aha! yeah, getting how the results change based on region is interesting 23:07:31 The table in the wikipedia article says Yandex doesn't offer DNSSEC. That would screw things up, right? 23:07:48 it does offer it 23:07:52 Maybe I will take all resolves on the wikipedia table that meet the requirements. 23:08:16 $ dig +https +dnssec +multi testpoints.moneropulse.ch TXT @77.88.8.8 23:08:17 Ok. I guess I will try each one to check. 23:08:54 alibaba doesn't :D 23:09:40 wiki says tencent does 23:09:40 So far I'm seeing a surprisingly high amount of consistency across queries (at a given point in time), which is "good", but "suspicious". 23:09:42 but doesn't 23:10:09 note that field can mean different things 23:10:21 I say it has DNSSEC if it returns RRSIGs (signatures) 23:10:36 I haven't put the +htpps in there, but even if it's cached everything, still there's high consistency across the domains. 23:10:42 however, DNS resolvers verify these and just return a validated/not bit flag 23:10:58 I think that's what wikipedia list does, so you are trusting the dns server in the end 23:11:21 yeah +https is if you have some network-layer server that overrides any DNS queries 23:12:01 DataHoarder: Any way to check that directly? 23:12:15 you need the not +short output 23:12:55 then if answer header has ad 23:12:59 that means authenticated data 23:13:24 flags: qr rd ra ad; 23:13:31 Got flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 23:13:32 vs flags: qr rd ra; 23:13:34 yep 23:13:39 ad = authenticated data 23:13:41 with dig @1.1.1.1 -t TXT testpoints.moneropulse.de +dnssec 23:13:52 (and on top of that - returned RRSIG 23:14:15 So that means on this machine I don't have to use +https, really, since my DNS queries aren't intercepted. 23:14:33 yeah, just something to keep in mind for replicating results in weird networks 23:14:42 testpoints.moneropulse.de. 60 IN RRSIG TXT 13 3 60 20250922001302 20250919221302 34505 moneropulse.de. u1ZL4b9CdllC4MKP0xwQftd2sA485wyh2wOQBL2Kjbeomx8U0Xnadx4b XcKCzCbjZQ6t7eO+oP9aqVvXmjLaeg== 23:14:45 or if you have a system-wide VPN, that sometimes intercepts queries 23:14:47 Ok thanks. 23:15:10 that's the RRSIG signature, you may discard this or try to inspect the fields. there is issuance/expiration date as relevant 23:15:27 but this might be set in the past and future to take into account bad clocks 23:15:49 this is a fixed offset and if you can "guess" it you can get to-the-second accurate signature creation times 23:15:57 this tends to be 23:16:44 Never thought I'd learn this much about internet infrastructure. But here we are. 23:16:58 the expected clock skew on DNSSEC clients is set by RFC 4035 to 20 seconds, for making these signatures 23:17:07 they require no more than that skew 23:17:13 however, reality disagrees. 23:17:45 on your rrsig you can see it's backdated an extra hour or so :) 23:17:56 I have seen some out there with days 23:19:41 I wonder if the local machine's time was inaccurate enough, would monerod consider the DNSEC signature to be invalid. 23:19:54 monerod doesn't check DNSSEC afaik 23:19:58 it just looks at the AD flag 23:20:16 for RRSIG in order, type coverage, sigAlg, labelCount, original TTL, signature expiration, signature inception, keyTag, zone, signatureData 23:20:38 (yep you can get original TTL this way :D) 23:20:44 instead of the cache ttl 23:24:38 01:16:44 Never thought I'd learn this much about internet infrastructure. But here we are. 23:24:38 That was also past me implementing dns-checkpointer and making all the checkboxes and tests pass, then testing it against reality