<ack-j:matrix.org> arxiv.org/pdf/2512.01437

<ack-j:matrix.org> Inside Qubic’s Selfish Mining Campaign on

<ack-j:matrix.org> Monero: Evidence, Tactics, and Limits

<ack-j:matrix.org> “In these intervals,

<ack-j:matrix.org> Qubic’s average hashrate share rises to the 23-34% range,

<ack-j:matrix.org> yet sustained 51% control is never observed.“

<ack-j:matrix.org> This is a very thorough analysis

<datahoarder> > view–key–based verification can be applied only to blocks that are already definitively included in the main chain; it cannot be used for blocks that are still within an ongoing epoch or for blocks that have already become orphaned.

<datahoarder> It can. That's how I released my orphan blocks with proofs, they were done using viewkeys. Monero GUI/CLI indeed does not let you verify them, but a custom verifier is able to check all orphan blocks later on

<datahoarder> Example: blocks.p2pool.observer/block/b7899a…17b9b1f7994eaaede1aa40b41b6ef2f143[... more lines follow, see mrelay.p2pool.observer/e/y7OUsc8KeE1fWWdZ ]

<datahoarder> The adaptation involves feeding the miner tx directly, not grabbing it from blockchain data (as it is orphaned)

<datahoarder> For example, orphan blocks listed here irc.gammaspectra.live/419c0c2b6e8bac8c/qubic-blocks-epoch178.csv include additionally the full block for any verifier to confirm this.

<datahoarder> > Empirical refutation of strategic utility: We demonstrate that the deployed strategy was economically ineffective, contrary to the context promoted by the pool.

<datahoarder> this was also seen empirically ^ though they improved towards the later days, it still was subpar (from empirical estimates myself they were running ~18% loss compared to pure mining, later on ~10% loss)

<datahoarder> > its expected revenue ratio should also fall within this interval, implying a relative loss of roughly 9% − 36% compared to honest mining at the same hashrate.

<datahoarder> oh! similar results for them using only main block data and task

<datahoarder> (they later estimate 12% from empirical data and not simulations)

<datahoarder> They really had a lack of granular data, which we gathered with more granularity (example, the "timeline logs" on github.com/WeebDataHoarder/Monero-Timeline-Sep14 which aren't even as verbose as they are in real life, we have 800 GiB of dumps and ~100 GiB of microsecond accurate hashrate submissions and task logs)

<datahoarder> The way they processed the data is consistent with internal methods, and they verified the same assumptions (timestamp delay they measured was around 5s, but we had these within 20-80ms of the tasks being created)

<datahoarder> Good report, it does not include times during August sadly and they might have missed orphan blocks that didn't end up on the network (but templates for them exist)

<datahoarder> Here's some of the granular measured hashrate they had, from Aug 11th to Oct 16th.

<datahoarder> mrelay.p2pool.observer/m/monero.social/KDbxiJDXvoTwqNBcfwbBrdqP.png (image.png)

<datahoarder> ^ 6h buckets

<datahoarder> mrelay.p2pool.observer/m/monero.social/slHbhaUVYRdamtaaylUMPEUw.png (image.png)

<datahoarder> ^ 24h buckets

<datahoarder> These are measured in absolute H/s, not network share.

<ack-j:matrix.org> Magic Monero Fund is now taking donations to fund increasing monerod fuzzing code coverage. Specifically in src/p2p src/fcmp_po and src/wallet

<ack-j:matrix.org> Please consider donating 🙏🏽

<ack-j:matrix.org> donate.magicgrants.org/monero/projects/fuzzing-monero-2

<ack-j:matrix.org> *src/fcmp_pp

<321bob321> Maybe post in community

<321bob321> And promote on monerotalk

<diego:cypherstack.com> Hi. FOSDEM. Anyone want to go? And if so, any people specializing in the p2p networking of Monero want to do a talk or workshop?