15:09:16 MRL meeting in this room in two hours. 17:00:40 Meeting time! https://github.com/monero-project/meta/issues/1303 17:00:44 1. Greetings 17:01:10 Hi 17:01:29 hi 17:01:42 waves 17:02:04

Hi 17:02:13 Hi 17:03:04 Hi 17:04:09 2. Updates. What is everyone working on? 17:05:45 me: Investigating medium- and long-term selfish mining countermeasures again. Looking at FCMP hard fork scaling parameters. 17:07:06 me: spinning up my scrap heap for fcmp stressnet testing. Hit a wall with monerosim re: mining shim, going to revert back to less perfect block controller 17:07:26 wrote the ccs proposal "Bulletstar", renamed in Bulletproofs* 17:07:40 me: FCMP++ alpha stressnet I shared a custom build that includes changes slated for v1.5 alpha stressnet to address OOM's, received a couple reports from people using that build I want to continue investigating (new sync issues), planning to put out a new CCS proposal soon 17:08:11 Continuing i2p bounty work, and personal research into more radical/general scalability paths. 17:08:23 me: squashing a few things (bugs) in lws, adding a get_info (get_version) endpoint to lws, and working on lwsf lookahead (still a slight mess) 17:09:28 (removed) 17:09:28 (removed) 17:09:28 (removed) 17:09:28 (removed) 17:09:29 (removed) 17:10:41 redacted 17:10:46 (minimum power level to send messages here temporarily raised to 10) 17:11:53 (Ping me in #monero-research-lounge:monero.social if you need your power level raised.) 17:12:02 3. BulletStar (more efficient membership and range proofs) (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626). 17:13:28 Here I am, I'm the author of this CCS, thank you for this space 17:13:45 @emsczkp:matrix.org: Thanks for joining the meeting. 17:14:04 Hi 17:15:07 @emsczkp:matrix.org: Would the proposed changes to the FCMP cryptography require a hard fork? 17:15:50

@emsczkp:matrix.org: How does bulketproof* compare to your previous work on constant time range proofs? 17:15:50

https://moneroresearch.info/178 17:15:57 Do most of the efficiency gains occur with multi-input txs? How much benefit would single-input txs see? 17:21:17 @rucknium: No, the proposal is an improvement to the zkp proofs mechanisms behind FCMP 17:21:43 @ack-j:matrix.org: this is related to the question of if the Halo's modified IPA is compatible with that of BP in order to do accumulation, and the answer is no ... this research was trying to explore that direction 17:22:12

s/time/size/ 17:22:15 So the planned FCMP hard fork could occur, then BulletStar added afterward without a hard fork? 17:24:19 Thank you for making the proposal 17:24:57 i.e. no modifications to the membership proof and range proofs used in FCMP++ txs would be needed, and the folding scheme would simply fold the existing proofs? 17:27:56 @rucknium: there is an asymptotic gain with folding as long as your computations grow, in single-input txs you should not see that 17:29:54 @jberman: We have to operate inside the underlying GBP proof and I would expect some modifications 17:30:43 According to my calculations (2019-2024), 54 percent of txs are single-input: https://gist.github.com/Rucknium/d2c02f51a2d9f103a28caa8f51be7dbf/ 17:31:59 Interesting to see than only around 7% have more than 2 17:34:22 as I understand it, a folding scheme would enable accumulating many single-input txs into a single proof. So it's not as though there would be no benefits for single-input txs in aggregate IIUC 17:35:11 I think @emsczkp:matrix.org was saying that standalone multi-input txs could benefit from a folding scheme too (if you're verifying a single 128-input proof e.g.) 17:35:23 is that accurate? 17:39:39 yes @jberman, thank you for clarification. Multiple single-input txs can be aggregated and with folding we may enable an efficient proof batching 17:40:43 Howdy. Sorry I'm late. I'm working on organizing an audit for the carrot_core library and trying to pin down a draft for a potential PQ turnstile design 17:40:45 basically this would complete this issue: https://github.com/monero-project/research-lab/issues/110 17:41:54 @emsczkp:matrix.org: although slightly different in that we may not be able to accumualte the existing proofs 17:42:07 How would this work in practice? Users send txs to miners and the miners create an aggregated proof, then post the aggregated proof to the blockchain and throw away the individual proofs? 17:43:34 not being able to accumulate the existing FCMP++ proofs is ok imo, this research direction is imo a critical avenue for a more scalable protocol nonetheless 17:45:32 Will this be quantum-resistant? 17:46:15 @rucknium: IIUC sounds like something like that would be possible. I imagine there would still likely be some archive nodes saving all individual proofs like @kayabanerve:matrix.org mentioned in that issue 17:46:50 @rucknium: You couldn't discard individual proofs w/o a hard fork, but perhaps a new node could skip downloading those individual proofs and just download/verify the aggregate proof 17:47:02 @jberman: pruned txs by default :), full node vs archival node time? 17:47:20 New nodes could do full chain verification without the individual proofs, right? Otherwise, it's not much better than simple pruning like we already have. 17:48:27 @rucknium: no, the folding security will rely on the underlying standard assumptions of GBP. But there are interesting research proposal moving towards PQ safe folding 17:49:46 @kayabanerve:matrix.org suggested a moratorium on Monero cryptography research that is not quantum resistant. I don't necessarily share that view, but he did suggest that. 17:51:59 I tend to prioritize PQ safe as well 17:52:25 I think it would be a nice added bonus to consider PQ in this proposal 17:53:04 But considering this is an independent researcher aiming to take ownership of this specific research direction in parallel, I don't think it would make a lot of sense to block it 17:53:23 What would be the implications of shifting to PQ in terms of difficulty/clarity of implementation? I wouldn't want PQ to derail the whole thing 17:54:33 Yeah I definitely don't want to block it. It is a reasonable enough direction as-is. But practically, PQ safe is more important than efficiency with the existing assumptions, imho 17:55:13 @preland: First you need a PQ safe GBP, then if you want folding is another question. From my knowledge there is only one proposal doing recursive proofs in PQ settings 17:57:31 We need to move on to the next agenda item. Any more quick comments or questions for now? It will come back as an agenda item next week. 17:58:27 I'm a strong +1, grateful for the submission @emsczkp:matrix.org ! 17:58:36 @emsczkp:matrix.org: IMHO, it would be good to add to the proposal a description in even simpler language of the likely benefits for Monero. 17:59:40 ok, thank you 17:59:51 Thank you very much for your work on this, @emsczkp:matrix.org 18:00:26 I had to raise your power level, @hooftly:matrix.org . 18:00:32 We had spam earlier. 18:00:34 thank you again, see you next week 18:01:03 4. P2Pool consolidation fees after FCMP hard fork. Coinbase Consolidation Tx Type (https://github.com/monero-project/research-lab/issues/108). 18:01:22 Ah I figured something happend 18:01:41 Any more discussion on P2Pool coinbase output consolidation for now? 18:01:44 No updates from last week. I need to start making a flow diagram to present here. 18:02:10 Thanks. 18:02:27 5. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-11.pdf). Revisit FCMP++ transaction weight function (https://github.com/seraphis-migration/monero/issues/44). 18:02:28 However, it'd depend on 1-in zero fee txs (in-pool) with fallback normal txs (with fees) for no multisig agreement. I think this topic can sit on the sidelines until above flow is ready. 18:04:00 Let me ask if "delayed" fast scaling would be acceptable. Slow scaling parameters in effect for let's say 2 years after the hard fork, then the fast-scaling parameters in effect after that. 18:04:16 I am going to cut to the chase here 18:04:38 This would provoide time to make the node code more efficient and some more technological progress in storage and CPUs 18:05:25 What I see is that stressnet has uncovered serious vulnerabilities that requires time and resources to fix 18:06:05 Many of the devs feel overwhelmed by the task at hand. 18:06:18 @rucknium: akin to ethereum's difficulty bomb, other way around? and worst case - the fast scaling can be soft forked if the code is not ready 18:06:52 Fast scaling cannot be soft forked 18:06:53 I see where you're headed with this @articmine:monero.social , false statements so far 18:07:20 What false statements 18:07:47 @articmine: I think @datahoarder:monero.social is saying that with the "delayed" scaling, you can soft fork away the fast scaling before it takes effect 18:07:53 @articmine: No one feels overwhelmed for starters. We are making progress 18:07:54 @articmine: I mean "limited", not added in. If fast scaling is seen as still bad then, it can be "patched" 18:08:31 @jberman: I know you are 18:08:55 But are the timelines reasonable? 18:09:19 What timelines? The prior timeline estimates? 18:09:41 @articmine: To make sure we are all on the same page, what is the current timeline, as I've heard it thrown around a ton, but nothing from core or anyone in the know 18:10:25 IMHO, the poor performance of the node was already revealed during last year's mainnet spam and the first stressnet last year. It is only now that more dev effort has been applied to the problems. 18:11:02 My point is that when is being proposed is to throttle scaling in an attempt to mitigate code vulnerabilities 18:11:04 It's been a while since (IMO since the divisors kink) we've had a real aligning about timelines 18:12:46 I think the last estimate I heard was Q1 '26, which seems too early 18:12:53 @articmine: Ack, heard on this point 18:12:54 How important is it to discuss timelines now? 18:13:44 I want to get a code audit for the carrot_core lib ASAP. FCMP++ Rust code already has most of the reviews it needs AFAIK. Then I think the FCMP++ integration code on the daemon side would be worth auditing. That can be done in parallel of carrot_core. We could modify hard fork table then? 18:14:05 Then HF activation is 6 months after that release 18:14:34 @jeffro256:monero.social let me know if you want help for the carrot_core audit(s) 18:14:43 dont we hard fork testnet first, potentially stagenet as well to give some time for ecosystem to update 18:15:17 arbitrary, but i dont think it has to be 6 months in advance 18:15:29 Yeah, that's fair. Testnet and stagenet don't need a 6month lead time tho 18:15:45 I mean if my proposal with a 500000 byte minimum penalty free zone is not enough to address the vulnerability concerns then we have some very serious issues that have nothing to with scaling 18:16:21 personally I'd like to complete the alpha stressnet (reach a point where alpha stressnet is running smooth under reasonable conditions), ideally within the next 4 weeks. and then reopen a conversation on target dates 18:17:22 That's fair, and can also be done in parallel to integration / crypto audits 18:17:32 Even with node code with zero inefficient "overhead", the proposed FCMP allowed block sizes would stress hardware. With 16MB blocks, which are allowed with quick scaling in @articmine:monero.social 's proposal AFAIK, you can get 2466 1in/2out txs into a block, which would require 93 seconds on a single thread to verify. Accord [... too long, see https://mrelay.p2pool.observer/e/v7eH18wKbFd4dkxM ] 18:17:47 AFAICT, the remaining changes to be made to the stressnet wouldn't involve much FCMP++/Carrot crypto-specific changes 18:18:04 If an adversary tries to pack blocks, they can slow down verification further by selecting slow tx types. 18:18:13 aside from the dropping connections, i think its running pretty well. Would like to see how mobile wallets fare with the tx volume. Dont want a zcash situation where wallets cant keep up 18:18:24 @rucknium: that proposal doesn't limit to 16mb blocks 18:18:30 I'm more concerned with the max block sizes (and permitted growth) than the initial penalty free zone 18:19:10 @ofrnxmr: Wallets really shouldn't be affected much if you assume daemons are working okay since they deal in pruned transactions, not full transactions 18:19:53 also saw last week, that a 128-in FCMP++ input is already larger than the block weight at minimum, which prevents these from being included unless block is grown (I guess if they pay more fees it could be worth it?) 18:20:12 DataHoarder: I think this is due to incorrrecrly reported weight 18:20:23 Then use the current scaling parameters with a 500000 byte penalty free zone and see what you get. 18:20:23 It is far easier to test the stressnet with the current parameters than with my proposal that delays the scaling by over 2 months 18:20:25 tx reports 132kb, but weight 700kb 18:20:56 yeah, then we have "Revisit FCMP++ transaction weight function" as part of this topic :) (which afaik agreement was byte size = weight?) 18:21:00 feel free to correct this math @articmine:monero.social, but if I'm calculating correctly the latest proposal allows blocks to grow to 611mb within 1 year 1000*(2^(365/100,000/720/2) 18:21:02 @sgp_: The lot term has va very negative impact on blockchain surveillance 18:21:16 Long term 18:21:25 I understand that. 18:21:51 This is a totally different and very serious issue 18:22:29 @ofrnxmr: block size is limited by tx weight, not tx byte size. So it would be limited under the current stressnet weight rules, but that is being changed for the next iteration of the stressnet 18:22:35 My proposal can destroy blockchain surveillance 18:22:54 https://github.com/seraphis-migration/monero/pull/232 18:23:15 Under this PR, its weight is approximately equal to its byte size 18:23:29 @jeffro256: Right, when i say incorrectly reported weight, i mean that the "weight roughly = to byte size" isnt in yet 18:23:31 @jberman: @jberman:monero.social: Is it 16MB blocks in the short term (100,000 blocks median)? 18:23:32 @articmine: 611mb blocks would destroy Monero 18:23:55 @jberman: 100.01mb blocks would destroy monero :P 18:23:56 How? 18:24:05 @ofrnxmr: lol 18:24:46 @articmine: you would need a data center to run a full node 18:24:55 @articmine: Nodes would not be able to sync / propagate faster than blocks are created. Storage requirements may become infeasible for particpants 18:25:39 @jeffro256: "storage is free" 18:25:39 yeah, 611mb blocks would be an issue imo 18:25:51 even storage r/w speeds would be crippled by receiving a 600mb block 18:25:55 I think we should join together and submit a counterproposal. It's fine my initial idea isn't getting traction, but we should have another actual option that's considered good by multiple people instead of talking in circles on this one imho 18:26:26 @sgp_: I will be blunt. Conflict of interest 18:27:00 What is the conflict of interest of discussing new scaling ideas? 18:27:32 @sgp_:monero.social: I don't know why you decided to start a blockchain surveillance firm. Baffling decision that will follow you forever. 18:28:03 https://www.naxo.com/faqs 18:28:26 @rucknium: have to second this lol; fireice_uk keeps giving me grief in the buttcoin discord server because of it xD 18:28:42 Blockchain survelliance simple does ntot scale 18:29:15 I think there is some general agreement short-term / medium-term larger blocks is ok, and general agreement besides @articmine:monero.social that consensus allowing blocks in the hundreds of mb's within 1 year is not (ignoring the 100mb serialization limit) 18:29:31 packet size limit* 18:29:32 It is at least apparent conflict of interest as defined by the government of canada 18:30:11 unless other people think blocks in the hundreds of mb's is ok? 18:30:15 ArticMine: We cant attract users by promising privacy if we get enough users. 18:30:26 This is totaly separate from the issue of whethre Monero can handel certain trasnaction rates 18:30:51 Why not just used one of the many other coins and just try get their coin more users 18:30:52 @jberman: I'd say this is a fair summary, though if anyone disagrees they should state it, because as it stands it'll be hard for anyone in the future to look back at this and come to a better conclusion 18:31:27 I havr a 1tb data limit on my vps and my home network 18:33:26 We need t make the necessary changes to allow Monero to be used 18:33:45 Is there a workable compromise to have hard fork scaling rules to allow fast scaling, but soft-fork rules has slow scaling? So the soft fork can be lifted or relaxed when it makes sense to do so? 18:34:17 If a 100x increase in usage breaks Monero we have some very serious problems 18:34:29 Removing soft fork rules is a HF AFAIK 18:34:53 @boog900: I have to agree with this 18:34:59 @rucknium: it can be a continuous function (up to some sanity limits) that can be slowed/stopped via soft fork, but that way it's always "improving" faster at a defined rate, not specifically linear 18:35:07 Why would that be true? Miners just agree "after this block, the rules are relaxed"? 18:35:27 @rucknium: some miners will reject the blocks 18:35:28 @rucknium: someone could have not upgraded. suddenly, chain split 18:35:35 Some nodes* 18:35:36 In Bitcoin they tried this and it failed in 2013 18:35:38 @rucknium: I like this idea on a basic level; the hardfork adds the switch, and soft forks are used to turn it from one to the other, though I agree that it isn't without critique 18:35:39 A soft fork is making rules tighter hard fork is making them looser 18:35:45 you can always make things stricter, not broader, with softforks. 18:36:16 @boog900: It can work. We have to be very careful 18:37:42 I must say that I am glad my hard line on scaling is exposing some serious problems 18:38:17 IIRC, Bitcoin Unlimited has this idea to let the bitcoin block size be unlimited, but allow miners to agree on a (short-term) limit. And miners would want that since propagation delays would increase their blocks' risk of being orphaned. 18:38:34 If we assume that we must hard fork in the future for either A) PQ crypto, or B) recursive ZK proofs, C) out-of-band proving (e.g. sheilded CSV), D) plain old FCMP efficiency improvements, or E) something else, we will have another opportunity in the future to adjust scaling parameters in the scaling-maximization direction kno [... too long, see https://mrelay.p2pool.observer/e/xrfU18wKaVY2X3ZL ] 18:40:05 I'm not convinved that increasing scaling parameters is do or not right now when there are popular proposals for much more radical changes in the future 18:40:06 @jeffro256: that ossification/untenable part is maybe why having a future date where it becomes enabled by default (unless something is done) might work to get things moving 18:40:59 Yeah, I don't dislike that idea 18:41:21 the difficulty bomb 2 18:41:59 @boog900: "past us build a bomb so we don't procrastinate now" 18:42:28 I'm not a proponent of disparate scaling algos / a future bomb 18:42:52 Here is info on the Bitcoin Unlimited Excessive Block Size config parameter: https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4 18:42:59 I mean a soft fork cap on the block size cout be overridden by a 51% of the hashrate 18:43:14 yeah, maybe difficulty bomb is a bad example, but something reasonable that all agree on ~2 years or whatever is set (and is not catastrophic) 18:43:29 @rucknium: I think the fluffy block fix, fixes the broadcast delay 18:43:34 @articmine: Not really, unless you want 49% of the Monero ecosystem to split 18:43:49 The problem is that the proposal allows catastrophic things. That's the core problem 18:43:54 yeah I would be ok with a future block size bomb, although I see most likely outcome that it is just delayed and we stick with the more security focused scaling algo 18:44:04 @ofrnxmr: with large tx pools that are segregated (not everyone has all txs) you still end up with large transfer of txs to get blocks accepted 18:44:21 (I have to step away in 7 mins unfortunately) 18:44:27 In reality, even with a soft fork, you need a supermajority to not cause catastrophic damage to the economy built around your network. You want opposing the soft fork to be so disastrous that no one does it 18:45:00 But what if you're qubic and want to do it for fun? 18:45:08 With all due respect the danger of ossification is real 18:45:11 @ofrnxmr: beat me to it lol 18:45:34 @jeffro256: reverse block size scaling? where blocks become smaller until it's catastrophic even without 100x growth 18:45:35 Remember what Satoshi said in 2010 18:46:19 I mean we can leave the parameters as they are 18:46:45 I think you are the only one that thinks current scaling is anywhere close to safe 18:47:33 @boog900: Is this true? Anyone want to say that current scaling is anywhere close to safe? 18:47:49 @rucknium: Define safe in this context 18:47:58 @ofrnxmr: the only reason qubic didn't do it with their tx spamming on the side was they had their own dumb technical limitation to 896 byte block header size, so they could only attach like ~20 txs per block tops 18:48:08 I like the current scaling TBF 18:48:22 @preland: allows us to react fast enough to someone producing max size blocks to prevent nodes falling out of consensus 18:48:27 @preland:monero.social: You can define it as you like. Qualify your statement. 18:48:37 @jeffro256: Getting to 40mb in under 48hrs? Without max fees? 18:49:14