00:00:08 These are not included in that dataset. 00:03:54 2. 00:03:54 Blocks were disseminated via above mentioned monero RPC, which we then pushed to several mining nodes RPC, and we ran specialized nodes that took any blocks via RPC, and pushed them via P2P (to be able to push alternate blocks behind current public known tip). 00:03:54 Usually these were propagated quick and accepted, so the network started mining on Qubic's block (which is now public).[... more lines follow, see https://mrelay.p2pool.observer/e/vqaQkNUKdVFMakZv ] 00:04:51 As for reactions, if Qubic block would be higher height than tip, Monero nodes would just accept that as the tip. 00:04:51 Something interesting we saw from Qubic is if any of the blocks from its selfish chain, no matter how long, was published out properly and they noticed this, they automatically pushed their whole chain(!) early. 00:05:41 For example, monero is at 102, they are mining alternate 100, 101, 102, 103, 104. We publish 100, yet they then post all blocks up to 104. 00:05:52 This was later patched by them. 00:06:39 > My current understanding is: if the reconstructed block wasn’t propagated/accepted quickly enough by the Monero network, Qubic could ignore it and continue building privately. If that’s incorrect, I’d appreciate a correction. 00:06:39 ^ it didn't matter how quick it distributed if it was before the rest of the network found one. basically we kept resetting Qubic's progress. 00:15:44 3. 00:15:44 Initially they used some constant XOR encryption, which we found hours later when we checked logs (they claimed to have found the final solution here). Was patched, and solutions were decrypted fine. But given they may change this again, we found a way to obtain specific nonce/extraNonce values from encrypted solutions of inte [... too long, see https://mrelay.p2pool.observer/e/ksS8kNUKWTVUcGhI ] 00:15:44 We usually waited between encryption changes before activating the lookups again to ensure they had not enabled any trap to leak source in the patches, which gave them some hope, but we triggered it again during important marathons when they ran their marketing machine (doing maximum damage to their marketing efforts, t[... more lines follow, see https://mrelay.p2pool.observer/e/ksS8kNUKWTVUcGhI ] 00:16:30 At some point we were connected to roughly 2.5k monero nodes via P2P to push blocks, and ~20 big nodes via RPC (which re-broadcasted via P2P as well) 00:18:35 For 1, we also have a wider set of tasks and solutions for specific periods of times. These do not include packet signatures so they can't be verified that way as coming from the dispatcher or computor, however, will be included in future logs. 00:19:44 We also gathered packet dumps of every passing packet in the network for core periods for future analysis. These span ~900 GiB after being highly compressed, for a couple of weeks data. 00:22:43 all currently processed tasks and solutions (without including extra ones) ended up as ~2 GiB dataset. Not all solutions are decrypted, but all include a PoW hash. 00:24:42 hopefully the above helps @suhyeon:matrix.org. The data is still being gathered live (although without packet dumps now) and try to keep up with any of their protocol changes to keep all the monitoring parts working. 00:30:45 As for citation, it's not just me, sech1 was the other side of it, plus a couple sponsors and helpful people that let us snoop on the encrypted solutions :) 00:32:48 Also, not just their PoC repo, but if you want to implement one of these snoopers, you probably need to look at their EFI source code https://github.com/qubic/core/blob/main/src/qubic.cpp#L1920 00:35:41 Feel free to ask anything else or see if we can provide anything else (or other form of data) that could be useful. For example, we can provide list of pow hashes for solutions tied to tasks. These have 640M difficulty granularity, which can estimate their realtime hash quite accurately (even right now with their low hashrate each task receives around 8-12 solutions) 00:37:01 There's still no deployment of emergency DNS checkpoints or similar systems, so Qubic, although weakened at the moment, is still considered an active malicious attacker so not all is public currently. 00:38:14 Some of what we can do with the event logs and granularity is make specific timelines like on https://github.com/WeebDataHoarder/Monero-Timeline-Sep14 (open "Full Timeline Logs, including all stratum sourced templates") 00:40:05 these include data gathered from Tari as well for example, to corroborate the two chains existing at the same time (with Qubic's not disclosed). Just imagine that there's many more solutions in between in the full logs, they got too long for GitHub to render the markdown properly. 01:23:49 <0xfffc> https://www.thurrott.com/dev/330980/microsoft-to-replace-all-c-c-code-with-rust-by-2030 01:33:28 @0xfffc: In other news, microsoft is yet again surfing on the trend (programming in rust isn't gonna resolve the extreme loss of quality in code of these last 5 years) 01:38:04 @syntheticbird: but what about the AI tool doing the rewrite, have you accounted for that? 01:44:36 <0xfffc> https://dl.acm.org/doi/pdf/10.1145/3722041.3723102 01:44:51 <0xfffc> @0xfffc: I think they are thinking about something like this 19:50:46 speaking of AI tools rewriting things, https://fountain5405.github.io/adaptiveblocksizesim/ . this has the recent specs. https://github.com/Fountain5405/adaptiveblocksizesim