above list of Qubic blocks updated for epoch 175, total of 8181 entries irc.gammaspectra.live/1971e3934d09f2ff/qubic-blocks-epoch175.csv

epoch 175: 45hzuq7TBR3J89EXkAmZuqYDGbpdCxf5qXU2dMYb5jorR2JuS7V4T9XhuMAGwF7CG895Suf6XR4PUWbLUhB5UnzcS3d6MDy / View key: 9267d1762b0f3262029be73e30f5158159c2f38e86b9d745231e57141afccd0a

<r​ottenwheel:unredacted.org> kayabanerve: thoughts on the detective mining thinger? monero-project/research-lab #140

<r​ottenwheel:unredacted.org> <n​ioc> the word "just" should be banned from the english language as it serves no purpose

<r​ottenwheel:unredacted.org> such a natzee.

Sorry, I must of had a stroke. Please continue

qubic's latest wallet shows all the transactions they made back to their own wallet to generate "decoy" transactions

verified list on paste.debian.net/hidden/c23d4585 and they all got sent back to themselves

it's still live and generating transactions back to their own wallet at this moment

<l​ordx3nu:matrix.org> when did they start spamming transactions? there doesn't appear to be any noticeable jump in daily transactions today

this was done as a way to prevent detective mining monero-project/research-lab #140#issuecomment-3213511402

so they just are continuously feeding their own wallet with their own transactions from their own miner outputs

<l​ordx3nu:matrix.org> oh nice

1-3 about every 2 minutes

they aren't even mining at the moment, why are they doing this spam?

<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.

<m​onerobull:matrix.org> detective mining is what the kids these days would describe as "cope"

<r​ottenwheel:unredacted.org> nioc libera.monerologs.net/monero-research-lab/20250827#c575142 aye, aye just catching up right this second...

<r​ottenwheel:unredacted.org> 😳 libera.monerologs.net/monero-research-lab/20250827#c575190

<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? 😅

<r​ottenwheel:unredacted.org> xmrack: oops, maybe we could take that [conversation](matrix.to/#/!toFcRZtpaiwiyapgVO:mat….org&via=monero.social&via=envs.net) to -lounge, haha.

<r​ottenwheel:unredacted.org> jw has this lil thing, about emission analysis stuff... github.com/jwinterm/blockchain-emission-analysis

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?

<m​onerobull:matrix.org> probably 100x

<m​onerobull:matrix.org> btw it seems like most of the recent selfish mining attempts have resulted in failute

<m​onerobull:matrix.org> btw it seems like most of the recent selfish mining attempts have resulted in failure

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/QGolviKrrgGfUiklkgwZjBAH

<d​atahoarder:monero.social> They have not attempted selfish mining. Those are just their regular orphans (they have quite delayed template generation)

<shortwavesurfer2009> Shouldn't their attack be starting soon? From what I understand, it's on Mondays, Thursdays, and Saturdays from 12 UTC.

looks like in 48 minutes

hey, the irc bridge works :D

\o/

will we be able to see matrix links now?

<datahoarder> mrelay.p2pool.observer/m/monero.social/AxNlYHTYkysoQdaekqcYzsII.png (aeb674a9cb0ffbe145400908a781c353.png)

<datahoarder> see ^ nioc

it also maps nick pings and links to rooms across IRC/Matrix

#monero #monero-community-dev #monero-community #monero-research-lounge #monero-research-lab are included on the first to get the new bridge

<3

qubic has started selfish mining straight up

right on time

they might be more confident - usually they wait until the evening

I was going by the charts which, at least to me, give a different time depending on the time scale selected

I mean, the marathon starts at 12:00 UTC, but they aren't always selfish enabled

Ok

they are mining 85 height now

<shortwavesurfer2009> 4 reorg detected

yeah they were on par at 91

they then found 92 and 93 quick to reorg

<syntheticbird> THE BRIDGE WORKS LETS GO

you can track how monero or qubic tips diverge here qubic-snooper.p2pool.observer/tips.txt

<datahoarder> example output

<datahoarder> mrelay.p2pool.observer/p/zb6u1a8KU1lSUlhf/1.txt (code snippet, 6 lines)

so they are +2 heights ahead of monero

<lordx3nu:matrix.org> Thank you!

<ofrnxmr:xmr.mx> can you reset the checkpoints. Not sure what happened but looks like the checkpointed chain got split off at some point

<ofrnxmr:xmr.mx> I need to test patch that changes bantime

<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.

thank you for your service m-relay, you will be deeply missed

wrong channel, sorry

<rucknium> : Should be working again now.

<rucknium> My log was showing

<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

<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

<rucknium> 2025-08-28 18:09:30.411 W WARNING: no two valid DNS TXT records were received

<rucknium> Maybe my DNS provider became more strict or something. I swear those domains are innocent.

<ofrnxmr> Problem with the script: if your node rolls back to a checkpoint, it creates an earlier checkpoint

<ofrnxmr> In this case, checkpoint was at 524(?), rolled back to 523 and created a checkpoint for 521

<ofrnxmr> Im trying to mine to your node, but its rejecting the blocks that i mine

<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.

<lm:matrix.baermail.fr> And the response, "just wait for qubic price to boom"

<lm:matrix.baermail.fr> That did not pleased him

<rucknium> : So, the script shouldn't blindly update the DNS record. Only update if the new height is higher than the old height.

<ofrnxmr> I'm not sure if that is why the blocks are being rejected, but yeah

<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)

<ofrnxmr> So its probably rejecting a different 524 than the older checkpoint

<rucknium> 2025-08-28 19:28:15.901 W CHECKPOINT FAILED FOR HEIGHT 2821524. EXPECTED HASH: <8f395e848f2a3e1c3ca03b3de49cbd4005556275fcaf19b8ee68e59f3d756521>, FETCHED HASH: <a71af163e69cd212a8e03e8bf69dc1a098b9a66a66d9984b7b70f343966bb495>

<rucknium> 2025-08-28 19:28:15.901 E CHECKPOINT VALIDATION FAILED

<rucknium> is what I saw on the checkpointing node. Resetting.

<rucknium> checkpointing node is enforcing checkpoints on itself again.

<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:

<rucknium> 84 blocks long, from height 2820850 (703 deep), diff 1123684676890: 034c761eda58bab4aaa890897c2f2bede6a5565ff9d798edfddc5480b1244fdc

<rucknium> 201 blocks long, from height 2821103 (450 deep), diff 1123721422257: dd4e203ce5d1f4fecf5f02d96e63698f54b47dbcea4271513bce1d560cc1a865

<ofrnxmr:xmr.mx> @rucknium: I didnt do an 84 block reorg 😅

<ofrnxmr:xmr.mx> The biggest i did was ~15 blocks

<ofrnxmr:xmr.mx> {4} loaded for me

<ofrnxmr:xmr.mx> {1} crashes

<rucknium> I just cleared the alt blocks on {1}. It won't load properly until new alt blocks appear

<ofrnxmr:xmr.mx> testnetnode2.moneroconsensus.info this one works as well

<rucknium> The other ones are starting to load OK again. Make sure you set it to tree view :D

<ofrnxmr:xmr.mx> yeah :P

<ofrnxmr:xmr.mx> i have a patch (from vt) to reduce bans to 5mins

<ofrnxmr:xmr.mx> Seems to work well

<rucknium> Can you share the patch?

<ofrnxmr:xmr.mx> mrelay.p2pool.observer/m/xmr.mx/XKGeYtPlmJNemheJuNvWFWWI.diff (light_ban2.diff)

IRC can get the file :D

<ofrnxmr:xmr.mx> :D

nice

<gingeropolous> @lm:matrix.baermail.fr: seems like we should get randomx v2 asap

<gingeropolous> wow the braincells

<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.

<gingeropolous> i guess the standard ASIC logic doesn't hold up across the board

<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

<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)