00:50:31 https://xcancel.com/c___f___b/status/1952855407237480797 00:53:49 that is what made me look at my logs: https://matrix.to/#/!toFcRZtpaiwiyapgVO:matrix.org/$rxrmvqLxafLD_8d5amgGCVsUETqJu6jN-7D_xhJYhlM?via=matrix.org&via=monero.social&via=cypherstack.com 00:54:45 I do wonder if they have just modified their node to just not send new blocks to peers 🤷 01:40:11 You dont really need to modify the node for that 01:44:00 hmm. Are blocks broadcasted to incoming _and_ outgoing connections? Or only outgoing, like dandelion? 01:45:01 They are broadcasted to all 01:50:15 Why not? 01:50:41 When monerod gets a block it immediately sends it over the network right? 01:52:42 I didnt read the lab link before sending. 01:52:43 you can disconnect your node while you mine, but its not that they are mining offline, but that they arent broadcasting 01:53:45 If they reconnected, it would broadcast the blocks. But that isnt what theyre doing, theyre not broadcasting iiuc 01:55:33 It wouldn't broadcast the blocks fwiw, other nodes would sync from it 01:56:07 So yeah they could be doing that 02:03:52 The easiest way ive done this, is to use a slave node and set in_peers and out_peers to 0. slave node has --add-exclusive-node set to the master. Master has add-exclusive set to slave. Master still receives inc (connections) 02:03:53 Use block-notify on master node to run a script to set out_peers to 1 momentarily on slave, then set back to 0. 02:03:55 if slave height > master height, in_peers to 1 on slave. 02:03:57 Smthn like that 19:51:22 Alt chain longer than one block crashed moneroconsensus.info 19:51:23 Fixing now. Should be interesting to see the results. 20:17:05 It's fixed. It looks like an unknown miner orphaned a two-block chain mined by supportxmr and c3pool at height 3,472,097 20:27:05 Wait, uh, something isn't counting the height right 😅. I'll go check. 20:37:05 Fixed, I think. The docs seem wrong https://docs.getmonero.org/rpc-library/monerod-rpc/#get_alternate_chains 20:37:07 > height - unsigned int; the block height of the first diverging block of this alternative chain. 20:37:44 I think `height` here is the block height of the _last_ diverging block of the alternative chain. 20:55:39 chain reorg from orphan blocks occurring? 20:57:37 Looks like it 20:57:53 unknown blocks going brr 20:59:44 Nvm. A couple unknowns changed to be known pools nkw 21:00:47 Pools reporting their blocks can take a while (plus delay from running the code) 21:01:28 they had one at 3,472,098 right? 21:01:30 The code reports unconfirmed blocks by the pool apis but they still can take some time to show fresh data 21:01:34 Yep 21:02:35 I think Qubic may be withholding blocks, even if it's not a profitable strategy with their hashpower share. They produced about 16 of the last 100 blocks, but they are still trying to orphan the main chain. 21:03:32 Ruck, probably doing this 21:04:07 they announced they will do selfish mining if their pool is above 2 gh/s 21:05:08 they only mine xmr for typically 30 mins so what is that like 15 blocks at a time? 21:05:10 According to my "Table: Duration of meta attack to achieve attack success probability of 50 percent", if you are constantly trying to achieve a re-org of just two blocks with 20% of hashpower, you should have a 50% probability of achieving that re-org if you run the strategy for about three hours: https://github.com/monero-project/research-lab/issues/102#issuecomment-2402750881 21:05:43 Given assumptions, the re-org rate is not surprising. 21:06:33 In the table, you would look at the cell at the intersection of the row with `3` and the column with `0.2`. At least I think that's the correct interpretation of their strategy. 21:08:16 they've been doing this strategy since yesterday and that was the first successful chain reorg for them 21:08:20 that ive seen 21:15:04 It doesn't matter, they're losing revenue to their own lost blocks (they do get orphans too) 21:15:13 They don't have enough hashrate for it to be profitable 21:20:20 do you know if their own hashrate data is accurate? they claim around 2-2.5 gh/s when they are mining 21:21:07 I have no way of verifying it 21:21:32 It matches the number of block they mine, +- luck variations 21:21:44 13% out of last 100 blocks on miningpoolstats, i suppose if you x2 its 26% which is within 2-2.5 gh/s but unsure if its correct to actually assume that 21:21:59 They don't mine ALL unknown blocks 21:21:59 since they really only mine for 30 mins or about 50 blocks each time 21:22:18 wait sorry 30 mins is 15 blocks 21:22:29 yeah idk i think they might be reporting inaccurate hash rate 21:26:54 nvm i take it back you are correct, it does match the number of blocks they mine 21:57:48 Is there any research on the effects on the network that would occur if multiple mining pools did selfish mining? 21:58:07 Independently, competing with each other? 21:58:50 that would be a mess 21:58:52 many reorgs 22:01:37 Torir: You can have at most two mining pools doing that if they are trying to maximize revenue since you need 33% or more of total network hashpower for selfish mining to be profitable. 22:02:09 Profitable compared to honest mining, I mean. 22:04:41 Qubic lost 1ed592a855c200b5b3d97cfaf53309767f8bdd43095b51447d5c12403b863027 at height 3472181 :D 22:04:45 They keep losing blocks 22:04:53 That's the cost of trying to do reorgs 22:05:07 how are you seeing these blocks 22:05:25 I won't tell 22:06:01 Let's just say, I know more than they think :) 22:06:33 That sounds fun 22:07:09 They lost f0b0fc9856c3e7c4ddec82353be503b292f9be9923045445a2bb22dd43d21f03 at height 3472183 22:07:14 So unlucky this round, hehe 22:07:49 They even lose it not to a pool, but to some solo miner 22:08:02 I told you, not all unknown blocks come from Qubic 22:09:43 hehe 22:18:00 They lost 169c6b669bba53b1697a7cad445d80622a0c3638444fa169e9ff4564dd68214a at height 3472188 22:18:08 It's fun to watch 22:23:33 we should see it start to reflect in their blocks mined per 100 depending on how unprofitable it is for them now 22:23:44 should drop from 12-16% EV to even less 22:24:39 oh yea theyre at 10% now, which is below EV 22:39:07 Added all-important dark mode option to https://moneroconsensus.info/ 😎 22:39:41 ah yeahhhh 22:48:14 btw > 2025-08-02: Known bug that fails to assign some blocks to mining pools is being investigated. 22:48:30 wasn't that addressed with pulling "invalid/orphaned" blocks from pool's APIs? 22:49:20 also feedback on dark mode, try to get bg to the same color as the page (or something other than pure dark) 22:49:25 text is ... harder to read 22:49:52 Can we get a net tally of failed presumed selfish mining blocks to successful Rucknium: ? 22:51:35 ... a net tally of orphaned unknown blocks vs orphaning unknown blocks? 22:54:15 Or would that be improper now since sech1 is observing orphaned unknown-origin blocks your experiment isn't reflecting? 22:54:58 (We don't want to imply a conclusion if we know the data isn't sufficiently accurate) 22:59:33 DataHoarder: I think the bug has probably been fixed. If you think it's fixed, too, and no one else notices an obvious problem, I will remove the notice. 22:59:57 I see no other data to pull from the pools - so yeah 23:00:37 There is still a delay but that's 100% pool API not reporting data until half a minute after they find it 23:01:01 but no longer like 20m or so, my tool maps out exactly what the pools API report as found blocks 23:09:25 DataHoarder: fixed both issues 23:09:47 image bg switches proper, very nice 23:11:51 kayabanerve: Without sech1's data, which is not easily verified, one could work hard to figure out what probabilities you would get, given a specific selfish mining strategy and assumptions about constant or non-constant hash rate over time. Then, you could write a statistical estimator for that, which would probably have wide confidence intervals. 23:12:17 Short answer: No 23:14:19 Rucknium you can DM me on IRC to get access to data 23:15:07 But an easy thing to do would be to check if unknown miners are getting over 33% of recent blocks, which is the threshold for when selfish mining is profitable. Source: Negy, Rizun, & Sirer (2020) "Selfish Mining Re-Examined" https://kevinnegy.github.io/Selfish%20Mining%20Re-Examined.pdf 23:16:03 sech1: Can the information be verified by an observer? Do you have the whole block data or just the block's hash? If you have the whole block, the information could be verified, AFAIK. 23:16:38 Thank you. Yes, I was interested in seeing if selfish mining was profitably occurring, but I hear that's infeasible to detect. I'll accept if it's theoretically profitable instead. 23:16:49 Yes, I can get the whole block data 23:17:03 Rucknium: Caveat, as sech1 could have personally mined those blocks hours after the fact with a spoofed timestamp. 23:17:07 I would guess that Qubic's selfish mining is a publicity stunt since they seem to be losing money, compared to just mining honestly without withholding blocks. 23:17:14 Just DM me, and I can share some juicy data 23:17:34 Rucknium, D​ataHoarder: 23:17:35 for bg, #181818 and text #E0E0E0 is good? 23:17:37 Alt-chains are only reliable when you personally observe their timestamp of existence and are trivial to retroactively forge. 23:17:52 (I trust sech1 here, just noting the theory) 23:17:53 https://webaim.org/resources/contrastchecker/ 23:18:28 It can only be 'verified' to the degree we trust sech1 to have not retroactively mined those blocks (which is reasonable) 23:18:58 foreground in the linked website is font color btw 23:19:18 I keep my source of information private, for now, but I can share with Rucknium or DataHoarder 23:19:34 the contrast is better, maybe not "good" but better than pure black 23:27:01 I don't need to know the source of the data if it's verifiable with the whole block data. I will DM. 23:27:12 D​ataHoarder: I think Ruck already changed it. 23:27:18 looks good 23:33:23 https://github.com/monero-project/monero-docs/pull/201 [@basses:matrix.org](https://matrix.to/#/@basses:matrix.org) [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) 23:46:58 I think it will be easier to determine if it is profitability occurring after they do another "marathon" and mine xmr for 24 hours 23:47:29 Although from the sounds of what seth has said already it seems they are losing out on more blocks than gaining, if that trend continues its definitely not profitable for them currently 23:48:04 talking profitable or not they are already paying what was it, 2x or 4x for people mining on their side 23:49:31 they claim 3x more mining rewards than mining xmr alone 23:49:38 I think losing an edge there is irrelevant. this is not a rational/profit seeking attacker (monero wise) 23:50:04 ofc it's paid on their token coupons 23:50:38 it's costing them just a bit more to do more "apparent" harm or be noticeable 23:51:07 they could be earning XMR and for now it doesn't seem to be their plan to grow that, but make noise for notoriety 23:51:16 yeah, part of the "marketing budget" 23:51:56 I also don't know how accurate the claim of 3x more mining rewards is. I'm pretty sure from what I've gleaned off their discord that figure was made by a qubic miner and they just ran with it 23:52:27 like not part of the core team just some random miner who wanted to make a positive statement about qubic mining 23:52:29 it's less of "they are losing this much" vs "it's only costing them this little" to do the attacks described 23:53:07 afaik it has been confirmed there's higher margin due to manually propping rewards up 23:54:14 yeah I don't doubt its more profitable right now but I just don't know if the figure of being 3x more is accurate or not 23:55:04 they aren't doing 10x or 100x so it's around similar "levels" :) 23:55:07 their entire price basically relies on xmr price though right? they mine xmr, sell it, then use funds to buyback qubic 23:56:02 there's not enough for that. can't remember what they promise, but either depends on people not swapping out or liquidity manually added to keep its price above 23:56:29 it's quite centralized so it's all promises anyhow 23:57:39 yes, lots of promises 23:57:54 and misinterpretations 23:58:01 from an uninformed userbase