15:07:52 MRL meeting in this room in two hours. 17:00:33 Meeting time! https://github.com/monero-project/meta/issues/1247 17:00:38 1) Greetings 17:00:59 Hi 17:01:03 Hello 17:01:22 Hi 17:01:50 Hi 17:02:24 *waves* 17:02:41 hello 17:02:50 Howdy 17:03:16 hi 17:04:03 2) Updates. What is everyone working on? 17:04:40 Me: currently fighting the monero_c build process 17:04:51 me: Setting up "honeypots" to discover more about spy node infrastructure. Monitoring Qubic hashpower share: https://gist.github.com/Rucknium/0873b10b6d36ff6c9d6f8f54107d16f7 I submitted a new research CCS proposal: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/599 17:06:10 Me: finished firs draft of hot-cold FCMP++/Carrot wallets, reviewing rbrunner7's subnet dedup PR 17:06:27 me: squashing bugs reported by ofrnxmr in the fcmp++ integration, refactoring refresh() to *not* download all hashes in the chain from before the wallet's restore height (since this has no tangible benefit as is) 17:06:58 me: still driving the bots to build monerosim. 17:06:59 I have been working on the scaling. Expect to have a revised document for the next meeting. 17:07:01 A long term sanity median is very much feasible and the wallets can be insulated from constant fee calculations 17:08:12 The value will also be in using MA for node relay bandwidth caps to effectively manage the blocksize 17:08:48 3) [Transaction volume scaling parameters after FCMP hard fork](https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf). 17:10:08 As I mentioned a sanity median is in the works. 17:10:09 One thing I am looking for is the latest stress net TPS for FCM++ 17:10:22 FCMP++ 17:10:55 Did the tx byte sizes from last week affect your analysis at all? 17:11:18 Not materially 17:12:19 The more critical issues in my mind iss going to be verification times 17:13:24 Since 1) they are serious and 2) can be mitigated substantially outside the consensus 17:14:01 Multi thread and GPU / graphics verification will be critical here 17:17:06 I am going to disagree that GPU verification is critical. It's a nice-to-have, but far from critical IMO 17:17:09 Byte sizes alone point to verify large block sizes because of current bandwidth availability. In my analysis the impact of sizes is for the most part factored in with the change to ZM 17:18:04 It means we have to restrict blocksize in non consensus 17:18:45 But it is not required right now 17:18:56 GPU verification 17:19:43 I wonder how many years left before we're going to ask ourselves about NPU verification 17:20:14 It depends on transaction demand 17:20:36 draft of a gist on it, or code-related? any links? 😁 17:21:11 rottenwheel: working code: https://github.com/seraphis-migration/monero/pull/52 17:21:14 https://github.com/monero-project/monero/pull/9856 this sped up initial sync by 40% for me 17:21:32 ah, yes; saw that before around here. thank you. 17:21:53 Not sure about w/ fcmp or w/o checkpoints 17:22:20 [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) good luck with the new proposal. thanks for the continued research and reports. 17:23:33 ofrnxmr: FCMP++ uses curves (Helios-Selene) where that scalar-point multiplication wouldn't be applicable, so the speedup will almost certainly be less pronounced syncing FCMP++, but that's very interesting 17:23:35 Wondering if there are any changing thoughts on tx weights clamping to powers of 2? Just reiterating from last week, this would incentivize the creation of multiple tx of lower input combinations instead of single larger txs (e.g. 1-in + 2-in > 3-in) 17:25:02 My take is that there will be significant improvement in verification after the FCMP++ fork. 17:26:01 1 in + 2 in > 4 in becomes the test 17:26:15 With power s of 2 17:26:55 By ">" I meant, a user is incentivized to spend 3 inputs across 2 txs (a 1-input and a 2-input), instead of in a single 3-input tx 17:27:13 I understand 17:28:08 We also would prefer people do a 4-in over a 3-in & 1-in, so it has to be bounded in both directions 17:28:57 If the cost of 3 in and 4 in are the same. Then we end up comparing 1 in + 2 in to 4 in 17:29:31 What if a user only has 3 inputs? 17:29:55 They have to pay for 4 17:30:14 3 in is still valid 17:30:46 They would be better off spending as a 1-in and 2-in instead of 3 though 17:31:40 Then this is the case against powers of 2 17:33:10 right I was wondering if there are any thoughts on changing the currently proposed powers of 2 approach, taking that case into account 17:33:55 Yes. This really comes down to the t numbers 17:34:28 Both size and verification time. 17:35:52 It is not just proof sizes. There is also the base part of the tx to consider 17:36:38 and the greater number of outputs 17:38:59 jberman: depending on the specific weight function, your issue of making a 2-in + 1-in instead of a 3-in because of the powers of 2 weight might not be so bad if we model the sender as also taking into account the *future* weight of having to spend 2-in versus a 1-in 17:39:13 There is another advantage to powers of 2. It encourages the consolidation of dust 17:41:10 In that case it's even worse no? because the future 2-in weight will be > future 1-in 17:41:26 Now if in the future, they only needed a small input from one of the two, then they pay no additional cost, however, if they needed to consolidate, they would pay that cost. So its strange b/c it's conditional on how they schedule their future payments 17:41:56 Oh you're saying it's more expensive to them in the future to consolidate those 2 future outputs, gotcha 17:42:01 Right, which would naturally disincentive the sneder from doing that 17:44:44 Methinks we need a fee market simulation 17:45:28 I can work on a table of all FCMP++/Carrot byte sizes and current verification times of default txs of 1 - 128 inputs and 2 - 16 outputs 17:45:29 did someone say simulation 17:45:31 It contains rational actors trying to pay the least amount of fees while fulfilling payments in a certain timeframe 17:45:42 Did someone say market 17:46:18 While node actors adjust the fee market policy to minimize verification time and storage costs 17:47:38 This would be very helpful 17:47:59 ... and answer this question 17:48:28 Will do that and comment it here: https://github.com/seraphis-migration/monero/issues/44 17:48:54 4) [FCMP++ optimization coding competition](https://www.getmonero.org/2025/04/05/fcmp++-contest.html). 17:49:55 Last meeting we planned to have a post-mortem discussion about this. 17:50:05 jberman do you want to dump the post here now, or publish it in a bit ? I'm fine w/ now 17:50:20 IMHO, the big win was `ec-divisors`, which attracted one (IIRC) submission, but got a 30x speedup. 17:50:30 Oh, there is a post 17:50:39 I'll dump it here, one sec 17:51:23 Is xmrack here today? 17:51:58 And the `ec-divisors` win makes me wonder if the speedup could have been achieved by doing a review of the relevant literature and finding the fast algorithm that way, instead of a competition. I mean, as a lesson for the future. 17:52:21

Hello 17:53:34 https://paste.debian.net/1388773/ 17:53:35 The one thing I wanted to talk to xmrack about is how they went about scouting for contestants, and if there is anything to be taken away from that process. (you don't have to answer now lol I kinda put you on the spot). That was something I wasn't involved in, but the outreach that they did produced good results. IIRC they contacted Fabrizio directly. Is that correct? 17:57:53 Fabrizio ack'd kayabanerve 's idea to use an FFT as "likely better" here: https://github.com/fabrizio-m/fcmp-competition/pull/1#issuecomment-3033736170. It was also a matter of finding someone to do the work 17:58:59

Correct. I looked at the ZPrize contest (recommended by kayaba at some point) which was the most similar contest to what we planned on running. https://github.com/z-prize/2023-entries 17:58:59

I went through each of the submissions for 2022 and 2023 and dug out contestants email addresses from their submissions and reached out to them directly. I only received a few replies with Fabrizio being one of them. 17:59:01

I also reached out to people who have published monero-related cryptography related research papers but had no luck there. 17:59:03

I’m not sure I have any lessons learned besides that we got really lucky with Fabrizio being a wizard and a perfect fit for our rust-based competition 18:01:59

I think posting to reddit was good for general awareness but I’m not positive that was successful at attracting competitors. 18:04:01 Ready to move to the next agenda item? 18:04:45 5) [FCMP alpha stressnet planning](https://github.com/seraphis-migration/monero/issues/53#issuecomment-3053493262). 18:06:11 - Unable to connect a wallet to an unrestricted rpc if txpool > 100mb: https://github.com/monero-project/monero/pull/9473 18:06:11 - dynamic block sync size: https://github.com/monero-project/monero/pull/9494 also here https://github.com/seraphis-migration/monero/pull/78 18:07:15 jberman mentioned that the >8-in PR is ready for review now, I will take a look at it very soon 18:07:38 I'd also like to knock out this wallet refresh refactor too to address ofrnxmr 's bugs 18:08:30 Ive tested the bss numerous times, but am unsure about 9473's correctness 18:08:35 Ive tested the dbss (9494) numerous times, but am unsure about 9473's correctness 18:10:19 what was the reasoning on 9473 for not just requesting max 100 txs at a time on unrestricted too? that seemed like a simple solution to the issue there 18:11:51 I dont know. Batching into 100 (or even 500) seems like the most simple solution 18:13:34 can discuss it further later 18:14:58 w.r.t. stressnet, I'd say let's get 1 more week to address above (refresh refactor, 9473, 8 input PR, and dynamic block sync size) 18:16:18 What will it take before we can use the optimized libs? 18:17:12 (currently takes me abt 20 seconds to build an 8in 8out tx, iirc) 18:17:50 Lederstrumpf's helioselene optimizations + kayaba's optimizations on top are already merged upstream. Open PR over here for fabrizio's: https://github.com/kayabaNerve/fcmp-plus-plus/pull/33 18:18:43 If fabrizio's not in by next week, I'll just push to my fork and we can use it from there in fcmp++-stage 18:19:27 6) [Spy nodes](https://github.com/monero-project/research-lab/issues/126). 18:19:41 I've set up some "honeypots" to try to learn more about the spy node infrastructure. No results to report yet. 18:19:52 My proposal to make a few changes to the DNS ban list contents is available for comments & questions: https://github.com/monero-project/meta/issues/1242 18:20:23 Like jeffro256 say, he is working on reviewing rbrunner's PR: p2p: Improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes' https://github.com/monero-project/monero/pull/9939 18:20:42 Thankful for that :) 18:21:04 Anything more on spy nodes? 18:22:12 7) [Proposal and spec for Proof-of-Work Enabled Relay ("PoWER")](https://github.com/monero-project/research-lab/issues/133). 18:22:28 Not spy node related, per say, but there are miners that seem to check ports and possibly mine on them 18:23:03 my xmrig-proxy has 20 unknown monero addresses that have connected to it over the past month or so 18:23:35 ofrnxmr: You mean trying to start the miner through an unrestricted RPC? Or just a nodeless miner looking for block templates? 18:23:44 I think boog900 raised some valid points that bump favorability of Equi-X over RandomX in discussion starting here: https://github.com/monero-project/research-lab/issues/133#issuecomment-3130110655 18:24:07 Thanks a lot for your hard work! 18:24:23 No, i mean a miner (probably xmrig) is connecting to my xmrig-proxy 18:24:54 I'm still curious how long RandomX PoW construction on light mode would take, assuming it takes some reference machine 1-2s on fast mode 18:25:14 Haven't gotten around to testing that out 18:25:28 They have their user section of xmrig set to a primary monero address, so it doesnt seem to be just knocking kookijg for unrestricted rpc, but an actual miner looking for a stratum or rpc 18:28:05 8) PoW mining pool centralization. [Qubic Monero Hashpower Share](https://gist.github.com/Rucknium/0873b10b6d36ff6c9d6f8f54107d16f7). [TEE-assisted Censorship-Resistant Block Template Production](https://github.com/monero-project/research-lab/issues/134). 18:29:26 Qubic changed their mining wallet at around 9:30 UTC today, so their mined blocks cannot be deduced from the method I used in the gist ^ anymore. And their pool API has stopped working AFAIK. 18:30:00 But you can get a good approximation of the number of blocks they have mined by getting all the blocks that other mining pools claim, then seeing what's left. 18:30:17 Is there anything in tx extra? 18:30:32 I see 15 - 25% of blocks unclaimed by other pools, in the last 24 hours 18:30:46 That is unique to Qubic? 18:31:14 I am not sure about the tx_extra contents 18:31:24 So the unclaimed blocks may have a signature 18:31:54 The unclaimed blocks were like 5% before? I dont remembwr 18:31:55 Tx extra for the coinbase is used by Tari 18:32:05 Unknown blocks were 1.5% of all blocks before, so just subtract 1.5% from what https://miningpoolstats.stream/monero pie chart shows 18:32:58 Years ago, DataHoarder made this Go program that pulls the blocks claimed by most major pools' APIs: https://git.gammaspectra.live/WeebDataHoarder/monero-blocks 18:33:14 could update it to re-fetch data 18:33:24 miningpoolstats.stream shows 5% unknown, 12% qubic over the last 1000 blocks. And 11% now (unknown) 18:33:43 Also the PoUWin Qubic is highly centralized with like 90% control 18:33:45 And then https://p2pool.observer/api gives you p2pool-mined blocks 18:34:50 Qubic claims that many miners are switching to their pool. I don't yet believe that claim without evidence. 18:35:00 DataHoarder: Please do if you can spare the time 18:35:12 I will be on MoneroTalk regarding Qubic later today 18:35:13 I dont believe that claim at all 18:35:16 4.71 GH/s are not on their pool at the moment. So they need 4.71 GH/s to overtake them 18:35:31 So far they haven't shown more than 2.2 GH/s even at peak moments. 18:35:56 I wonder how much info the makers of xmrig have about miners possibly switching pools, from the 1% hashrate donation behavior. 18:36:05 The only evidence about switching miners was from supportxmr 18:36:13 https://p2pool.observer/api https://mini.p2pool.observer/api (and nano, old, old-mini) etc. but they can be coalesced 18:36:16 they had ~300 MH/s miner profit switching between Monero and Qubic 18:36:24 They need to incentivize by paying Qubic to get the hash rate to move 18:36:34 in general if the mining coinbase has quite some outputs it tends to be p2pool, specially with the merge mining tag 18:37:08 If subsidizing attacking hashpower is their strategy, two (or more) can play that game. XMRvsBeast already does some subsidization of p2pool miners with the hashrate raffle, AFAIK. 18:37:17 So about 6% 18:37:31 Current Qubic price is $0.000002281 per coin, and give 1T/week emission, it's $325k/day going to miners 18:37:37 double that of Monero's miner subsidy 18:37:56 So they in theory can overtake Monero in raw hashrate, they do have the money (daily subsidy) 18:38:13 The question is, how do they manage to keep the price from falling, they're a small cap coin 18:38:24 This depends on the price difference and the effective emission of Qubic vs Monero 18:38:38 Do they have the buy liquidity to support that 325k/day 🙃 18:38:40 Their effective emission (in $) is two times bigger right now 18:39:03 You can claim 325k by looking at spot,but its not real if you cant exit your position without crashing the price to 0 18:39:20 No they are getting Qubic to cover this 18:39:42 It. Is an effective merged mining 18:39:47 So someone is dumping big money to keep the price afloat and subsidy the miners 18:40:18 They have to keep the Qubic price afloat 18:40:28 right. They sell xmr for 30k/day, buy qubic with 30k (or put up buy walls) 18:40:55 hoping nobody actually mines qubic,sells 100% of it and buys 2x as much xmr 18:41:09 Then they have to pay for power 18:41:10 Also, TradeOgre is currently down (this exchange had a huge amount of Qubic on the sell side). 18:41:33 Bingo 18:41:50 That makes it easier to keep the price afloat, because there is a lot of coins locked there now and for an indefinite time 18:41:56 Feed the Qubic to the bears 18:43:10 ... but they can manipulate Qubic to mitigate this bear raid approach 18:43:40 By locking the Qubic up 18:45:00 Also Qubic plan the halving in 3 weeks time, that will reduce the subsidy proprotionally (unless they manipulate the price again) 18:45:05 Awareness can be a real problem for them 18:45:08 If you want to fight fire with fire, the Core General Fund could temporarily subsidize honest hashpower. (Of course, I love volunteering other people's money 😁.) 18:46:15 The best way to subsidize XMR hashrate would be to pay P2Pool miners (proportionally to their hashrate) - it's easy to put together a list of miners every day for a manual payout, DataHoarder's observer can do it 18:46:19 I don't know what other realistic active countermeasures there may be. 18:46:27 how would honest miners be picked 18:46:36 If countermeasures are considered necessary. 18:46:36 I just wrote how 18:46:57 weight of their shares in difficulty units is tracked as part of consensus 18:47:09 Right. The p2pool sidechain is a secure, honest way to get the addresses of miners. 18:47:22 Currently, all P2Pool miners earn 20-22 XMR/day. If 50 XMR/day are paid to them, that's double the profit and a good enough incentive for other miners to switch 18:47:49 No, not the double. More than triple, because it adds up 18:47:50 ah okay, and qubic block structure is incompatible with p2pool requirements? 18:48:08 Yes, they are incompatible 18:48:08 p2pool can merge mine, are they "merge mining" or doing something else? 18:48:18 What if Qubic points its own hashpower at p2pool? Wouldn't the forced orphaning tatic fail, because other p2pool miners would be mining on other miners' honest blocks? 18:48:18 Qubic is merge mining Tari 18:48:39 Qubic was using p2pool before 18:48:50 No, they used nanopool 18:49:03 They used p2pool for a while too 18:49:40 I'm not aware of that, and I watch p2pool daily 18:49:47 The `--enforce-dns-checkpointing` optional flag also exists, but IMHO its use should not be encouraged. Just a reminder that it exists: https://docs.getmonero.org/interacting/monerod-reference/#server 18:49:49 I see as the better strategy " merge" mining Qubic by honest Monero miners 18:50:18 "Mining" Qubic leaves you no choice but to also participate in their attack 18:50:34 they use some centralized approach for mining 18:50:51 They just let you run xmrig pointed to their pool. Did nobody here actually try? 18:50:55 Moneroocean wrote about adding qubic to their pool, but wasnt as simple as a regular chain 18:50:57 No if one can decentralize Qubic 18:51:08 https://matrix.monero.social/_matrix/media/v1/download/monero.social/QozzcjCsmwKnwuYBsREzxdyy 18:51:14 Take the fight to their chain 18:51:22 They don't have one :) 18:51:31 https://matrix.monero.social/_matrix/media/v1/download/monero.social/vGPKThqFvmAAnCBOZVQjpBJg 18:52:30 rbrunner: And xmrig doesn't let you pick the block template, right? 18:52:46 It runs fully under control of their "miner" 18:53:47 And you know what is really hilarious? So far on each day except Saturday they run xmrig only 50% of the time 18:53:49 Is there the possibility of a Qubic chain split 18:54:04 Again, there is no chain. 18:54:39 They have block explorer IIRC 18:54:44 Please, you all. Have a closer look. It's a very interesting beast. Very different. 18:54:46 a block explorer* 18:55:08 It is 18:55:10 No, they have a tick explorer 18:55:17 Those are not blocks in some blockchain 18:55:22 Yes, what are those ticks?! 18:55:27 git has a commit explorer too 18:55:42