00:10:57 <DataHoarder> above list of Qubic blocks updated for epoch 175, total of 8181 entries https://irc.gammaspectra.live/1971e3934d09f2ff/qubic-blocks-epoch175.csv 
00:11:44 <DataHoarder> epoch 175: 45hzuq7TBR3J89EXkAmZuqYDGbpdCxf5qXU2dMYb5jorR2JuS7V4T9XhuMAGwF7CG895Suf6XR4PUWbLUhB5UnzcS3d6MDy / View key: 9267d1762b0f3262029be73e30f5158159c2f38e86b9d745231e57141afccd0a
00:29:24 <m-relay> <r​ottenwheel:unredacted.org> kayabanerve: thoughts on the detective mining thinger? https://github.com/monero-project/research-lab/issues/140
00:31:35 <m-relay> <r​ottenwheel:unredacted.org> <n​ioc> the word "just" should be banned from the english language as it serves no purpose
00:31:39 <m-relay> <r​ottenwheel:unredacted.org> such a natzee.
00:39:40 * nioc wonders who rotten is talking about 
00:40:35 <nioc> Sorry, I must of had a stroke. Please continue 
00:55:25 <DataHoarder> qubic's latest wallet shows all the transactions they made back to their own wallet to generate "decoy" transactions
00:55:37 <DataHoarder> verified list on https://paste.debian.net/hidden/c23d4585/ and they all got sent back to themselves
00:56:17 <DataHoarder> it's still live and generating transactions back to their own wallet at this moment
00:58:59 <m-relay> <l​ordx3nu:matrix.org> when did they start spamming transactions? there doesn't appear to be any noticeable jump in daily transactions today
00:59:42 <DataHoarder> this was done as a way to prevent detective mining https://github.com/monero-project/research-lab/issues/140#issuecomment-3213511402
01:00:07 <DataHoarder> so they just are continuously feeding their own wallet with their own transactions from their own miner outputs
01:00:26 <m-relay> <l​ordx3nu:matrix.org> oh nice
01:01:04 <DataHoarder> 1-3 about every 2 minutes
01:02:01 <DataHoarder> they aren't even mining at the moment, why are they doing this spam?
01:44:08 <m-relay> <k​ayabanerve:matrix.org> rottenwheel: I'm not convinced it'd be effective vs a stupid cat and mouse game between sysadmins. It also doesn't stop larger adversaries who can run a private pool, preventing snooping.
06:21:05 <m-relay> <m​onerobull:matrix.org> detective mining is what the kids these days would describe as "cope"
06:37:18 <m-relay> <r​ottenwheel:unredacted.org> nioc https://libera.monerologs.net/monero-research-lab/20250827#c575142 aye, aye just catching up right this second...
06:40:37 <m-relay> <r​ottenwheel:unredacted.org> 😳 https://libera.monerologs.net/monero-research-lab/20250827#c575190
06:40:52 <m-relay> <r​ottenwheel:unredacted.org> > <k​ayabanerve:matrix.org> Can I have my CCS merged and can the community agree PoW isn't a fundamental tenant of Monero, security and decentralization is? 😅
06:56:17 <m-relay> <r​ottenwheel:unredacted.org> xmrack: oops, maybe we could take that [conversation](https://matrix.to/#/!toFcRZtpaiwiyapgVO:matrix.org/$vEVoq5PJnBiZ02muWhE1vwZxpe-aii8SUGqNJUqKnYU?via=matrix.org&via=monero.social&via=envs.net) to -lounge, haha.
06:59:35 <m-relay> <r​ottenwheel:unredacted.org> jw has this lil thing, about emission analysis stuff... https://github.com/jwinterm/blockchain-emission-analysis
07:42:58 <midipoet> does anybody know approximately how much fees would have to increase by, to meaningfully disincentivize selfish mining? is it like 10x or 100x? i guess it's the block reward/fees ratio, but i feel  like a bad actor wouldn't care, regardless? or is the thesis that higher fees would attract a higher percentage of honest miners?
10:42:56 <m-relay> <m​onerobull:matrix.org> probably 100x
10:43:23 <m-relay> <m​onerobull:matrix.org> btw it seems like most of the recent selfish mining attempts have resulted in failute
10:43:31 <m-relay> <m​onerobull:matrix.org> btw it seems like most of the recent selfish mining attempts have resulted in failure
10:44:31 <m-relay> <m​onerobull:matrix.org> https://matrix.monero.social/_matrix/media/v1/download/matrix.org/QGolviKrrgGfUiklkgwZjBAH
10:49:08 <m-relay> <d​atahoarder:monero.social> They have not attempted selfish mining. Those are just their regular orphans (they have quite delayed template generation)
11:00:31 <br-m> <shortwavesurfer2009> Shouldn't their attack be starting soon? From what I understand, it's on Mondays, Thursdays, and Saturdays from 12 UTC.
11:12:35 <nioc> looks like in 48 minutes
11:12:52 <DataHoarder> hey, the irc bridge works :D
11:13:35 <nioc> \o/
11:14:34 <nioc> will we be able to see matrix links now?
11:16:57 <br-m> <datahoarder> https://mrelay.p2pool.observer/m/monero.social/AxNlYHTYkysoQdaekqcYzsII.png (aeb674a9cb0ffbe145400908a781c353.png)
11:17:03 <br-m> <datahoarder> see ^ nioc
11:17:36 <DataHoarder> it also maps nick pings and links to rooms across IRC/Matrix
11:18:25 <DataHoarder> #monero #monero-community-dev #monero-community #monero-research-lounge #monero-research-lab are included on the first to get the new bridge
11:18:43 <nioc> <3
12:10:22 <DataHoarder> qubic has started selfish mining straight up
12:10:58 <nioc> right on time
12:16:56 <DataHoarder> they might be more confident - usually they wait until the evening
12:22:32 <nioc> I was going by the charts which, at least to me, give a different time depending on the time scale selected
12:24:25 <DataHoarder> I mean, the marathon starts at 12:00 UTC, but they aren't always selfish enabled 
12:25:06 <nioc> Ok
13:13:56 <DataHoarder> they are mining 85 height now
13:44:15 <br-m> <shortwavesurfer2009> 4 reorg detected
13:44:33 <DataHoarder> yeah they were on par at 91
13:44:42 <DataHoarder> they then found 92 and 93 quick to reorg
13:45:48 <br-m> <syntheticbird> THE BRIDGE WORKS LETS GO
14:54:16 <DataHoarder> you can track how monero or qubic tips diverge here https://qubic-snooper.p2pool.observer/tips.txt
14:54:30 <br-m> <datahoarder> example output
14:54:30 <br-m> <datahoarder> https://mrelay.p2pool.observer/p/zb6u1a8KU1lSUlhf/1.txt (code snippet, 6 lines)
14:54:40 <DataHoarder> so they are +2 heights ahead of monero
15:14:24 <br-m> <lordx3nu:matrix.org> Thank you!
16:02:34 <br-m> <ofrnxmr:xmr.mx> can you reset the checkpoints. Not sure what happened but looks like the checkpointed chain got split off at some point
16:03:37 <br-m> <ofrnxmr:xmr.mx> I need to test patch that changes bantime
17:58:53 <br-m> <rucknium> It looks like the checkpointing node is no longer recognizing the .info domains. I will switch to the .net domains, which require re-compile.
18:08:04 <plowsof> thank you for your service m-relay, you will be deeply missed 
18:08:29 <plowsof> wrong channel, sorry 
18:13:51 <br-m> <rucknium> : Should be working again now.
18:16:26 <br-m> <rucknium> My log was showing
18:16:39 <br-m> <rucknium> 2025-08-28 18:09:30.410 W Invalid DNSSEC TXT record signature for checkpoints.moneroconsensus.info: validation failure <checkpoints.moneroconsensus.info. TXT IN>: no DNSSEC records from 127.0.0.53 for DS moneroconsensus.info. while building chain of trust
18:16:39 <br-m> <rucknium> 2025-08-28 18:09:30.411 W Invalid DNSSEC TXT record signature for checkpoints.moneronet.info: validation failure <checkpoints.moneronet.info. TXT IN>: no DNSSEC records from 127.0.0.53 for DS moneronet.info. while building chain of trust
18:16:39 <br-m> <rucknium> 2025-08-28 18:09:30.411 W WARNING: no two valid DNS TXT records were received
18:17:42 <br-m> <rucknium> Maybe my DNS provider became more strict or something. I swear those domains are innocent.
19:09:44 <br-m> <ofrnxmr> Problem with the script: if your node rolls back to a checkpoint, it creates an earlier checkpoint
19:11:04 <br-m> <ofrnxmr> In this case, checkpoint was at 524(?), rolled back to 523 and created a checkpoint for 521
19:11:31 <br-m> <ofrnxmr> Im trying to mine to your node, but its rejecting the blocks that i mine
19:17:26 <br-m> <lm:matrix.baermail.fr> Lurking on the qubic discord, someone claiming to have a farm of x5 bitmain was pissed off because he didn't get 3x rewards while mining on qubic. So maybe they are not even paying their miners like they promised.
19:18:44 <br-m> <lm:matrix.baermail.fr> And the response, "just wait for qubic price to boom"
19:19:07 <br-m> <lm:matrix.baermail.fr> That did not pleased him
19:27:16 <br-m> <rucknium> : So, the script shouldn't blindly update the DNS record. Only update if the new height is higher than the old height.
19:28:13 <br-m> <ofrnxmr> I'm not sure if that is why the blocks are being rejected, but yeah
19:29:38 <br-m> <ofrnxmr> It could be though. My node seems to throwing errors about 524 checkpoint, even though dns is on 521. our nodes are on 523 (Im mining 524)
19:30:03 <br-m> <ofrnxmr> So its probably rejecting a different 524 than the older checkpoint
19:34:52 <br-m> <rucknium> 2025-08-28 19:28:15.901 W CHECKPOINT FAILED FOR HEIGHT 2821524. EXPECTED HASH: <8f395e848f2a3e1c3ca03b3de49cbd4005556275fcaf19b8ee68e59f3d756521>, FETCHED HASH: <a71af163e69cd212a8e03e8bf69dc1a098b9a66a66d9984b7b70f343966bb495>
19:34:52 <br-m> <rucknium> 2025-08-28 19:28:15.901 E CHECKPOINT VALIDATION FAILED
19:35:10 <br-m> <rucknium> is what I saw on the checkpointing node. Resetting.
19:37:08 <br-m> <rucknium> checkpointing node is enforcing checkpoints on itself again.
20:06:28 <br-m> <rucknium> The testnetnode{1,2,3,4}.moneroconsensus.info seem to be down because they probably can't handle the recent deep re-orgs on testnet:
20:06:28 <br-m> <rucknium> 84 blocks long, from height 2820850 (703 deep), diff 1123684676890: 034c761eda58bab4aaa890897c2f2bede6a5565ff9d798edfddc5480b1244fdc
20:06:28 <br-m> <rucknium> 201 blocks long, from height 2821103 (450 deep), diff 1123721422257: dd4e203ce5d1f4fecf5f02d96e63698f54b47dbcea4271513bce1d560cc1a865
20:07:16 <br-m> <ofrnxmr:xmr.mx> @rucknium: I didnt do an 84 block reorg 😅
20:07:53 <br-m> <ofrnxmr:xmr.mx> The biggest i did was ~15 blocks
20:09:33 <br-m> <ofrnxmr:xmr.mx> {4} loaded for me
20:11:35 <br-m> <ofrnxmr:xmr.mx> {1} crashes
20:12:32 <br-m> <rucknium> I just cleared the alt blocks on {1}. It won't load properly until new alt blocks appear
20:13:23 <br-m> <ofrnxmr:xmr.mx> https://testnetnode2.moneroconsensus.info/ this one works as well
20:13:42 <br-m> <rucknium> The other ones are starting to load OK again. Make sure you set it to tree view :D
20:14:54 <br-m> <ofrnxmr:xmr.mx> yeah :P
20:15:14 <br-m> <ofrnxmr:xmr.mx> i have a patch (from vt) to reduce bans to 5mins
20:16:02 <br-m> <ofrnxmr:xmr.mx> Seems to work well
20:16:46 <br-m> <rucknium> Can you share the patch?
20:20:42 <br-m> <ofrnxmr:xmr.mx> https://mrelay.p2pool.observer/m/xmr.mx/XKGeYtPlmJNemheJuNvWFWWI.diff (light_ban2.diff)
20:22:12 <DataHoarder> IRC can get the file :D
20:23:08 <br-m> <ofrnxmr:xmr.mx> :D
20:23:57 <ofrnxmr> nice
20:35:20 <br-m> <gingeropolous> @lm:matrix.baermail.fr: seems like we should get randomx v2 asap
20:38:20 <br-m> <gingeropolous> wow the braincells
20:39:25 <br-m> <gingeropolous> so you have a farm of x5s, which while being CPUs, somehow bitmain screwed up and made them only capable of mining monero, and you decide to switch that farm to a mining effort that is attacking monero.
20:40:39 <br-m> <gingeropolous> i guess the standard ASIC logic doesn't hold up across the board
21:36:22 <br-m> <ofrnxmr:xmr.mx> @tevador, regardinf #144, would it make sense to have the normal 1440 block difficulty calculation, but to adjust for uncle difficulty near immediately? So, instead of increasing the difficulty tomorrow based on todays uncles, it would increase the difficulty now
21:38:42 <br-m> <ofrnxmr:xmr.mx> When attackers game the difficulty, they usually mine when diff is low and stop when diff starts to catch up. I guess i'm thinking about how to allow diff to burst higher during short term high block rates (both with and without uncles)