15:14:19 MRL meeting in this room in about two hours. 17:00:17 Meeting time! https://github.com/monero-project/meta/issues/1307 17:00:36 1. Greetings 17:00:49 Hello 17:01:00 Hi 17:01:00 Hi 17:01:09 Hi 17:01:15 👋 17:02:03 waves 17:02:42 2. Updates. What is everyone working on? 17:04:17 me: Starting to use Markov Decision Process to analyze selfish mining countermeasures. 17:04:19 me: completed subaddress lookahead in lwsf, just needs a few tests. otherwise been tracking down bug reports in lws, several of which have been solved 17:05:09 stressnet, identified a cause of disconnected stressnet nodes when the pool exceeds max weight and submitted a PR for it (this was a bug in the fcmp++ integration code, not an existing issue), continuing to v1.5 stressnet release 17:05:30 me: refining the BP* CCS proposal to introduce potential application scenarios in Monero with the help of @kayabanerve:matrix.org 17:06:31 Hi 17:06:43 Sorry I am late 17:07:51 me: making adaptive blocksize simulation websites, gearing up to get working on monerosim again 17:08:23 I have updated my scaling proposal by incorporating Tevador's concept as a sanity cap 17:08:49 3. Bulletproofs* (more efficient membership and range proofs) (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626). 17:09:31 Hi and thank you for this time slot 17:09:41 I liked "BulletStar" more :) 17:09:41 Bulletproofs* will be harder to search for in a search engine. 17:10:23 Discussing with @kayabanerve we've identified several application scenarios for folding in Monero, including (but not limited to) the following: 17:10:23 “Chain proving”. Suppose Alice and Bob each include their own membership proof in a single transaction without revealing their witnesses to each other: Alice creates her proof, passes it to Bob, and Bob adds his proof on top. In this case, we aggregate single-input transactions into one many-input transaction and create a single folded proof. 17:10:23 “Stream proving”. This would enable zkRollups, where many statements are collected across transactions and a folded proof is generated for a batch of transactions. 17:10:23 “Transaction uniformity”. In this scenario, all transactions have a fixed number of inputs and outputs so that all transactions look the same, improving privacy. We currently lack such a feature because larger transactions are too expensive for it to be worth the benefit to privacy. Cheaper standalone multi-input transactions through folding would address this issue. 17:10:23 [... more lines follow, see https://mrelay.p2pool.observer/e/ob7D9c4KUm5QR0Qy ] 17:12:23 Any prediction of the computational cost of these applications? 17:12:35 There may be a case to defer FCMP++ until we obtain these proofs 17:12:52 No there is no such case 17:13:11 Especially given the concerns over the state of the code 17:13:12 these are optimizations right? 17:14:08 Ones requiring hard forks, such as MLSAG -> CLSAG. 17:16:38 That design goal sounds like it would apply to all 3 of those applications ya? 17:17:19 @rucknium: the most promising benefits in terms of computational costs is the reduction of memory consumption of membership proofs verification. Theoretically and asymptotically this would reduce to log time 17:17:52 The obvious use-case is within a transaction, across inputs (or even within a single input), assuming the overhead from folding is sufficiently small. 17:17:52 That inherently leads to uniformity being worth the performance hit due to the performance being so improved. 17:18:23 Larger efforts, folding across transactions, are theoretically enabled by this but would require much more work on integration. 17:19:09 (presumably, block builders would need to form a meta-proof, but I did once propose a way for a pool of proofs which anyone could fold onto) 17:19:30 That's my view of it, at least 17:19:46 @jberman: Yes, and I believe independently of the top-level design. 17:22:32 That design goal sounds fine to me. Imo "stream proving" is by far the most useful followed by "tx uniformity" followed by "chain proving". I hear how implementing within a single tx would be much simpler to integrate. I think we can cross that bridge when we get to it though once the foundational research is more firmly established 17:24:20 IMHO, this sounds like a worthy CCS. Good applications and a reasonable budget. 17:26:40 small nit: "stream proving" sounds like it's interactive at time of tx construction, but the goal is to be able to fold already constructed proofs into 1 proof AFAIU i.e. you can separate folder from provers 17:27:28 Not quite, AFAIK, @jberman:monero.social: 17:28:01 In general, folding requires creating the proof on top of prior proofs. Folding proven proofs would require proving a meta-proof and folding that. 17:28:26 (To my understanding, obviously @emsczkp:matrix.org: should be deferred to here for their work) 17:29:16 @jberman: If true, then this wouldn't be a nit, it would be a complete overhaul in the privacy model expected in Monero which turns the privacy battlefield to the network level. I don't think that it would ever be acceptable to require interaction from the folder IMO 17:29:21 While I'm unsure if the results will be applicable, and applicable in a timely fashion given other potential developments (quantum computers), I find the work reasonable and the concept of folding universally relevant to Monero's future. I also find the rate incredibly reason and see no reason we shouldn't be happy to have @emsczkp:matrix.org: working on Monero as a researcher. 17:30:37 Sorry, I responded to the wrong thing. I was thinking of "chain proving". Durr. 17:31:15 i outlined "stream proving" as different case of "chian proving". The first should be done by a separate "folder" that aggregates statements (such as a sequencer in zkRollups) and it may have knowledge of witness. The chain proving does not 17:31:30 For "stream proving", yes, I believe the pitch would be for the block builder to perform the aggregation without a loss in privacy 17:32:13 🤔 I'll be quiet and leave it to @emsczkp:matrix.org: 17:33:31 @kayabanerve:matrix.org: this was my thought as well. My nit is just highlighting how the name "stream proving" sounds like it could require interaction from tx provers. "stream folding" may be better here 17:34:12 or just "rollups" 17:34:51 in any case, I'll reiterate I'm a strong +1 on the proposal too :) 17:36:07 @emsczkp:matrix.org: "Stream proving" may have knowledge of the witness or must have knowledge of the witness to do its job? For the record, I'm supportive of the CCS proposal either way. 17:37:27 I think the next question here is "what's the witness"? Is the witness the opening of the membership proofs, or is the witness the original proofs which were folded into this succinct proof? 17:38:40 Because the folder of proofs into a theoretical meta-proof, across the entire chain, produces a proof whose witness is the original proofs. Therefore, they know the witness to their proof (the meta-proof attesting such proofs originally existed) but there's no loss of privacy. 17:40:17 More discussion on this item? 17:42:07 @rucknium: jeffro and I asked for clarifications on theoretical applicability to folding proofs across transactions, but seems the CCS itself is well-liked :) 17:43:33 4. P2Pool consolidation fees after FCMP hard fork. Coinbase Consolidation Tx Type (https://github.com/monero-project/research-lab/issues/108). 17:43:49 @datahoarder:monero.social: More on this? 17:43:59 Thank you @emsczkp:matrix.org 17:44:12 Nothing currently. 17:44:30 As said last week, working on it and building a schema for it. No updates until then, I'll bring it up once it's ready 17:44:58 @datahoarder:monero.social: Do you want me to take it off the agenda until you say to put it back on? 17:45:26 Maybe a minor update, a different derivation for coinbase outputs is considered internal to P2Pool that would be ephemeral (not need to be proved in a future turnstile) to allow efficient multisig per block ahead of time 17:45:29 @rucknium: Let's do that 17:45:34 @jeffro256: I believe it must as the sequencer has to be also trusted, but i need further invesitagion on the current design of rollups 17:47:31 Regarding the next agenda item: 17:48:07 Others' views on decision making processes are welcome. IMHO, trying to get "loose consensus" in MRL is a good goal, in general for two reasons. And on this specific topic for one practical reason. 17:48:07 1. Compared to majority vote, seeking consensus can help prevent people from being entrenched in their positions. It can encourage creative compromise. 17:48:07 2. Defining a voting body is not easy in MRL. With majority voting, you would have to say who can and cannot vote. 17:48:07 3. ArticMine seems to have a small minority position, but he is in the Monero Core Team. I don't know if Core would approve a Monero node release with a scaling algorithm that ArticMine strongly opposes. 17:49:05 5. 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:49:40 Does this also include my proposal or not yet? 17:49:56 No 17:50:22 It includes Tevador's 17:50:47 @kayabanerve:matrix.org: No. Your proposal is next on the agenda. 17:50:56 @articmine:monero.social: I was asking @rucknium:monero.social: about the agenda item, not about you about your proposal. 17:51:03 I don't agree with coding in exponential growth of the sanity cap with no extra usage. 17:51:07 Thank you for clarifying @rucknium:monero.social: 17:52:09 I think supporters of this proposal owe it to the community to confirm that the daemon can handle a steady stream of 10 to 16 MB blocks. 17:52:10 If supporters can make their case from evidence, are willing to pin their reputations to that claim, and there are not objections from others preventing consensus on the matter, then I have nothing to add. 17:52:53 I agree with @boog900:monero.social: with disliking how the sanity cap may become progressively insane 17:53:39 @emsczkp:matrix.org: this sounds like "stream proving" actually would be the more accurate term in that case, since sounds like there would be some privacy loss if the sequencer is indepedent. I think the design goal of an untrusted sequencer would be ideal, but the applications described would still be useful even if not 17:53:43 fwiw, progress was made by ArticMine adding a ~40% max growth per year cap. This cap increases without any consummate increase in block demand, but there may be more restrictive caps (e.g. the long term median) at any given moment. One dispute seems to be whether scaling should permit "catching up" to this cap with a time peri [... too long, see https://mrelay.p2pool.observer/e/9Z3i9s4KRzFnek1F ] 17:54:04 Polynomial growth instead of exponential? 17:54:06 From discussion in mrlounge, id agree with a kayaba-style "or" condition that limits the to higher of exponential cap vs packet size limit (or serialization limit) 17:54:32 Limits the sanity cap* 17:54:57 Catching up is critical 17:55:28 This is now the essence of the disagreement 17:56:01 I also disagree with the rest of the changes to the scaling that have undergone very little discussion 17:56:05 as you can see ArticMine is in strong favor of it, whereas others (including me; make your voices heard everyone else) prefer not to have this catch-up 17:56:11 Since we cant actually sync blocks > 100mb under any circumstances. 40% would keep us under 100mb for 6 more years. The last hf was 3yrs ago 17:58:42 @boog900: I agree; the increase of the long term median is an example of something that seems unnecessary 17:59:26 @sgp_: This has been discussed at length going back to 2020 17:59:59 but after only weeks and weeks of discussion, we convinced one person that multi-gig blocks within one year is not acceptable. yay 18:00:17 sgp_: By the "increase long term median", do you mean without prior increased chain activity, b/c the median has always had the potential to grow given that the priot median block size has increased 18:00:22 I also find the design to be disagreeable and agree with boog900's perspective. That said, I hold myself to the statements I made above (at the start of this topic). 18:00:25 @sgp_: I knew code rot 18:00:31 I mean the rate, sorry for the confusion 18:00:58 @spackle: from 1.7x -> 2x 18:01:12 Replie to wrong msg 18:01:55 While ignoring that the short term median cap is dropped from 50 to 16 18:02:31 ... and the maximum block weight is dropped from 100 to 16 18:02:32 When I disagreed with the input limit, I acknowledged I was the minority and while I kept my position clear, I understood consensus was for a much higher input limit than I'd personally reasonably support. I understand ArticMine's history not just within the project yet on this specific topic, but given the work on the stressn [... too long, see https://mrelay.p2pool.observer/e/uL2C984KRkhGUmpp ] 18:02:43 I do understand some of this is part of the discussion process, a process ongoing for months, and I'm happy this latest proposal has improved from a wider belief of critically-flawed to solely disagreed-with (after incorporating a design from tevador as a safety mechanism, tevador themselves a voice held in high regard) though. 18:03:14 It _feels to me_ like we're talking down to an agreeable design instead of working out an agreeable design from the start. 18:03:45 (If that's even possible, I understand in a room of such different opinions, there isn't an agreeable starting point) 18:04:06 Then go back to eliminating the long term median entirely 18:04:22 That is in Tevador's concept 18:05:05 The limit is the lower of the LTM and the Sanity Cap 18:05:16 I'm actually in support of some long term sanity cap on the long term median that doesn't require chainstate besides block height, for quicker failures in block handling, given that it is an ADDITIONAL restriction, not a loosening of some other parameter. I think an exponential factor around 1.4 is reasonable and gives us time to cap if further. 18:05:24 Correct 18:06:49 in eli5, isnt this "16mb max short term median, but really capped to 10.8 at current time. Max long term median of 2x 16mb, but really still capped to 10.8mb. So the actual median cant go above 10.8mb" 18:07:17 What is the current proposed rate of change of this long-term cap? (just to be sure i'm not mixing numbers) 18:07:20 The cap starts at 10 18:07:29 @jeffro256: an attack is to submit a block with zero txs but with extremely large miner tx. That after FCMP++ is no longer possible. Given we are checking on height, maybe it'd be reasonable to limit this input as well 18:07:31 10 MB? 18:07:48 @jeffro256: 38.8% per yr 18:08:17 @jeffro256: ~1.39 x a year 18:08:20 @datahoarder: Are coinbase txs not also limited to 1MB? Lemme check 18:08:37 they are post FCMP++ afaik 18:09:10 I don't like how the net will break after 7 years/the net's fundamental limits will cause 'valid' blocks to be rejected after 7 years. 18:09:18 extra data can bloat it before the limit. 18:09:46 Coinbase TXs have no limit other than block size until FCMP++ which enforces extra and output limits. 18:09:51 I wont support a block size bomb which will require a future fork to change scaling vs just changing the long term median growth rate to an acceptable level 18:10:50 We may upgrade the net in seven years. We presumably will as the network hasn't ossified. I don't see why we shouldn't update the sanity limit five years from now via hard fork given we know this will definitively become incongruent with reality at time of deployment. 18:11:23 But that leads into the next agenda topic, so I'll leave my criticism there for now. 18:11:39 @kayabanerve:matrix.org: At least people have notice 18:12:04 @articmine:monero.social: would you support exponential to a hard limit of 90 MB? 18:12:26 No 18:12:36 @boog900: (under the packet size limit) 18:12:41 @boog900:monero.social: Some alternatives to exponential growth are: 1) Polynomial growth, 2) Logistic Growth https://en.wikipedia.org/wiki/Logistic_function#In_economics_and_sociology:_diffusion_of_innovations 3) Bitcoin Cash's block size algorithm with a control function https://gitlab.com/0353F40E/ebaa#technical-description 18:12:48 @ofrnxmr: have to account for overhead 18:12:49 Can we not fix this in 5 years 18:12:54 @boog900:monero.social: Isn't that the next agenda topic? Have the lines disappeared? :( 18:13:13 @articmine: Will need a hard fork to remove the limit afaik (?) 18:13:24 @articmine: Can we not have the net blow up in five years if we don't fix it? 18:13:40 So can cross that road at the same time 18:13:49 We need a HF, either to: 18:13:49 A) Stop the net from blowing up 18:13:49 B) Not have overly limited capacity 18:13:56 I'd rather be slower than incongruent and unstable 18:14:24 @kayabanerve:matrix.org: What you are telling me is that someone put in a scaling bomb in the code 18:14:48 Even if a new relay protocol isn't a HF itself, it will force old nodes to update if they can't download new blocks unless they update to it. 18:14:57 No wonder everyone is up in arms 18:15:10 @articmine:monero.social: Your proposal will force a hard fork in ~7 years if this growth occurs. 18:15:23 @rucknium: I would much rather it take usage to increase the limit but slower growth would be better. 18:15:26 Or we'll have a netsplit 18:15:36 @kayabanerve:matrix.org: I understand. This is a scaling bomb that needs a HF to fix 18:16:15 ... so if you acknowledge you're proposing putting a clock on blowing up the network, can you agree to not do that and accept a 90 MB hard cap? 18:16:40 Or no, you're acknowledging you're proposing a bomb and you refuse to not do so? 18:16:48 @boog900:monero.social: The BCH algorithm does require usage to increase the limit FWIW. 18:17:19 To be fair, a 100 MB serialization limit does not necessarily limit the block size to 100 MB if the block is sent over multiple packets. I will need to check again, but I think that the syncing protocol already supports syncing individual txs from other nodes at a time, and only ~60 bytes per block is needed to validate PoW 18:17:20 Caveat that removing the 90mb sanity cap can/will be done at the same time as the packet size removal/fix 18:17:27 No I am not proposing a bomb. I am proposing fixing this in the next HF 18:17:35 @jeffro256: 100mb packet size limit 18:17:54 Sorry yes, packet size limit 18:18:04 @articmine:monero.social: That is a bomb though. You're saying this will blow up unless there is a next HF. That's the whole reason it's being called a bomb. 18:18:39 @jeffro256:monero.social: Yeah, I did wonder if we could shim such networking protocols. 18:19:04 Which means not supporting ANY HF that doesn't fix this 18:19:27 Clarifying, I'm saying your proposal, if enacted with the FCMP++ HF, will require yet another HF after in order to not cause a net split (unless we create radically new networking proposals which are also backwards compatible). 18:19:38 ArticMine is saying that it can blow up now, the bomb is already planted. Albeit, his proposed scaling changes would make it trigger faster, but we need to fix it even if we didn't HF to FCMP++ 18:19:44 Then defuse the bomb 18:20:12 packet size limit has been there from the start fwiw: https://github.com/monero-project/monero/blob/1a8f5ce89a990e54ec757affff01f27d449640bc/contrib/epee/include/net/levin_base.h#L71 18:20:23 Your proposal doesn't @articmine:monero.social: , not without the 90 MB limit @boog900:monero.social: asked you for and you declined 18:21:01 Why is it so difficult to fix this? 18:21:39 @kayabanerve:matrix.org: It's possible to defuse w/o the 90MB limit by a smart syncing protocol 18:22:44 I'm sorry, this is going in circles so I'm withdrawing until the next agenda item. Your proposal, which assumes and mandates yet another network upgrade later (though as @jeffro256 notes, one POTENTIALLY backwards compatible) is itself a bomb. 18:23:02 Various other limits adde here https://github.com/monero-project/monero/commit/3c7eec152cd5663c461f64699574943d3619f0b9 18:23:41 I think the added sanity cap following tevador's proposal makes sense, with a hard cap at 90mb that can be eliminated once the daemon is rearchitected to actually be able to support it 18:23:42 Please do not delay the FCMP HF for any reason. 18:23:51 @jeffro256: we are betting on that happening before the 100 MB is hit. ngl I gave 90 MB as an example, I knew artic would not agree to it. The exponential growth will get out of hand eventually we will need to HF to decrease it. 18:23:57 It is the single most important change and controversial changes should not be paired with it if at all possible. 18:24:45 90mb wont be hit for 6 years 18:24:52 (sanity cap) 18:25:03 We need to separate the 90 MB hard cap from my proposal 18:25:24 Is it acceptable otherwise 18:25:27 @boog900: This is what I originally said was a bomb, the fact that in enough years the sanity cap grows so much it is no longer in play. 18:25:35 @articmine: its just an "or" on top of your proposal 18:25:35 @articmine: TO YOU. 18:25:54 @jeffro256:monero.social: Wallets, RPC also breaks 18:26:00 Lower of 90mb vs exponential growth vs LTM vs STM 18:26:29 @kayabanerve:matrix.org: Sure, but also those limits can be changed very easily in comparison to p2p limits 18:26:53 as spackle said earlier: essentially, what can the daemon handle today? what can stressnet actually prove as feasible? 18:27:50 Even if the nodes syncs the blocks, it can't serve them and an upgrade is mandated 18:28:12 AFAIK, stressnet hasn't hit any hard limits yet. Just hitting annoying snags. 18:28:21 @jbabb:cypherstack.com: we're still not at the stage where we can answer definitively unfortunately. pool exceeding max default size triggered other issues that took time to investigate and deal with 18:28:45 txpool is a fiasco :) 18:29:10 @rucknium: It might be easier to test/prove limits on beta stressnet, but if it can't reach "hard" limits these soft limits are effectively the scaling limits 18:29:45 As for as the 100 MB bomb there are only two options: 18:29:45 Fix it 18:29:45 Put in a hard cap 18:30:08 This has nothing to do with my proposal 18:30:38 temporary hard cap that will be HF'd away from just as we will HF to lower the sanity growth rate 18:31:29 My proposal does have a built in temporary hard cap 18:32:20 that grows exponentially ... yes we know 18:32:42