02:10:33 You were completely wrong. 02:11:38 Which is why I, along with many others, were able to make money from Qubic's stupidity, rather than spreading misinformation. 02:15:21 From the profits I earn through shorting Qubic, 10% will be donated towards CCS proposals. Funding Monero's growth from Qubic's decline. What are you doing other than spreading FUD? 04:27:34 Your 10 dollars will be a good addition to development budget. I was buying hashrate to slow Qubic down when they were at their peak 04:29:20 Your 10 dollars will be a good addition to the development budget. I was buying hashrate to slow Qubic down when they were at their peak 13:29:17 But in all seriousness though. was i wrong? Yeah I was, but don’t really want to play dumb gotcha games and I’m actually glad I was wrong 16:44:48 qubic has started selfish mining attempts according to pool data 16:44:55 but seems they fell behind 16:45:12 they don't have more than network currently 16:56:04

What do you mean by "more than network currently"? 16:56:58 51% 16:57:32 so they can still get lucky and get some orphans 16:58:17

Yes, they are far from it. Seems like they have lost some miners and mining power as a result in the last few days. 16:59:58 TOTAL BOT ANNIHILATION 17:00:03 Does anyone object to me locking & closing this issue? "The true target is consensus to change the PoW." https://github.com/monero-project/research-lab/issues/143 17:00:22 seems they have been able to win and orphan one monero block 17:01:12 Rucknium, no objection, this is reddit tier post 17:30:31 will be faced with reddit tier action 18:24:22 They orphaned a block. o well I guess 18:40:49 Well solutions like kayabanerve is to add a finality layer to stop big reorgs from occurring. https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604. Other solutions are to change the pow entirely like moving to a hybrid system to replace the current pow or others suggest moving to POS entirely. 18:54:39 The question on how to get more miners to mine monero. Is a tricky one, because the biggest reason why is simply because the price of monero has stayed stagnant for too long and due to rising electricity costs. There is simply a lot less incentive to mine it compared to like 2018 when random X was first introduced 18:55:07 The question on how to get more miners to mine monero. Is a tricky one, because the biggest reason why more miners don’t mine is simply because the price of monero has stayed stagnant for too long and due to rising electricity costs. There is simply a lot less incentive to mine it compared to like 2018 when random X was first introduced 18:56:03 they are further ahead now 18:59:20 looks like they got 9 18:59:24 https://irc.gammaspectra.live/4b289b6022729287/image.png 18:59:29 yeah they released it early 19:00:03 you can see they still were ahead a bit 19:02:13 Good lord our pools are performing terrible 19:10:21 They’ve mined the last 20 blocks (?)😬 19:10:44 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/lugwCthMqqrDmbQNjIYJgplL 19:13:20 they are ignoring new blocks 19:13:40 they are going backwards in heights to orphan all that exist above theirs 19:14:37 seems like their new orphan chain starts at 25 19:14:49 they are mining at height 30' now 19:15:04 they are +3 to known tip 19:15:12 hm 19:15:29 no change in hashrate on their pools 19:15:53 +4 19:16:54 either their hashrate is underreported or they are getting some extreme luck 19:17:15 or they have hashrate outside of pools that is not reported 19:17:45 ok i bought hash, prioritizing pools that aren't reporting any activity today 19:22:11 How does the activity look? 19:22:23 Are a lot of the big ones mining already? 19:22:28 no 19:22:42 Hm. I wonder why 19:25:20 what are they at now? 19:26:57 They got 47 out of 100 blocks 19:30:04 49 out of 100 19:30:35 I’m sure I’m going to be told it’s all fud 19:31:33 They must be massively underreporting their actual hashrate 19:31:50 They’re likely at 3gh/s instead of 1.8 or whatever they say it is 19:32:29 They’re at 51 19:34:22 how many blocks were orphaned 19:35:04 33 19:35:08 if 40 orphans, then they got 40/140 19:36:04 Gotcha, they’re doing massive disruption to the network 19:36:35 14 blocks reorg 19:37:41 Really? If so, i guess its time we fight dirty 19:38:16 Yeah they were able to get a massive reorg 19:39:04 Looks like 26-36 here 19:39:21 Ok nannoopool got 3 blocks, so at least that gives us some breathing room 19:39:58 Wen dns? 19:40:22 We should do it now. They’re likely underreporting their own hashrate anyways 19:41:05 We cant do it now 19:41:28 When is it going to be ready? 19:41:37 Current dns setup will reorg up to 1hour of blocks and cause more damage than qubic 19:42:14 Ok gotcha, but they were able to do a massive 14 block reorg in like 50 minutes 19:45:29 Nanopool got a 4th block, so our unlucky streak seems to be over at least for now 19:46:12 they are mining on top of it at least 19:47:32 At least it’s something I guess. We stopped their reorgs, but it’s still 33 blocks that were reorged 19:47:51 did we stop their reorgs? :D 19:47:55 Cum_from_behind said on their Discord that 9 block re-org is the max that they can do 19:48:04 Wonder why is that 19:48:14 The Monero Defense Fund saves the day ;) 19:48:16 that's cause they set a limit to not let anyone do double spends 19:48:23 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/RHXqPNrtqKVJOTrtzKTYZqxK 19:48:30 not technical limitation, just their decision to not allow it 19:48:48 they are mining 45' now 19:48:50 Datahoarder, but they reorged 10 or 11 :P 19:48:56 26-36 19:49:07 Idk if 26 is included 19:49:26 not included 19:49:31 It’s pretty bad either way you slice it. 19:49:41 OFRNXMR SHAME ON YOU FOR USING A REACTION. DATAHOARDER COULDN'T SEE IT FROM MATRIX 19:49:49 SORRY FOR CAPS 19:50:01 from irc* 19:50:10 well, I could see those caps from irc :) 19:50:28 always a pleasure to ruin someone else' screen 19:51:50 😁 20:06:06 they are mining 53 at the moment 20:06:32 from 45? 20:06:50 lost where they started from, but some long chain 20:15:41 they are at tip now 20:16:21 They orphaned 38 blocks 20:27:32 When does their marathon end? 20:28:26 24h from 12:00 UTC, so at 12 UTC 20:29:11 So in like 3 hours? 20:29:35 Oh I’m dumb 20:30:53 :P haha. Like 16hrs 20:31:23 So do orphan blocks count towards their blocks count? 20:32:03 which count? 20:32:03 they take numbers from 3 different places without regard, compare apple to oranges 20:33:14 Well are orphan blocks counted in the mining pool stats 20:34:29 They have 56 20:36:10 does it matter? 20:37:09 What do you mean? 20:42:39 hey monero orphaned one of their attempts! https://irc.gammaspectra.live/f708dcb190d5fb6a/image.png 20:53:06 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/xzRGbFquHNVYIOvOeucQvnlu 20:53:33 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/ONvaXrICMebtVTETTgkcbqgq 20:53:41 how did nanopool mine 3 consecutive blocks, selfish mining too? 20:54:10 they appeared in order fine 20:55:33 how do you see qubic on the blocks, I only see unknown on https://moneroconsensus.info/ 20:58:21 I made my own source 20:58:27 I run it myself :) 20:58:40 then feed custom source. I sent ruck info on how to add a custom source 20:58:57 I added this commit to monero-blocks https://git.gammaspectra.live/WeebDataHoarder/monero-blocks/commit/b6aec9dc4698e328250d9d47740569a068aa4779 20:59:08 you scoundrel :) 20:59:11 then you just need to tag qubic blocks yourself you find on the network 21:01:24 made a new package for every pool 21:01:43 using an interface wouldn't work? 21:02:15 there is an interface 21:02:26 for nodejs-pool and the cryptonote ones 21:02:36 the other packages are for custom reporting on each custom pool 21:02:52 see https://git.gammaspectra.live/WeebDataHoarder/monero-blocks/src/branch/master/main.go#L35-L89 21:02:59 curious why new packages for every pool, could have just been a new file 21:03:34 there's no new packages for every pool 21:03:41 these can also get reused elsewhere 21:04:11 each has their own paging tokens and other data 21:04:15 package xmr_nanopool_org 21:04:36 package xmr\_nanopool\_org, package monero_hashvault_pro 21:04:48 yes. they have a custom api and way of pagination, and otherwise it'd be NewNanoPool() 21:04:48 it's a package for every pool 21:04:54 must make sense, i just don't get it 21:04:59 irrelevant 21:05:13 yeah, why not NewNanoPool() 21:05:47 then not standardized, every package offers the same API and implements a common call / interface 21:05:53 pool.New... auto-completes which one I want 21:07:13 if you have more questions about the code syntax my personal choices of packages (with already given reason), you know #p2pool-observer or relevant can probably take those conversation better than lounge :) 21:07:20 it's not the first time! 21:07:28 sorry for being a hassle, couldn't wrap my head on the design 21:07:42 cheers 21:16:51 more orphans (it's theirs now) https://irc.gammaspectra.live/29b63483d0d708cc/image.png 21:38:28 Rucknium can you turn your checkpoint script back on 21:39:06 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/MMISciWAFNTOwtBVoHQvtQqH 21:39:46 Thsts 9 blocks 21:39:51 DataHoarder: something strange happened with xmrconsensus. Your image shows an orphaned Qubic block with hash 4fd... at height ...799 , but moneroconensus.info shows orphaned unknown block with hash 055... at height ...799. The rest of the alt chain have the same block hashes. 21:41:26 779 on DH's image 21:42:00 which full height? 21:42:02 Good. I mixed them up. Still though. How did they pull that off with only 33%? 21:42:20 data points they had more, for a short burst 21:42:26 not via pools 21:43:34 4fd is 3485781 21:43:52 so indeed, why is that on mine 21:43:56 Oops, I meant 779. Yes, 3,485,779 21:44:54 I refreshed, now it's gone 21:45:06 seems it's good on tree view 21:45:29 They could be renting hashrate in bursts? Make the reorgs as deep as possible when they get ahead 21:45:47 full tree image https://irc.gammaspectra.live/c24ebeb5950f67d2/image.png 21:45:49 Kasmaristo: https://github.com/monero-project/research-lab/issues/102#issuecomment-2402750881 21:46:08 See "Table: Duration of meta attack to achieve attack success probability of 50 percent" 21:46:10 they did say that'd it is something they do 21:46:37 Thank you 21:46:57 Yeah, it makes sense when you take human psychology into the mix 21:47:24 Kasmaristo: If you have 30% hashpower and try peristently to always re-org 7 blocks, they you have a 50% probability of re-orging 7 blocks after 3.4 hours of trying. 21:48:13 And the probability of 10? 21:48:26 According to my analysis, based on theorems by others. 21:49:04 8.6 hours. The table is in units of days. 21:50:31 I wrote that analysis when MRL was discussing changing the 10- block lock. It's useful now! 21:50:54 Yes! Thanks for the write up 21:52:09 The classic Nakamoto attack is well-known, but in MRL we were discussing what happens when an attacker stops and re-starts the attack, which is not what Nakamoto originally analyzed. 21:52:43 The Nakamoto attack assume that the attacker starts the attack and continues the attack for an infinite length of time. 21:53:31 So I analyze a "`z` stopping rule" attack. 21:54:05 The results cooled enthusiasm for reducing the 10 block lock. 21:56:08 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/seZPEYgaEeEJHyCAXVzhWjLg 21:56:36 So if I'm reading this right it would take roughly one day for 5% of the hash power to perform a 1 block reorg? 21:57:07 Or to have a 38% chance 21:58:07 Or .38 days? 21:58:17 Less than one day. Remember, that's the attacker's only goal. If they have a different strategy, then the numbers would be different. For example, a true profit-driven selfish miner would cause a re-org if it were profitable, not necessarily at a specific `z` re-org depth. 21:58:56 Right. 0.38 days. Not guaranteed. You reach 50% probability of doing that. 21:59:23 That's...concerning. So why not INCREASE the lock instead? 22:00:38 48 days for a 30 block reorg is much better than .36 days at 30% hash rate percent 22:01:09 48 days for a 30 block reorg is much safer than .36 days at 30% hash rate percent. Of course an hour for funds to unlock would be inconvenient. 22:04:27 But is there a way the network could dynamically adjust the block lock amount based on the % of any given pool? Say 30 blocks if any pool has >30%, 20 for 20%, and 10 blocks for 10%? 22:05:23 We dynamically adjust our block size. Why not the block confirmations? 22:05:36 that can be abused :) 22:07:06 Elaborate for me 22:07:38 The blockchain doesn't know which pool mined each block. 22:07:42 there is no reliable way to detect ^ 22:07:55 they could specifically appear as 1% 80 pools 22:08:20 Ah. I see 22:08:33 when they want to make noise, they all appear as one, then suddenly confirmations go up. it also doesn't work against collusion between pools, even if you had a way to identify them 22:09:30 Can it detect orphaned block % somehow? 22:09:51 I guess it wouldn't matter anyway. The selfish mining wouldn't appear until they broadcasted it. Too late at that point 22:10:11 to detect orphaned blocks they'd need to be added to blocks so it can be verified later 22:10:25 if there is no incentive to include them, these won't get added 22:10:36 that effectively gives you an extra prize for doing selfish mining 22:10:47 so it promotes selfish mining. 22:11:00 an attacker could also stay hidden UNTIL they publish the chain that double spends 22:11:07 you would know nothing until it is too late 22:11:24 not even posting normal blocks to chain, but mining in silence, trying again 22:11:39 you would never know they existed, until, they do, and it's done 22:12:39 What's the best solution/s to our current problem? More hash rate (obviously), but a 9 block reorg at 30% is too much 22:13:04 there's bandaids incoming at some point 22:13:22 probably DNS checkpoints, sort of less decentralized as desired 22:13:52 there's suggestions about how to prevent overt selfish mining. but otherwise, most long term changes are still being discussed 22:15:42 In the meantime I sure hope pubic doesn't get lucky enough to pull off a 10 with 30%. That would be awful for pr. The media would have a hayday 22:16:09 they no longer have the hashrate burst of before 22:16:14 I was thinking abt the detective mining. I don't think that works if i am mining in secret? 22:16:21 they had ~4GH/s before from estimates 22:16:28 not reported on pool hashrates 22:16:44 no, detective mining doesn't work if detective doesn't know about the mining 22:17:33 do they mine in secret or do they actually have a pool open to anyone ? 22:18:39 qubic is in the open. it'd work for current situation, but they can also pull different tricks 22:18:53 ofrnxmr: I think there was a re-org 1.8 days ago on testnet and my checkpointing node was on the wrong side of it. 22:19:42 I restarted without enforcing DNS checkpoints and got several messages like this: 22:19:43 ``` 22:19:45 2025-08-25 22:18:53.463 W CHECKPOINT FAILED FOR HEIGHT 2818109. EXPECTED HASH: , FETCHED HASH: 22:19:47 2025-08-25 22:18:53.463 E WARNING: local blockchain failed to pass a MoneroPulse checkpoint, and you could be on a fork. You should either sync up from scratch, OR download a fresh blockchain bootstrap, OR enable checkpoint enforcing with the --enforce-dns-checkpointing command-line option 22:19:49 ``` 22:19:54 they have a larger reorg in the work, unless they lose it 22:21:47 I think the non-checkpointed chain just overtook 22:22:10 ofrnxmr: After testnet advances 10 blocks, the DNS checkpoints should be up to date. I will turn on DNS checkpoint enforcing on the _checkpointing_ node at that time. 22:22:38 I'll make sure to put some hashrate towards the checkpointed chain this time :P. Sorry 22:22:50 are altchains broadcasted widely across the network now? 22:23:36 You can see the re-orged alt chain at https://testnetnode4.moneroconsensus.info/ , etc. 22:46:24 DataHoarder: Any idea of what's causing it or a fix? I don't completely understand. 22:46:35 it's reverse order 22:46:54 https://irc.gammaspectra.live/7304f787b9ea53af/image.png 22:47:13 this should be (top to bottom hashes) 05, 4f, ea, 98 22:47:22 the order is instead 98, ea, 4f, 05 22:47:44 is it maybe fct_alt_chains.R line 48/49? 22:47:52 I'm so unfamiliar with R :) 22:47:58 Thanks. I will look at it. 22:48:27 here's a recently generated csv https://privatebin.net/?0633283d458731b9#3czPpxeRYXxSr871Lp9Zz9hD7yiUQcs5tHk8bE4S3CuU 22:48:30 I had to do some untidy things to get certain display characteristics. Maybe that is causing it. 22:49:04 your live version also seems to be affected 22:51:10 they are trying to attempt longer reorgs according to discord 22:52:28 they are mining at 21 already 22:52:32 +6 over tip 22:52:57 but the chain is way longer 22:53:43 seems like a 15 reorg so far? 23:00:14 ourch 23:00:15 ouch 23:00:17 they are at 24 23:00:40 +10 over monero tip plus everything else before that they have before 23:01:15 or well, +9, plus everything before (-1 as what I see is their "next" height) 23:04:58 We’re pretty much helpless against them it seems. Anybody who downplayed qubic is looking pretty stupid 23:05:44 it's here 23:05:51 08 until 23 23:06:03 16 reorg 23:06:12