15:00:20 Hi, I’m one of the authors (Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. ) — thanks for discussing our work. We computed Qubic’s hashshare using both mainchain and orphan blocks, so that description of the paper is mistakenly incorrect. I’d be happy to discuss the other points further. 15:01:49 @suhyeon:matrix.org: Hello! Do you want to stay for the meeting? It will start in about two hours (17:00 UTC). 15:01:55 Especially we're interested in missing orphan blocks you pointed out. 15:02:17 oh can you share the information about the meeting? I have no clue 15:02:37 https://github.com/monero-project/meta/issues/1313 15:02:52 I can add you to the beginning of the meeting agenda if you want. 15:03:23 okay that will be great then ! 15:03:50 Fantastic. Good to meet you! 15:04:25 Good to meet you too 15:08:26 > <@suhyeon:matrix.org> Hi, I’m one of the authors (Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. ) — thanks for discussing our work. We computed Qubic’s hashshare using both mainchain and orphan blocks, so that description of the paper is mistakenly incorrect. I’d be happy to discuss the other points further. 15:08:26 Welcome! Thanks for joining 15:29:24 > <@suhyeon:matrix.org> Especially we're interested in missing orphan blocks you pointed out. 15:29:24 as a heads up, here's also a CSV with all identified "mined" Qubic blocks including orphans up to last week https://irc.gammaspectra.live/05eb9beefdebb016/blocks-proof.csv, in case of them being orphan the full block header is included, which contain a miner transaction that can be verified with their viewkeys. Most of the dat [... too long, see https://mrelay.p2pool.observer/e/mem1s9MKSFFLTE4y ] 16:59:20 We found the reason. At first we attributed Qubic blocks without relying on view keys and used coinbase pattern. Later, we found viewkeys are shared in Qubic's discord channel, we confirmed the identified Qubic blocks but didn't check other blocks not attributed with the pattern. Thanks for sharing the dataset. With yours, our hashshare estimate should be corrected as the below plot (red to blue). 16:59:24 https://mrelay.p2pool.observer/m/matrix.org/psnGtaHExKEFXgRjmKpmlFtt.png (image.png) 17:00:20 Meeting time! https://github.com/monero-project/meta/issues/1313 17:00:28 1. Greetings 17:00:34 Hi 17:00:40 waves 17:00:54 Hi 17:01:00 Hello 17:02:06 hi hivia hi via IRC 17:02:06 Is this meeting happening here in chat? 17:02:20 yes 17:02:32 okay good 17:02:33 hi 17:02:54 @suhyeon:matrix.org: Yes. MRL meetings are text chat only. 17:03:37 2. Updates. What is everyone working on? 17:04:41 me: Using Markov Decision Process (MDP) to analyze selfish mining countermeasures. Accidentally eating all the RAM on the MRL research computing cluster. 17:05:28 I updated and uploaded the latest scaling parameters 17:05:28 Capping MS to 8 ML 17:05:49 me: testing randomzied attention test to solve verifier's dilemma in optimistic rollups 17:06:13 Howdy 17:06:17 Implemented changes to tree building using the unbiased hash to point (unbiased hash to point is on the TODO list for beta), addressed all comments on outstanding PR's, we're close to releasing v1.5 for the alpha stressnet. Continuing today with tx relay v2, then may investigate a reported segfault 17:07:11 Me: working on knowledge proofs integration, reviewing PRs for v1.5 release, and still coordinating with potential auditors for carrot_core 17:07:52 Me: speced out fcmp++ spending in lws clients. Nothing built, just convos with berman and jeffro confirming plan. Also attempting to rebase the lws carrot patch after jeffros changes to some functions. The tests fail and I havent dug into why yet. A user reported 0conf was broken in carrot but I haven't verified. And otherwis [... too long, see https://mrelay.p2pool.observer/e/_7yettMKODRFVXpk ] 17:10:05 Cleaned up all recent additions due to FCMP/Carrot on my codebase to try to make it usable for any potential library users/p2pool. All carrot changes now converge as well. Working on finally making a full event log of Qubic mining events with the archived points of view of their network. 17:10:53 3. Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. (https://moneroresearch.info/293) 17:11:23 Welcome, @suhyeon:matrix.org (Suhyeon Lee), co-author of the paper! 17:11:40 How did you find out about this Matrix room by the way? 17:11:51 Hello Thanks for inviting me and also for discussion 17:12:08 Oh I found your discussion in X (twitter) and tried to reach out for discussion 17:12:44 I wanted to mention the description of the hashshare calculation is wrong, not the hashrate calculation itself 17:12:55 Also, wanted to know missing Qubic blocks from our dataset 17:13:22 Actually, this work was not systemized, one of side project with me and one undergraduate student (my mentee) 17:13:32 So dataset was collected after most of selfish mining 17:13:37 @suhyeon:matrix.org: I think @datahoarder:monero.social , true to name, has even more data than that. 17:13:42 indeed. 17:13:49 So there was some mistake and thanks to you we can improve the paper 17:14:24 Also, for that, I want to mention, at least, appreciation to you guys in paper later. If possible, cowork on the paper will be nice. :) 17:14:34 Hi @suhyeon:matrix.org. A few notes. I mostly noted that you lacked granular data on Qubic, and mostly ran on on-chain plus tasks from dispatcher (what you call job_notify) 17:14:53 @suhyeon:matrix.org: Do you plan to publish the analysis code and make it open source? 17:15:15 @datahoarder: Yes we collected such data during only very limited time. 17:15:32 @suhyeon:matrix.org: I would be open to collaboration on the paper :) 17:15:32 @rucknium: Yes 17:15:45 I have an archive on all historical tasks from their network, with full block template. Additionally, we also have a record of all solutions of 640M or higher (a block is a high difficulty solution, usually at several G) 17:15:59 Currently, I'm very busy with my main job. After some hassle, of course, we should publish all the codes. 17:16:11 That gives us around 6-20 solutions for every task which allows calculating hashrate of Qubic directly from source. 17:16:19 The reason why we didn't publish the codes is now it's too much with mess 17:17:02 @datahoarder: Great. How did you collect all the data? 17:17:06 If you go back to when your paper was posted in this room historically I posted some charts comparing what we saw hashrate wise from them, but that's captured from the live database. 17:17:27 We connect to their consensus network directly and gather raw packets. These are verified against public keys 17:17:55 Then we gather tasks from dispatcher, and solutions for each task, provided by computors and signed by them. 17:18:06 Each solution includes nonce values and PoW hash (for verification) 17:18:10 okay I'll check this later > <@datahoarder> If you go back to when your paper was posted in this room historically I posted some charts comparing what we saw hashrate wise from them, but that's captured from the live database. 17:18:32 Discussion starts here ^ . @suhyeon:matrix.org , can you try to click on the message? > <@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. 17:18:41 What was the major difference in conclusions of your analysis other than hashrate? 17:18:47 However, this dataset has not been publicly gathered/released at this moment. Nonetheless the hashrate values are mostly similar to the ones reported by Qubic 17:18:57 @rucknium: Thanks it works 17:19:15 What I wondered was their selifsh mining strategy in the research 17:19:38 We also saw similar lack of efficiency on their selfish mining. Initially estimated to -20% losses, later they optimized to -10-8% losses 17:19:59 The state machine you built is generally very close to what we observed, though they changed it over time. 17:20:12 IMHO, their aim was propaganda. To publicize their cryptocurrency. 17:20:13 I came across Qubic guys in TOKEN 2049 Singapore 17:20:25 I asked what they're doing in Qubic 17:20:32 @rucknium: I agree 17:20:43 Becuase of that I know Qubic now X) 17:20:58 They said they're doing optimized selfish mining 17:21:16 So I wondered they use theoretically optimized selifsh mining based on the Markov chain analysis 17:21:17 Additionally, there is bias on blocks published by Qubic. Not all of them were intended to be published, some of the bias was caused by sech1 / me :) 17:22:01 So I checked if they did 'catch up' which means they're behind and try to catch the main chain height. But we didn't find any intended or systemic trials on it. 17:22:04 in many cases this bias just made them more profitable (it prevented their selfish mining) and your analysis covers later stages, which were not biased this way. 17:22:15 Rather, we found they made selfish mining less efficient that is analyzed in the paper 17:22:31 @suhyeon:matrix.org: They do not. The most they do is if they are at "par" after releasing their chain they will stick to it until next block. 17:22:34 @suhyeon:matrix.org: My guess is that they released blocks manually. It was a human judgement decision usually. 17:23:05 It was automated in later stages. Some of the first long trials were manually released, yes 17:23:13 Can you explain it more, I didn't understand clearly > <@datahoarder> Additionally, there is bias on blocks published by Qubic. Not all of them were intended to be published, some of the bias was caused by sech1 / me :) 17:23:34 Basically. We read their nonces and built blocks to send them to the Monero network. 17:23:39 @rucknium: if it's human decision, wow. Then, how did you guess so? 17:24:22 This makes them look like they weren't selfish mining for a given period, but they were. This was later prevented by including undisclosed transactions in their blocks. 17:25:42 @datahoarder: @datahoarder:monero.social and sech1 prevented their long private alt-chains from forming by forcing them to be public. 17:26:12 Initially we pushed all instantly, later kept their chains short 17:26:13 It was some intense spy-vs-spy, cloak-and-dagger maneuvering. 17:26:15 @datahoarder: That's smart. Then, they changed a strategy for that? 17:26:43 @rucknium: Sounds like game theory 17:26:46 They added encryption. They added new encryption. They added new new encryption. They blamed pools, disabled task dispatchers, and so on. 17:27:00 A heroic battle in the shadows 😎 17:27:05 Nothing worked until they added the undisclosed transactions, after it was discussed in an MRL issue :) 17:27:14 You are cool, guys 17:28:00 All they did was centralize their network more, anyhow. Their infrastructure back then and now is effectively just a centralized pool with central dispatcher authority that decides what to mine 17:29:04 The encryption algorithms they use were kept private as well. So anyone verifying solutions is unable to do so anymore. 17:29:08 I think I can't stay much longer cause it was not a plan today for me. How can we communicate later? Especially @datahoarder:monero.social 17:29:16 The encryption is kept secret, only to be revealed via discord DMs 17:29:29 I'm around here and #monero-research-lounge:monero.social 17:30:09 Okay I'll talk to there later then 17:30:21 As of last note, besides a specific oddity during a night, the reported hashrates on their API were mostly correct to what the internal stratum was. 17:31:38 Any other discussion on the paper/Qubic for now if @suhyeon:matrix.org has to leave? 17:31:43 @suhyeon:matrix.org: Thank you very much! It's always great to see more people researching Monero. 17:32:04 @suhyeon:matrix.org: Here is something I wrote about Qubic's disruption: https://rucknium.me/posts/monero-18-block-reorg/ 17:32:35 Oh thank you so much. I'll check this too. 17:32:50 Thanks for invitation and also thanks for your information. 17:32:54 Have a good day guys 17:34:00 4. Spy nodes (https://github.com/monero-project/meta/issues/1124). 17:34:23 (if you need input in other topics from me I'll be AFK, ping if needed, doesn't seem like from agenda) 17:35:14 It seems that the new spy nodes have been consistently connected to the network for a week: https://moneronet.info/ 17:36:24 Last meeting I suggested that we wait until this meeting to confirm the switch to the new IP address ranges and adopt/publicize the new MRL ban list 17:37:50 The new proposed list is https://github.com/Boog900/monero-ban-list/blob/update/ban_list.txt 17:38:07 I confirm it too, when I look at one of my node firewall log, the only thing I can see are the thousands lines that start with "SPIES" on the new range! 17:38:07 I did keep the old range blocked in case 17:38:49 How can versioning be handled? IIRC, you can add comments to specific lines in the ban list file. IIRC, @jeffro256:monero.social added that feature. Can comments be added on their own line? 17:39:26 Yes 17:40:09 Everything on a line on or after a pound character is ignored, then whitespace is stipped, and empty lines ignores 17:40:12 *ignored 17:40:48 And there is the DNS ban list. One could take a big step and completely replace the DNS ban list with the new MRL ban list (or as many IP addresses on the MRL ban list that fit). It seems that all the nodes on the DNS ban list have disappeared from the network. 17:41:27 Or you could keep most of the DNS ban list unchanged and add the big /24 subnets from the new MRL ban list. 17:43:32 @jeffro256: So maybe a comment could be added to the top of the MRL list: Version 2 or something. And put in-line comments on the old and new /24 ranges, describing what happened. 17:44:02 I just remembered that I wanted to say something at the beginning of the meeting: 17:44:58 Next Wednesday is December 24. Personally, I won't put up an MRL agenda in the meta repo and I won't chair a meeting then. If anyone else wants to, they should feel free. 17:45:01 We could, do we care the ban list won't then work on older daemons though? 17:45:30 Good question. Maybe just the comment on the top. That's supported on old nodes, right? 17:47:50 i dont think so 17:50:13 Here is your PR: https://github.com/monero-project/monero/pull/9558 17:50:38 I thought from the decision that non-inline comments were allowed before, but maybe not. 17:50:48 the description* 17:51:43 Is there another way to properly version the list? Or just live without proper versioning? 17:52:21 Nope, they weren't a thing at all. The old parsing code reads a line in, then immediately tries to parse it as an net address 17:53:04 IIRC the net address parsing code skips whitespace, but definitely no comments 17:53:30 Any comments from anyone else about this topic? Anyone opposed to updating the MRL ban list and publicizing it? 17:54:08 Is @preland:monero.social here? 17:54:36 I'm taking a final in 6 minutes (sry) 17:54:39 I think it's ok that the ban list doesn't work on older daemons 17:54:57 @preland:monero.social: Good luck! 17:55:21 Me too. If they're not updating their daemon code, they're probably not keep up-to-date with the ban list 17:55:26 The recent updates have been important, more people updating is good 17:56:24 Do we know what happens if a ban list with comments is ingested by an old-version node? I can try it if we don't know yet. 17:58:16 The next agenda item (Post-FCMP scaling concepts) was suggested by preland, but they are busy now. Going to next item. 17:58:32 6. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-01.pdf). Revisit FCMP++ transaction weight function (https://github.com/seraphis-migration/monero/issues/44). 17:58:44 https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-03.pdf 17:59:01 Last week @boog900:monero.social , tevador , and I raised explicit support for max growth of 1.2x the LTM, in addition to the sanity cap 17:59:08 @boog900:monero.social mentioned this would allow for 40-47x growth within 1 year, and 2.5x every year after that 17:59:11 40-47x year 1 growth also fits within @ofrnxmr:monero.social's expected growth also shared last week: https://libera.monerologs.net/monero-research-lab/20251210#c625246 17:59:19 I do not think the sanity cap justifies a higher LTM growth rate, because as @boog900:monero.social has argued, the sanity cap eventually will not matter due to its exponential growth 17:59:29 Personally I would prefer @boog900:monero.social's proposed params over all proposals, and rank my order of preference: 17:59:39 1. @boog900:monero.social's proposed params, 2) sanity cap, 3) hard cap 17:59:56 I am in favor of all 3, but personally mention I'd be ok with excluding the hard cap 18:00:01 I have updated this to to cap the MS growth to 8 ML 18:00:31 Rucknium: a comment line in the ban list should get printed on stdout and skipped 18:00:57 I have given my reasons for keeping the growth of ML at 2 under the sanity cap 18:02:30 @jeffro256:monero.social: Would the rest of the ban list lines be interpreted normally and successfully? 18:02:41 I think so, but I haven't tested 18:02:53 @rucknium:monero.social @jeffro256:monero.social @ofrnxmr:monero.social curious if you have thoughts on 2x LTM versus 1.2x LTM 18:03:53 We must keep in mind the sanity cap applies 18:04:13 So it is the lower of the two 18:05:02 > I do not think the sanity cap justifies a higher LTM growth rate, because as @boog900:monero.social has argued, the sanity cap eventually will not matter due to its exponential growth 18:05:44 @jberman: I think that max long-term growth YoY of 2.5x is enoug, personally 18:05:58 growth in block size 18:06:23 Which corresponds to the 1.2x LTM value, right? 18:06:31 right 18:07:08 Then I am also in favor of boog's proposal 18:07:27 Yet but this ignores the suppression of Monero for at least the last 5 years 18:07:54 non sequitor 18:08:25 I know about the lobbying behind the scenes here 18:08:45 It is not a non sequitor 18:09:04 It is, and your constant witch hunting is hostile to the Monero project 18:09:15 IMHO 1.2x growth on the 100,000-block long-term median (LTM), which allows 2.5x growth annually after exhausting the short-term growth ceiling, would sound good to me. Stressnet is having difficulties processing the (rough) amount of txs that the short-term growth would allow. 18:09:58 @rucknium: But you are ignoring the sanity cap 18:10:21 > I do not think the sanity cap justifies a higher LTM growth rate, because as has argued, the sanity cap eventually will not matter due to its exponential growthboog900bo 18:10:32 3rd time I've posted this message and you've consitently ignored it every time 18:10:48 boog's was without a sanity cap 18:11:13 That is not a coherent response to the message 18:11:33 What is your rationale 18:11:40 I don't really like exponential growth in the long term, but changing the functional form would require re-analysis of the whole blocksize-fee interaction system. 18:11:54 IMHO, fee analysis of blockchains is nontrivial. 18:12:23 Expontential growth in the long term means that it will eventually grow so large that it won't have any impact in limiting growth 18:12:23 It is the lower of the two 18:12:52 IMO I think that there should be a sanity cap just to be safe on either of the proposals, which doesn't necessarily have to be exponential indefinitely 18:13:34 I agree with the sanity cap 18:13:48 Asking for rice grains on chessboard squares. 18:14:05 What I don't understand is why lock in the harm that has by done 18:16:03 It isn't locking in harm that has been done that is a madeup argument that has no basis in reality. It's implementing rational limits that ensure the network remains healthy 18:16:08 I think that the harm is a sunk cost, we can't unharm reputation / adoption / suppression by allowing big blocks. The harm is at root done at the human level. Yes, perhaps Bitcoin's p-to-p use case is bottlenecked at a technical level, but we're not there: our use case is bottlenecked at the political / adoption level 18:16:27 https://bitinfocharts.com/comparison/monero-transactions.html#log&alltime 18:16:58 I can't ignore the suppression and how much longer it can go on 18:17:26 Good thing 1.2x LTM allows 40-47x growth within 1 year and 2.5x per year every year after that 18:17:27 Just look at the historical transaction data for Monero 18:18:11 @jberman: It does not if the suppression continues 18:18:38 Yes, it does 18:19:11 The is no chance to recover 18:20:05 Do the math for another decade of suppression 18:20:43 You cant predict the future usage of monero 18:20:45 By your argument, a 10,000x LTM also would not allow for growth if suppression continues 18:21:05 @boog900: Neither can tou 18:21:19