15:00:29 MRL meeting in this room in two hours. 17:00:24 Meeting time! https://github.com/monero-project/meta/issues/1310 17:00:27 1. Greetings 17:00:43 Hi 17:00:45 Hi 17:00:48 Hello world. 17:00:49 hi 17:00:57 Howdy 17:01:10 Hello 17:01:20 waves 17:01:29 Hi 17:01:31 Hi from IRC 17:02:49 Hello 17:02:53 2. Updates. What is everyone working on? 17:03:45 Revisiting PQ encryption (#151). 17:03:48 I have reviewing the various scaling proposals 17:04:12 Implemented Carrot PQ derivation changes and PQ Turnstile test on my libraries, and tested convergence. Stressnet testing, launched https://stressnet.p2pool.observer/ (for as long as stressnet monerod survives). Analyzing long term Qubic log artifacts, it's ~800 GiB of compressed event logs. 17:04:16 me: Working on analysing selfish mining with Markov Decision Process (MDP). Getting stressnet more stressed. Updated https://moneroresearch.info to the latest version of WIKINDX, with some help from @plowsof:matrix.org . 17:05:04 Me: Added PQ changes to spec, working on knowledge proof integration into wallet2, communicating with potential code auditors for carrot_core, reviewed some seraphis-migration PRs 17:05:10 Identified and patched issues causing broken and unreliable sync when the pool exceeds the max weight allowed, currently investigating unexpectedly slow multithreaded FCMP++ verification 17:07:23 Me: working on boost::beast transition in lwsf for websocket support. Otherwise bug fixes in lws+lwsf infrastructure 17:08:04 3. Bulletproofs* (more efficient membership and range proofs) (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626). 17:08:22 This CCS proposal has now moved to Funding Required. 17:08:44 Hi, I’m the proposer of the Bulletproofs* research. Thank you all. 17:08:44 No additional comments beyond the previous meeting. I just wanted to let the community know that this proposal has been merged. I’m truly happy about this and I look forward to seeing it funded: 17:08:44 https://ccs.getmonero.org/proposals/emsczkp-research-folding-gbp.html 17:09:17 More discussion of Bulletproofs*? 17:10:05 jeffro256: where can I find the PQ changes to carrot? 17:10:38 tevador: https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243 17:10:38 https://github.com/jeffro256/carrot/pull/6 17:10:48 https://github.com/jeffro256/carrot/pull/6 17:10:57 https://github.com/seraphis-migration/monero/pull/250 for C++ code port 17:10:58 jinx 17:11:05 Thanks, DataHoarder 17:11:08 Thanks 17:12:02 4. Spy nodes (https://github.com/monero-project/meta/issues/1124). 17:12:43 I noticed yesterday that the spy nodes on the LionLink Autonomous System Number (ASN) had disappeared from my scanner: https://moneronet.info/ 17:13:46 I think that the spy node on DigitalOcean and Hetzner are still there. About a month ago they started "hiding" themselves by not responding with the spy node fingerprint. 17:13:58 But @boog900:monero.social may have more info 17:14:50 tevador: Changes in #6 may (needs reviewing) allow a PQ switch-style migration which securely 1) opens amounts to existing amount commitments, and 2) opens key images to existing output pubkeys. The signer should be able to make a Schorr signature against their prove-spend key, univariate over the T generator, which is A) hi [... too long, see https://mrelay.p2pool.observer/e/mfeFltEKTm9ZR1hL ] 17:15:28 I think they have just switched to these IP ranges: 17:15:28 ``` 17:15:28 45.13.179.0/24 17:15:28 82.26.133.0/24[... more lines follow, see https://mrelay.p2pool.observer/e/yZ2IltEKRlcxaTdF ] 17:15:35 It destroys spend privacy for the migrated enotes, but should leave the history of the rest of the wallet hidden 17:15:57 @boog900: This is more IPs than they had before as well btw 17:16:18 But they showed up with the spy fingerprint on the new range? 17:16:20 By "just switched" we mean "switched in the last 24 hours and the scanner should display the info when it updates the data for today." 17:16:52 @jeffro256: Yep 17:18:21 Those ranges are on a different ASN that got registered a few weeks after I found the spy nodes last year 17:18:53 hmmm, does anyone have any hypothesis why they would have shown up non-fingerprinting on the old range, but fingerprinting on the new range? 17:19:00 IMHO, it's strange that the DigitalOcean & Hetzner spy nodes fixed their spy fingerprint, but these "new" nodes coming online today did not. 17:19:30 Two entities using the same software. One entity fixed their software. 17:19:38 One hypothesis ^ 17:20:26 You think perhaps someone is selling this spy node software commercially? 17:20:49 Maybe monitor the situation for a week and then update the official MRL ban list with the new IP ranges and announce it. 17:21:06 They are as part of BS 17:21:22 Maybe they had an automatic deploy script, but forgot to update the deploy script 17:21:35 @jeffro256:monero.social: I don't know how plausible it is, but it's a possibility that came to my mind. 17:22:51 BS does not have to work, to make money. The illusion of surveillance is enough 17:23:35 The 2 proxies always behaved a bit differently, I suggested that they might just be trying to stop us from finding their other nodes. 17:23:35 If they keep the big subnets as obvious proxies, then they might have thought we are less likely to look for difference in behavior and find their other nodes. 17:24:09 By the way, the second chart on moneronet.info, "Estimated number of honest nodes with ban lists enabled", increased the number of nodes with "DNS ban list enabled", but those are probably false positives. 17:24:23 They can't really keep them hidden anyway, 2000 nodes going offline then 2000 nodes going online is pretty obvious 17:24:35 Since no nodes on the DNS ban list are on the network anymore, all nodes don't have them in their peer lists anymore. The data in the chart is an inference, not direct measurement, based on whether nodes share banlisted peers when they perform a Levin handshake. 17:25:16 @boog900:monero.social: It's obvious when it's being monitored daily 😇 17:25:26 can someone make a fresh list for the DNS ban list that fits into DNS? 17:26:42 https://github.com/Boog900/monero-ban-list/pull/10 17:26:50 selsta: I suggested it here a while ago, but now the ranges should be changed to reflect the new spy ranges: https://github.com/monero-project/meta/issues/1242 17:26:59 @boog900: That's the update to my list 17:27:56 Maybe we invest in a compact binary format for specifying the DNS ban list? 17:28:15 Binary ranges ought to work :) 17:28:59 Or require TCP for dns which should already be a thing with the long existing dns checkpoints 17:29:53 @rucknium: We could drop the old spy node ranges, which should free up a lot of space, but it would be a sneaky trick if they switched back. I guess it's faster to update a DNS record than to re-acquire a block of IPs for hosting. 17:29:59 More honest nodes are using the DNS ban list than the MRL ban list. 55 percent versus 8 percent. Changing the DNS ban list could have a big effect. 17:30:07 ok, once https://github.com/Boog900/monero-ban-list/pull/10 is merged I'll ask mooo to update the DNS list, at least as many as fit 17:30:46 if they switch back we can update it again 17:30:54 @rucknium: So you're saying add it to the FCMP++ hard fork....... 17:31:28 There's automatic range merging plus a binary format for this would help sizes. What are the current sizes and intended target? 17:31:31 Anyway, node operators should continue to be encouraged to update to the latest version of monerod, which has the subnet deduplication countermeasure against this type of adversary. 17:33:14 Subnet deduplication PR by @rbrunner7:monero.social , reviewed by @jeffro256:monero.social , @vtnerd:monero.social , and myself: https://github.com/monero-project/monero/pull/9939 17:33:23 More on spy nodes at this time? 17:34:14 5. New papers: Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. (https://moneroresearch.info/293) & Venturi, A., Jerico-Yoldi, I., Zola, F., & Orduna, R. (2025). ART: A Graph-based Framework for Investigating Illicit Activity in Monero via Address-Ring-Transaction Structures. (https://moneroresearch.info/292) 17:34:37 There are two new papers about Monero. I read both of them. 17:35:20 I liked the Qubic paper. I don't agree with every methodological decision, but they did a good job in a short period of time IMHO. 17:36:09 It concludes that Qubic did not achieve a 51% attack and Qubic's block-orphaning strategy was usually less profitable than if they had just mined honestly. 17:36:27 They used on-chain data plus tasks form Qubic. They lacked a lot of data but still aggregated them consistent to what we also found with larger set of data and internal hashrates 17:36:57 In Section III(A), they seem to say that they assume Qubic's hashpower share is the share of main-chain blocks that they mine. This seems incorrect because it ignores orphaned blocks of honest miners and Qubic and blocks that Qubic never broadcasted to the network. 17:37:05 @datahoarder:monero.social: Do you agree that's what they did? 17:37:56 They still have data on the orphaned blocks that propagated through the network, but they don't use it to compute "effective hashpower" 17:38:01 AFAIK 17:38:02 They did gather a limited selection of orphan blocks. They describe how they gathered the data, one by querying Monero nodes for blocks and historical orphans, and second by polling one of Qubic RPC that gives the current task 17:38:23 The current task includes all possible Qubic block templates, so they can find orphans as well that never get published 17:39:13 > <@rucknium> In Section III(A), they seem to say that they assume Qubic's hashpower share is the share of main-chain blocks that they mine. This seems incorrect because it ignores orphaned blocks of honest miners and Qubic and blocks that Qubic never broadcasted to the network. 17:39:13 If true, then this is the exact same misunderstanding of PoW that the Qubic founder leveraged to claim a "51%" attack, which they later retracted. As you probably know, you don't just need more than 51% of the blocks, you need 51% of the active hashpower, which is not the same thing. 17:39:37 But indeed, they didn't do a similar comparison of hashrates when taking into account missing data. That's the flaw I see, they lacked large sets of data for orphans or actual hashrates. 17:40:07 I did get a different understanding of that section, I'll re-read. 17:40:08 That is a pretty big mistake for a researcher to make when selfish mining is the main topic of the paper IMO. 17:41:10 Yeah, that would be a major criticism as well. That's a root base that they use for assumptions later on so if that's flawed, the simulations may be too 17:41:49 > Figure 1 shows Qubic’s mining power share in the Monero network, computed as the ratio of Qubic-attributed blocks to all main-chain blocks over weekly, daily, and hour windows. Since direct telemetry of the pool’s physical hashrate is unavailable, we rely on this ‘effective hashrate’ realized on-chain as the primary metric (α) for our selfish mining models. 17:41:59 ^ That's the passage I'm interpreting 17:42:25 Their estimates found a lower efficiency than observed in the real world. This may be due to that flawed assumption (our quick checks using more complete data of orphans on both sides showed -20 to -12% efficiency loss) 17:43:01 @rucknium: Aha! They later touch on it if I remember correctly, that they may have underestimated hashrate 17:43:13 Eek, yeah if you take their word in that passage Rucknium quoted, then they messed up that calculation. 17:43:16 Or maybe "Qubic-attributed" blocks also means Qubic's orphaned blocks. But then it doesn't make sense to not include the honest miners' orphaned blocks. 17:43:51 That's why they have a whole section on the observed values not matching simulations. The actual state machine for the simulation is pretty accurate to observed behavior otherwise 17:44:36 I note that they use the original Eyal & Sirer (2013) theoretical selfish mining behavior. 17:44:50 Later papers showed that the selfish mining behavior proposed by Eyal & Sirer (2013) was not optimal. Selfish miners could get a little more revenue by following a more complex decision rule. You find the decision rule by setting up Markov Decision Process (MDP) analysis. In MDP, you define the objective (i.e. maximize self mi [... too long, see https://mrelay.p2pool.observer/e/2t7zltEKNFhZUl9F ] 17:45:03 I wonder if Qubic had many of their blocks orphaned in practice. If I had to guess, it's probably not big enough to be important 17:45:07 The Eyal & Sirer (2013) strategy instructs the selfish miner to broadcast its block if its chain is one block ahead of the honest chain. But often Qubic would broadcast when it was two blocks ahead. The two-blocks-ahead strategy is less profitable, but less risky if Qubic's block propagation is slow. 17:45:43 @datahoarder:monero.social: Do you have something to say about @jeffro256:monero.social 's guess? 17:46:30 @jeffro256: They did, specially around the threshold levels 17:47:13 I have the dumps I published every week until they stopped selfish but they had quite many in the list that can be proven 17:47:15 @jeffro256: TBC, by orphaned, I mean Qubic's blocks which made it on the main chain of most other nodes, but then were beat out. I'm not talking about blocks in side chains which Qubic decided to abandon before they were longer than main 17:47:36 Aha. Most of those are 1-2 deep only 17:47:57 I am parsing the event logs so I'll have more info on this later 17:48:09 @jeffro256:monero.social: They plot Qubic's orphaned blocks in Fig. 1 on page 3. 17:48:36 @datahoarder: Are these dump from Qubic mining pool or from your node? 17:49:11 It's a dump of the equivalent of their inner stratum tasks and solutions - with 600M difficulty granularity 17:49:37 Events logged to the millisecond across several networks PoV and across Monero nodes 17:50:16 (And other data, Tari blocks, task server they had, it's ~800 GiB of compressed event logs) 17:51:11 I noticed the spy nodes stopped to try to connect to my node on the 6 of this month. 17:51:11 Adding the new IPs everywhere. 17:51:23 https://mrelay.p2pool.observer/m/xmr.mx/uXaEUNvsxSEQSiBksYMvRZHy.png (clipboard.png) 17:52:10 What I'm trying to do now is 1) Fit tevador's "Share or Perish" (https://github.com/monero-project/research-lab/issues/146) suggestion into MDP and 2) Develop an alternative MDP objective that maximizes disruption instead of maximizes the adversary's revenue. 17:52:22 Qubic wasn't trying to maximize revenue. They were interested in the propaganda value of disruption, IMHO. So we want to know how the proposed countermeasures would inhibit disruptive mining instead of just selfish mining. 17:52:39 If you want specific pre-parsed data around Qubic I have an aggregate list, though not posted publicly (it's incomplete, pending parsing of full logs which I can't do live, we are still gathering data). If you want this incomplete list, DM me 17:54:07 I will probably make my Monerotopia Conference talk in February about Qubic and selfish/disruptive mining. Possibly with some collaboration. 17:54:10 @rucknium: Indeed. There's entities extracting maximum value and entities extracting maximum damage or marketing 17:56:06 What about the other paper if there isn't more on Qubic? 17:56:23 The other paper is Venturi, A., Jerico-Yoldi, I., Zola, F., & Orduna, R. (2025). ART: A Graph-based Framework for Investigating Illicit Activity in Monero via Address-Ring-Transaction Structures. (https://moneroresearch.info/292) 17:57:23 I didn't really like this paper. It fit a machine learning model on 19 transactions from 2017 and tried to validate detection of behavioral traits in txs. 17:57:59 In 2017, Monero didn't even require a fixed ring size, so they could use ring size as a predictor. 17:58:39 IMHO, training ML on RingCT Monero txs is a dead end because you cannot get a valid training set. 17:58:43 There was a minimum ring size 17:59:40 Even if you have info from centralized exchanges, those txs are obviously a biased sample that would not reflect general user behavior outside of interaction with a centralized exchange. 18:00:26 Yes, minimum ring size in 2017, but AFAIK, users could select higher than the minimum if desired. 18:01:37 Yes they could. I used a much higher ring size in 2018 to extract the Monero Original safely. 18:01:54 A minimum of two ring members causes decoy elimination cascading attacks. Was that the limit enforced in 2017, or was that already known by then and the minimum greater than 2? 18:02:41 The minimu as I recall was 5 18:03:24 These two papers brings the count to 10 of Monero papers written by non-MRL affiliated researchers in 2025. Nice to have the auxiliary platoon of external researchers 😎 18:03:28 The other 8 are 18:03:35 Thakore, V., & Vijayakumaran, S. (2025). MProve-Nova: A Privacy-Preserving Proof of Reserves Protocol for Monero. Proceedings on Privacy Enhancing Technologies, 2025(2), 582–606. (https://moneroresearch.info/266) 18:03:41 Yang, X., Xu, L., & Zhu, L. (2025). De-anonymizing Monero: A Maximum Weighted Matching-Based Approach. IEEE Transactions on Information Forensics and Security. (https://moneroresearch.info/260) 18:03:46 I used like 255 to ensure common rinngs on both chains greater than 5 for the Monero Original extration 18:03:55 Lee, J., Choi, G., Han, J., & Park, J. (2025). Advanced Monero wallet forensics: Demystifying off-chain artifacts to trace privacy-preserving cryptocurrency transactions. Forensic Science International: Digital Investigation, 54, 301988. (https://moneroresearch.info/290) 18:03:56 According to the README, there was already of minimum of 3 by 2016, which got increased to 5 in 2017. 18:03:58 Kopyciok, Y., Victor, F., & Schmid, S. (2025). Moneros Decentralized P2P Exchanges: Functionality, Adoption, and Privacy Risks. (https://moneroresearch.info/270) 18:04:04 Kopyciok, Y., Schmid, S., & Victor, F. (2025). Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. (https://moneroresearch.info/280) 18:04:11 Shi, R., Peng, Z., Lan, L., Ge, Y., Liu, P., & Wang, Q., et al. 2025, February 24–28, Eclipse Attacks on Monero’s Peer-to-Peer Network. Unpublished paper presented at Network and Distributed System Security (NDSS) Symposium 2025. (https://moneroresearch.info/248) 18:04:18 25* 18:04:21 Gao, Y., Zhang, Y., Piškorec, M., & Tessone, C. J. (2025). Monero Peer-to-peer Network Topology Analysis. (https://moneroresearch.info/278) 18:04:26 Gao, Y., Piškorec, M., Zhang, Y., Vallarano, N., & Tessone, C. J. (2025). Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network. (https://moneroresearch.info/267) 18:04:59 More discussion on these papers? 18:05:44 They also moved the tor/i2p spy nodes too 18:06:04 Does the BulletCT paper count? ;) 18:06:19 @ravfx:xmr.mx: These were the spy nodes spying on the i2p and tor networks in general, right? 18:07:54 Then, 11 😀 Wang, N., Wang, Q., Liu, D., Esgin, M. F., & Abuadbba, A. (2025). BulletCT: Towards More Scalable Ring Confidential Transactions With Transparent Setup. https://moneroresearch.info/285 18:08:29 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). 18:09:25 I have spent some time reviewing the various proposals. In particular @boog900 18:10:57 the laater would make a good choice for a mature chain over 1000 transactions per second. If one tries to modify it then the maximum annual growth rate grows over 2.5%. 18:11:05 @rucknium: yeah, but they have a big collection of them at LIONLINK 18:11:12 had* 18:13:06 This issue is that we need the ability of ML to change in order to accommodate the variability in transaction rates that has been identified in the past both in Monero and other chains including over 100x in Bitcoin and Litecoin 18:13:40 I think my proposal is too aggressive if anything, but it is an improvement over what we have currently. 18:13:49 Then we hate the issue of too high an annual growth rate. 18:14:14 @boog900:monero.social: Can you post the link? 18:14:25 My take is that my proposal with the Nielsen's Law caop is the way to go 18:14:46 https://github.com/seraphis-migration/monero/issues/44#issuecomment-3617687600 18:14:50 We are capping the annula growth rate to below 1.389 x 18:15:10 There is also no need for fixed caps 18:15:41 and we have a predictable max block weight with time. 18:15:59 Like ~7 years to reach 100 MB for example 18:16:43 1024x max growth in a year is completely unnecessary 18:17:14 47x is too but it is much better 18:17:31 There is no max growth of 1000x in a year 18:17:36 Personally I'd consider a 100x capacity change in the short term to be unimportant. Without it, worst case fees go up in the short term. I don't consider this a failure. I don't see short term higher fees as a devastating failure of the goal of p2p cash 18:17:59 ArticMine: 16x in short term 2x every ltm adjustment 18:18:24 I ran a bitcoin node in 2017 - 2018. Over 2 TB of data in a month 18:18:46 Bitcoin stly fee markes can be easily spammed 18:19:01 that was over a 50 Mbits DSL line 18:19:35 @boog900 You have the cap at 1.390 .. 18:19:41 That is the key change 18:19:45 @articmine:monero.social: has said mine is good for a mature network, I believe my proposal also allows us to reach a mature level (according to artic) in a reasonable amount of time 18:19:57 I SAID MAX GROWTH. 18:20:09 I know max growth 18:20:16 is way faster 18:20:33 but are people prepard to accept this with no caop? 18:20:44 Or conntroversial fied limits? 18:20:46 Max growth in a single year makes the sanity cap meaningless as eventually it grows enough to not restrict a years worth of growth 18:21:41 If that is the case then the market is taking care of things 18:22:02 This is not a case to argue against the underlaying scaling 18:22:17 why do we need to plan for no growth for 14 years then gigabyte blocks in 1 year? 18:22:19 And I mean ovr a decade of more 18:22:45 ArticMine: it is as otherwise we are just relying on the sanity cap to keep us secure 18:22:51 We are not planning for no growth for 17 years 18:23:01 another bandaid solution, just like the ones that got monerod in the state it is 18:23:08 we can have 1000 tpd in 14 years 18:23:17 tps 18:23:30 we do not need 1024x in a single year 18:23:31 This is far from no growth 18:24:04 I think @boog900:monero.social raises good arguments against exponential cap, in favor of more reasonable allowed max growth params 18:24:07 we can have a gradual increase if you believe we wont have all the growth in 1 year 18:24:55 Even if we allow, say, 2x growth per year max, that will still catch up to the sanity cap over time 18:25:05 We have an under 1.4x per cap How many time do I have to repeat this? 18:25:21 brooooo 18:25:23 Why not both? I thought that the exponential cap was an additional sanity check on the long term medium, which itself is limited by the historical block sizes. 18:25:48 That is what it is 18:26:00 It's not like the block size is allowed to immediately jump up to sanity cap 18:26:07 my proposal has that as optional @jeffro256:monero.social, I don't think it is needed with it though 18:26:13 Both are integrated into my proposal 18:26:20 the underlying scaling is slow enough without it IMO 18:27:16 So why does it hurt, in your eyes? Just extra unnecessary complexity? 18:27:17 2.5x is greater compunded than 1.4x 18:27:29 @jeffro256: yes 18:27:40 ArticMine: 2.5x is literally maxing out scaling 18:27:58 1.4x is always increasing, no matter what 18:27:59 It is actually too high over time 18:28:07 I agree 18:28:19 ^ > <@boog900> I think my proposal is too aggressive if anything, but it is an improvement over what we have currently. 18:28:25 TBF, if implementeting the sanity cap as a function of the block height, it could be extremely helpful as a quick stateless pre-check 18:28:26 Then what is the problem with under 1.4x? 18:28:32 we can lower it? 18:28:54 ArticMine: BECAUSE IT INCREASES NO MATTER WHAT 18:29:05