11:25:21 Hi everyone, i just want to let the community know about the new update: 11:25:21 https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626#note_36734 14:17:04 @emsczkp:matrix.org: Thank you. Do you want me to put your update on today's MRL agenda? 14:37:05 Yes, thank you 15:01:00 MRL meeting in this room in two hours. 16:07:09 unfortunately I won't be able to attend live during the meeting. But I'm continuing to push monerosim towards mainnet fidelity. Current results here: https://github.com/Fountain5405/monerosim/blob/main/docs/20260620_network_topology_study.md . TL;DR, it seems the hypothesis was right, that a 100% reachable network behaves differently than main net. 16:07:53 the sim currently running is the "churning" - nodes turning on and off throughout the sim, as opposed to always on. 17:00:34 Meeting time! https://github.com/monero-project/meta/issues/1410 17:00:39 1. Greetings 17:01:05 Hello 17:01:06 Hello 17:01:08 waves 17:01:14 👋 17:01:30 Hello 17:02:01 Hello 17:02:04 Howdy 17:02:17 Hi 17:02:28 2. Updates. What is everyone working on? 17:02:49 me: warning people to STAY HYDRATED 🚰 17:03:11 me: reviewing upstream PRs, implementing feedback for FCMP++/CARROT PRs, writing documentation for existing code 17:03:14 me: Keeping stressnet stressed with transaction spam. Helping identify stressnet bugs. 17:04:02 updated my tooling and go-p2pool test to support beta stressnet (which works vastly better than alpha for the purposes of mining, so far, even with the current tx spam levels) 17:04:29 Making some patches, and have also ostensibly finished the daemon integration for I2P SAM. Waiting on sone feedback :) 17:05:36 me: continuing reviewing jeffro's Carrot/FCMP++ hot-cold wallet PR, continuing investigating the observed stressnet wallet double spend error with @rucknium:monero.social's help 17:06:14 3. emsczkp research Bulletproofs* Milestone 2 completed (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626#note_36734). 17:07:23 Hi everyone! this updated version of the paper provides the proofs of the main theorems establishing the security of the BP* folding scheme. In particular, Theorem 1 proves that the modified AC proof for Bulletproofs is complete, HVZK, and special sound. Before introducing the BP* folding scheme, the paper presents an intermed [... too long, see https://mrelay.p2pool.observer/e/-6bkoJALcmlnOWtT ] 17:08:23 The revised version also includes some changes with respect to the previous draft. In particular, it introduces a new algebraic verifier map V^comm and its relaxed version. This required the introduction of additional error terms in both the accumulator and the accumulation proof. 17:09:08 Overall, the main purpose of this step is the security proof 17:09:55 I've added more details in the GitLab update comment 17:12:41 sounding like great progress! 17:12:46 @emsczkp:matrix.org: Thank you! After completing Milestone 2, did you uncover anything that makes Milestone 3 (extend Bulletproofs* to Generalized Bulletproofs) more difficult or easier? 17:15:11 thanks, for the step 3 i think it will be appropriate to go into detail about GBP's relation and security proofs, but the folding scheme now appears to me extendable to GBP 17:15:49 i can't say for sure, but i see good foundations 17:18:11 Do you have more discussion of this item or questions for @emsczkp:matrix.org at this time? 17:19:29 Thank you, @emsczkp:matrix.org . 17:19:32 4. Post-quantum encryption (https://github.com/monero-project/research-lab/issues/151#issuecomment-4412416686). Jamtis (https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832#appendix-c-instant-sync-protocol). 17:19:44 @rucknium: Thank you! 17:20:17 I have no significant updates for today. 17:21:54 Anyone else have comments or questions on this item? 17:22:27 I think that with the implementation of Polyseed in the official wallet (big thanks to rbrunner), it makes sense to directly implement Jamtis and skip the Carrot hierarchy to save 1 Polyseed bit. 17:23:48 You mean no "Carrot key hierarchy" feature bit, but a "Jamtis" feature bit? 17:24:50 Yes, exactly 17:25:14 tevador: I disagree, I still think that there's value in having a hierarchy with enchanced features and some quantum privacy which is backwards compatible and indistinguishable from existing addresses 17:25:45 What would be the impact on the timing of the HF here? 17:25:49 I don't think we need to make a decision on that until FCMP++ / Carrot (without the Carrot key hierarchy) is 100% merged upstream in the first place. It'll be a question of what to work on/prioritize next at that point/what the timeline to Jamtis versus Carrot hierarchy would be expected to be 17:25:56 Jamtis is strictly superior to the Carrot key hierarchy 17:25:57 Well, skipping the Carrot key hierarchy and go directly to Jamtis is of course a much bigger question than any feature bits alone :) 17:25:57 @articmine: 0 impact 17:27:08 The only reason to introduce an intermediate wallet type would be if Jamtis was severely delayed for some reason (I don't forsee that at the moment). 17:27:15 Looks like a hard decision to me. Both pathes have advantages and disadvantages 17:30:13 FWIW, having multiple intermediate addressing protocols (which will each presumably be used for just a few years) in the codebase would seemingly create quite a large attack surface, and that code will have to be maintained forever if we are to keep restore functionality 17:30:48 Just wondering, couldn't a switch to Jamtis get complicated if it should turn out that it brings a significant performance hit? 17:31:06 tevador: Except in metrics that I previously mentioned: backwards compatability, and by extension, ease of implementation, and indistinguishability 17:31:08 Do we have already any idea how Jamtis might perform 17:33:04 "Details table" section in https://github.com/monero-project/research-lab/issues/151#issuecomment-4281932714 17:33:37 "Just a few years" is quite a lot in the life of a cryptocurrency, as they develop today, if you ask me 17:34:05 jeffro256: no protocol with the features of Jamtis can compete on those metrics. But you are technically correct. However, Carrot is also beaten by CryptoNote on the 'ease of implementation' metric. 17:34:08 19:25:56 Jamtis is strictly superior to the Carrot key hierarchy 17:34:08 the reason for Carrot though is being still backwards compat with address format as mentioned 17:34:44 Ah, yes, sorry I forgot this table. Where we ruled out schemes that would run for freaking hours! 17:35:28 Jamtis scanning performance should be roughly on par with Carrot, except for wallets with a lot of received external payments that need CSIDH decryption. 17:37:45 What about TX sizes? 17:38:38 Unpruned parts of the tx (the part that wallets download) would be 31% larger 17:39:02 For BC512 17:39:16 Jamtis aims for on-chain indistinguishability, which implies identical tx sizes. But there will be ~132 bytes in tx extra for all transactions (even legacy ones). 17:39:31 IMHO it could well be that we can go into a focussed decision process only with the FCMP++ and Carrot hardfork successfully behind us, not yet now 17:40:10 Yes, it's definitely too early to decide. I was just stating my opinion. 17:42:34 Yes, TBC, the bit that decides whether unpruned tx sections rises by 31% is whether or not we collectively decide to support Jamtis in some wallets AND plan for on-chain distinguishability. If we stuck with only the Carrot hierarchy, then tx sizes would stay down. But if some wallets support Jamtis-PQ and we decide that all [... too long, see https://mrelay.p2pool.observer/e/oZvloZALcUFpZnRF ] 17:44:28 A 31% increase in sizes is less than 1 year of Neilsen's law 17:45:34 It's the price to pay for PQ privacy with static address support. 17:45:35 Well, right now only storage prices rise trememdously. Thanks, AI 17:46:08 Will give quite a dent in that law 17:46:26 This is very short term. I prefer to focus on the long term 17:47:18 Yes I am very much aware of the SSD pricing issue 17:47:26 Understood. And still, we want to offer a cryptocurrency that works today, for various values of "today" for the next years 17:48:16 Well, should probably have written "works well" 17:48:36 More discussion of this for now? 17:49:44 5. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). 17:51:11 We are pushing up the long term median block size now. https://stressnetnode1.redteam.cash/ 17:51:11 We produced a 17MB block recently: https://stressnet.p2pool.observer/block/cdae2957c5c0034d7b40a79ba636b31e01635456ab6398e3a3e2e68caebd6958 17:51:15 have been seeing an increase on block sizes (recent ones have quite a list of txs) https://stressnet.p2pool.observer/block/cdae2957c5c0034d7b40a79ba636b31e01635456ab6398e3a3e2e68caebd6958 thanks to the spam 17:51:31 heh. yep that block. there is a second one as well https://stressnet.p2pool.observer/block/d36b9d9f057c972d54293bb7d2c57e475a97a9d34ddebe9e8973b3bf641adcf8 17:51:36 Thanks to DataHoarder[m] for getting his FCMP block explorer working :) 17:51:49 Not a whole lot of updates from me. Still bugging hardware wallet people. Working on hot/cold PR, thanks @j-berman. I'm about to push a couple business PRs to upstream 17:52:17 my p2pool miner will stop packing txs past 128K block blob byte sizes, but I can deal with that. it's 70 KiB / 128 KiB so far and approaching quick :) 17:52:23 I decided to turn some of my spam wallets to high fees to push block sizes up and exhaust the wallets' funds. 17:52:43 anything else to do to help push sizes further? I have p2pool mining code which is quite efficient at packing these sudden high fee txs 17:52:46 Stressnet generally seems to continue to run smooth. Unfortunately, the issue I brought up last week of wallets sporadically erroring on tx construction with double spend errors is actually not solved yet (seems I mistakenly mis-identified the root cause of the issue, realized thanks to @rbrunner7:monero.social's pushback on t [... too long, see https://mrelay.p2pool.observer/e/jM6KopALSlNURmpR ] 17:53:05 I can send funds or mine to other addresses if that'd help Rucknium :) 17:54:06 DataHoarder: DataHoarder: We hit another long-term median ceiling again. I don't know how long we will be scraping that ceiling until it gives way. I'd guess 1-4 days. 17:54:38 additionally could make many miner outputs on coinbases, that send each to a different wallet (and with some changes, maybe multiple per wallet) 17:54:55 DataHoarder: I may need more funds in a week to two. You can pay me back for those high-fee mined blocks :D 17:55:15 so far I have been sending to the faucet, give an address and I can send via the wallet :) 17:56:06 also, for anyone mining or spamming, if you'd like to get listed on the blocks list with attribution or https://stressnet.p2pool.observer/pools, or display payment details, you can give an address+viewkey 17:56:16 I chose to exhaust funds on a few wallets because eventually big wallets get slower. Big = lots of historical txs. 17:57:07 Same here, I've built up some miner funds , let me know where to send em 17:57:16 My main stressnet wallet: 9uk5eY8waibQp7MMwpo3JrcMFatbiGtHKcTHMEzxWE39An8R3VTbztTPcJ7MDYEVVrAC4ueSV5KzP4GMTTwGoGBjAtKFp7i 17:58:14 Thanks. 17:58:25 sent ~640 tXMR your way. 17:58:32 More discussion about stressnet? 17:58:40 DataHoarder: Thank you. 17:59:30 how long is v2 beta stressnet expected to continue for? 18:01:02 I would suggest that it run until the hard limit 100 MB code issues are addressed 18:01:27 So we'll afy the HF 18:01:38 after 18:01:41 100MB blob byte size or weight size? 18:02:59 DataHoarder: Enough to trigger the code issues 18:03:02 privacy wise, would it be proper in these sweep cases https://stressnet.p2pool.observer/tx/b5ec0584c6da18cc13ecc71a95609bd801cd1ee2379b6bc6bb12f18cc5ccd339 to not send 0.000000000000 XMR back as change? 18:03:04 It would be nice to solve the following big issues observed: sporadic double spend errors, higher ban frequency, possibly node's pool not catching up to another. And get p2p SSL and hot/cold wallet support running / tested. It would also be very nice to get the major RPC getblocks.bin speedup implemented too because I expect t [... too long, see https://mrelay.p2pool.observer/e/3JywopALUjNmcFh6 ] 18:03:29 Yes 18:03:55 the former "nice-to-solves" would be nice to solve to be certain if the cause is tx relay v2, pre-existing, or anything FCMP++/Carrot related (though that is not my current suspicion) 18:04:31 tx relay v2 though I guess is a big +1 especially for FCMP++ once tx sizes are much larger, so it's indirectly related in that way 18:04:40 Would the RPC getblocks.bin speedup affect wallets' txpool requests at all? 18:05:07 @rucknium: ya that's what I'm referring to there (the pool fetching part of getblocks.bin, not the blocks fetching part) 18:05:21 DataHoarder: You need 1 scannable output per tx as per CARROT rules. Also, if you share your viewkey and the public can see amounts of UTXOs , they can calculate that the output has 0 XMR anyways 18:05:25 Ah good. 18:06:37 jeffro256: yeah, this case is due to viewkey sharing specifically that it decrypts the 0 XMR. I guess it'll be better with full Carrot where those outputs end up internal instead of the special external change case. 18:07:02 The main reason the sweep case has 0 amount change back to sender is so that seeds remain compatible for background syncing and light wallet support as currently implemented (without needing to reveal your key images to a daemon/server) 18:07:04 I think my max spam pace is being limited by slow wallet-node interaction. I think I can only get 25-30 wallets connected per node before adding more wallets decreases total spam volume. And I don't have infinite nodes. 18:07:38 right! the tx needs to be picked up by a spend / view balance wallet 18:08:11 If we want to go a lot higher with tx volume, faster RPC would be very helpful I think. 18:08:25 Rucknium: I see a lot of txs coming as discretized units instead of batches which is spamming some of my logs, so somewhere it's hitting a bottleneck 18:08:54 example recent ones https://privatebin.net/?80e0dae714f31b58#6LpSPFNkyXywMyMBsrPmBPHDK7NBip7buEa7yaGB6HWP 18:09:00 ya it's known when there's a lot of txs in the pool, the /getblocks.bin request can be extremely slow and prevent the daemon from doing anything: https://github.com/seraphis-migration/monero/issues/293 18:09:38 Discretized units instead of batches means what? 18:09:40 afaik the verification is faster (1.5s for the recent big blocks) 18:10:28 Rucknium: on ZMQ interface new txs can be notified as one event instead of individual ones. Usually the node is fast enough that it aggregates them a bit, but recently it has started sending many individual events (which adds some overhead) 18:10:57 @jberman:monero.social: Will the new getblock.bin code make txpool requests become a non-blocking operation? 18:11:45 DataHoarder: Do you think that is related to clumping in p2p tx messages? 18:12:02 It will still be blocking 18:12:03 @rucknium: no, it can make the request take ~0.1s as opposed to 3-15s+ per wallet. Making it a non-blocking operation is another potential improvement mentioned in that issue 18:12:28 yeah, maybe they are less clumped, so they don't come at once, or the monero code takes time verifying them. they also come very quick one after each other 18:12:29 Unfortunately that's just how the blockchain DB and higher level code work 18:12:34 e.g. https://github.com/Fountain5405/monerosim/issues/3 "Clumping in transaction broadcast messages" 18:13:48 I am talking about post-verification, where it notifies listeners via ZMQ. I can't remember if that's done per clump on the wire message, or on the go as txs get verified 18:15:37 I think we had some attrition with the total number of nodes on the network. IMHO a smaller network causes less tx message clumping. I don't know if that could be causing what you're seeing. 18:19:19 6. monerosim (https://github.com/Fountain5405/monerosim). 18:19:28 code on my side is performant, so doesn't make much of a difference except sending ~400 new jobs to xmrig instead of 2-10 per block 18:19:51 @gingeropolous:monero.social gave an update before the meeting: 18:19:54 > unfortunately I won't be able to attend live during the meeting. But I'm continuing to push monerosim towards mainnet fidelity. Current results here: https://github.com/Fountain5405/monerosim/blob/main/docs/20260620_network_topology_study.md . TL;DR, it seems the hypothesis was right, that a 100% reachable network behaves differently than main net. 18:20:07 > the sim currently running is the "churning" - nodes turning on and off throughout the sim, as opposed to always on. 18:24:32 I think someone has one last question for the meeting. 18:25:52 Can I quickly ask about the Milestone ? Do people think another review slot is needed next week, or can we consider the current state sufficient for approval? Thanks 18:27:44 IMHO this depends on if anyone plans to spent time reading the revised paper at this point. 18:28:08 Yeah, feedback from one of our cryptographers would be interesting 18:28:36 Even as they are surely quite busy already ... 18:29:50 > <@jberman> It would be nice to solve the following big issues observed: sporadic double spend errors, higher ban frequency, possibly node's pool not catching up to another. And get p2p SSL and hot/cold wallet support running / tested. It would also be very nice to get the major RPC getblocks.bin speedup implemented too b [... too long, see https://mrelay.p2pool.observer/e/i6mSo5ALV0N2THow ] 18:29:50 I'm running p2p ssl 18:30:08 We will see if anyone comments here and then decide about approval timeline. 18:30:16 On stressnet, on 2 nodes, and seems to be a third node on sttessnet also running it 18:30:28 We can end the meeting here. Thanks everyone. 18:30:31 (sorry for the interruption) 18:30:49 Thanks 18:35:46 @rucknium: I will try to make time over the next week, but FWIW the summary does sound like solid progress to me 18:36:04 Thanks, @jberman:monero.social 18:36:32 @jberman: Thank you 19:03:44 Crap missed reminders about meeting. I was focused on the fido2 encryption lib, initial but not yet complete code is at github.com/vtnerd/fhse 19:04:11 There's already the base structure with tests and ci 19:08:58 tevador: is there any implementation of current jamtis progress/research other than the gist? 19:29:02 There is only the specification in the gist, no code yet.