<o​frnxmr:monero.social> xcancel.com/c___f___b/status/1952855407237480797

<b​oog900:monero.social> that is what made me look at my logs: matrix.to/#/!toFcRZtpaiwiyapgVO:mat…a=monero.social&via=cypherstack.com

<b​oog900:monero.social> I do wonder if they have just modified their node to just not send new blocks to peers 🤷

<o​frnxmr:xmr.mx> You dont really need to modify the node for that

<o​frnxmr:xmr.mx> hmm. Are blocks broadcasted to incoming _and_ outgoing connections? Or only outgoing, like dandelion?

<v​tnerd:monero.social> They are broadcasted to all

<b​oog900:monero.social> Why not?

<b​oog900:monero.social> When monerod gets a block it immediately sends it over the network right?

<o​frnxmr:xmr.mx> I didnt read the lab link before sending.

<o​frnxmr:xmr.mx> you can disconnect your node while you mine, but its not that they are mining offline, but that they arent broadcasting

<o​frnxmr:xmr.mx> If they reconnected, it would broadcast the blocks. But that isnt what theyre doing, theyre not broadcasting iiuc

<b​oog900:monero.social> It wouldn't broadcast the blocks fwiw, other nodes would sync from it

<b​oog900:monero.social> So yeah they could be doing that

<o​frnxmr:xmr.mx> 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)

<o​frnxmr:xmr.mx> Use block-notify on master node to run a script to set out_peers to 1 momentarily on slave, then set back to 0.

<o​frnxmr:xmr.mx> if slave height > master height, in_peers to 1 on slave.

<o​frnxmr:xmr.mx> Smthn like that

<r​ucknium:monero.social> Alt chain longer than one block crashed moneroconsensus.info

<r​ucknium:monero.social> Fixing now. Should be interesting to see the results.

<r​ucknium:monero.social> It's fixed. It looks like an unknown miner orphaned a two-block chain mined by supportxmr and c3pool at height 3,472,097

<r​ucknium:monero.social> Wait, uh, something isn't counting the height right 😅. I'll go check.

<r​ucknium:monero.social> Fixed, I think. The docs seem wrong docs.getmonero.org/rpc-library/monerod-rpc/#get_alternate_chains

<r​ucknium:monero.social> > height - unsigned int; the block height of the first diverging block of this alternative chain.

<r​ucknium:monero.social> I think `height` here is the block height of the _last_ diverging block of the alternative chain.

chain reorg from orphan blocks occurring?

<o​frnxmr:xmr.mx> Looks like it

<o​frnxmr:xmr.mx> unknown blocks going brr

<o​frnxmr:xmr.mx> Nvm. A couple unknowns changed to be known pools nkw

Pools reporting their blocks can take a while (plus delay from running the code)

they had one at 3,472,098 right?

The code reports unconfirmed blocks by the pool apis but they still can take some time to show fresh data

Yep

<r​ucknium:monero.social> 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.

<o​frnxmr:xmr.mx> Ruck, probably doing this

they announced they will do selfish mining if their pool is above 2 gh/s

they only mine xmr for typically 30 mins so what is that like 15 blocks at a time?

<r​ucknium:monero.social> 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: monero-project/research-lab #102#issuecomment-2402750881

<r​ucknium:monero.social> Given assumptions, the re-org rate is not surprising.

<r​ucknium:monero.social> 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.

they've been doing this strategy since yesterday and that was the first successful chain reorg for them

that ive seen

It doesn't matter, they're losing revenue to their own lost blocks (they do get orphans too)

They don't have enough hashrate for it to be profitable

do you know if their own hashrate data is accurate? they claim around 2-2.5 gh/s when they are mining

I have no way of verifying it

It matches the number of block they mine, +- luck variations

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

They don't mine ALL unknown blocks

since they really only mine for 30 mins or about 50 blocks each time

wait sorry 30 mins is 15 blocks

yeah idk i think they might be reporting inaccurate hash rate

nvm i take it back you are correct, it does match the number of blocks they mine

<t​orir:matrix.org> Is there any research on the effects on the network that would occur if multiple mining pools did selfish mining?

<t​orir:matrix.org> Independently, competing with each other?

that would be a mess

many reorgs

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> Profitable compared to honest mining, I mean.

Qubic lost 1ed592a855c200b5b3d97cfaf53309767f8bdd43095b51447d5c12403b863027 at height 3472181 :D

They keep losing blocks

That's the cost of trying to do reorgs

<c​ountbleck:matrix.org> how are you seeing these blocks

I won't tell

Let's just say, I know more than they think :)

<c​ountbleck:matrix.org> That sounds fun

They lost f0b0fc9856c3e7c4ddec82353be503b292f9be9923045445a2bb22dd43d21f03 at height 3472183

So unlucky this round, hehe

They even lose it not to a pool, but to some solo miner

I told you, not all unknown blocks come from Qubic

<c​ountbleck:matrix.org> hehe

They lost 169c6b669bba53b1697a7cad445d80622a0c3638444fa169e9ff4564dd68214a at height 3472188

It's fun to watch

we should see it start to reflect in their blocks mined per 100 depending on how unprofitable it is for them now

should drop from 12-16% EV to even less

oh yea theyre at 10% now, which is below EV

<r​ucknium:monero.social> Added all-important dark mode option to moneroconsensus.info 😎

<c​ountbleck:matrix.org> ah yeahhhh

btw > 2025-08-02: Known bug that fails to assign some blocks to mining pools is being investigated.

wasn't that addressed with pulling "invalid/orphaned" blocks from pool's APIs?

also feedback on dark mode, try to get bg to the same color as the page (or something other than pure dark)

text is ... harder to read

<k​ayabanerve:matrix.org> Can we get a net tally of failed presumed selfish mining blocks to successful Rucknium: ?

<k​ayabanerve:matrix.org> ... a net tally of orphaned unknown blocks vs orphaning unknown blocks?

<k​ayabanerve:matrix.org> Or would that be improper now since sech1 is observing orphaned unknown-origin blocks your experiment isn't reflecting?

<k​ayabanerve:matrix.org> (We don't want to imply a conclusion if we know the data isn't sufficiently accurate)

<r​ucknium:monero.social> 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.

I see no other data to pull from the pools - so yeah

There is still a delay but that's 100% pool API not reporting data until half a minute after they find it

but no longer like 20m or so, my tool maps out exactly what the pools API report as found blocks

<r​ucknium:monero.social> DataHoarder: fixed both issues

image bg switches proper, very nice

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> Short answer: No

Rucknium you can DM me on IRC to get access to data

<r​ucknium:monero.social> 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" kevinnegy.github.io/Selfish%20Mining%20Re-Examined.pdf

<r​ucknium:monero.social> 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.

<k​ayabanerve:matrix.org> 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.

Yes, I can get the whole block data

<k​ayabanerve:matrix.org> Rucknium: Caveat, as sech1 could have personally mined those blocks hours after the fact with a spoofed timestamp.

<r​ucknium:monero.social> 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.

Just DM me, and I can share some juicy data

<b​asses:matrix.org> Rucknium, D​ataHoarder:

<b​asses:matrix.org> for bg, #181818 and text #E0E0E0 is good?

<k​ayabanerve:matrix.org> Alt-chains are only reliable when you personally observe their timestamp of existence and are trivial to retroactively forge.

<k​ayabanerve:matrix.org> (I trust sech1 here, just noting the theory)

<b​asses:matrix.org> webaim.org/resources/contrastchecker

<k​ayabanerve:matrix.org> It can only be 'verified' to the degree we trust sech1 to have not retroactively mined those blocks (which is reasonable)

<b​asses:matrix.org> foreground in the linked website is font color btw

I keep my source of information private, for now, but I can share with Rucknium or DataHoarder

the contrast is better, maybe not "good" but better than pure black

<r​ucknium:monero.social> I don't need to know the source of the data if it's verifiable with the whole block data. I will DM.

<b​asses:matrix.org> D​ataHoarder: I think Ruck already changed it.

<b​asses:matrix.org> looks good

<o​frnxmr:xmr.mx> monero-project/monero-docs #201 [@basses:matrix.org](https://matrix.to/#/@basses:matrix.org) [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social)

I think it will be easier to determine if it is profitability occurring after they do another "marathon" and mine xmr for 24 hours

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

talking profitable or not they are already paying what was it, 2x or 4x for people mining on their side

they claim 3x more mining rewards than mining xmr alone

I think losing an edge there is irrelevant. this is not a rational/profit seeking attacker (monero wise)

ofc it's paid on their token coupons

it's costing them just a bit more to do more "apparent" harm or be noticeable

they could be earning XMR and for now it doesn't seem to be their plan to grow that, but make noise for notoriety

yeah, part of the "marketing budget"

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

like not part of the core team just some random miner who wanted to make a positive statement about qubic mining

it's less of "they are losing this much" vs "it's only costing them this little" to do the attacks described

afaik it has been confirmed there's higher margin due to manually propping rewards up

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

they aren't doing 10x or 100x so it's around similar "levels" :)

their entire price basically relies on xmr price though right? they mine xmr, sell it, then use funds to buyback qubic

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

it's quite centralized so it's all promises anyhow

yes, lots of promises

and misinterpretations

from an uninformed userbase