03:46:21 https://arxiv.org/pdf/2512.01437 03:46:34 Inside Qubic’s Selfish Mining Campaign on 03:46:34 Monero: Evidence, Tactics, and Limits 03:47:21 “In these intervals, 03:47:21 Qubic’s average hashrate share rises to the 23-34% range, 03:47:21 yet sustained 51% control is never observed.“ 03:50:41 This is a very thorough analysis 03:54:40 > 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. 03:54:40 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 03:54:40 Example: https://blocks.p2pool.observer/block/b7899ad5f54b8f4ebfdbe44f64d36517b9b1f7994eaaede1aa40b41b6ef2f143[... more lines follow, see https://mrelay.p2pool.observer/e/y7OUsc8KeE1fWWdZ ] 03:55:39 The adaptation involves feeding the miner tx directly, not grabbing it from blockchain data (as it is orphaned) 03:56:43 For example, orphan blocks listed here https://irc.gammaspectra.live/419c0c2b6e8bac8c/qubic-blocks-epoch178.csv include additionally the full block for any verifier to confirm this. 03:59:40 > Empirical refutation of strategic utility: We demonstrate that the deployed strategy was economically ineffective, contrary to the context promoted by the pool. 04:01:12 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) 04:13:07 > 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. 04:13:31 oh! similar results for them using only main block data and task 04:15:37 (they later estimate 12% from empirical data and not simulations) 04:19:08 They really had a lack of granular data, which we gathered with more granularity (example, the "timeline logs" on https://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) 04:21:45 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) 04:23:15 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) 04:35:38 Here's some of the granular measured hashrate they had, from Aug 11th to Oct 16th. 04:35:40 https://mrelay.p2pool.observer/m/monero.social/KDbxiJDXvoTwqNBcfwbBrdqP.png (image.png) 04:35:43 ^ 6h buckets 04:37:46 https://mrelay.p2pool.observer/m/monero.social/slHbhaUVYRdamtaaylUMPEUw.png (image.png) 04:37:49 ^ 24h buckets 04:39:05 These are measured in absolute H/s, not network share. 15:48:47 Magic Monero Fund is now taking donations to fund increasing monerod fuzzing code coverage. Specifically in src/p2p src/fcmp_po and src/wallet 15:48:47 Please consider donating 🙏🏽 15:48:47 https://donate.magicgrants.org/monero/projects/fuzzing-monero-2 15:49:10 *src/fcmp_pp 19:44:55 <321bob321> Maybe post in community 19:45:24 <321bob321> And promote on monerotalk 21:00:31 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?