15:01:25 MRL meeting in this room in two hours. 15:19:53 I'm sorry, I'm not going to be able to make this MRL meeting 15:55:26 You can skip item 6 unless someone else has something to talk about for that 17:00:39 Meeting time! https://github.com/monero-project/meta/issues/1299 17:00:43 1. Greetings 17:00:50 Hi 17:00:57 hello 17:01:01 Hi 17:02:05 waves 17:02:05 hi 17:02:06 Hello 17:03:24 2. Updates. What is everyone working on? 17:03:57 me: Looking at research papers about p2pool mining scalability. 17:04:22 I have updated the spreadsheet with the weights and the scaling documents 17:04:27 Various bugs and small changes to lws and polishing up lookahead in lwsf. Need to move onto carrot/fcmp in lwsf too 17:05:33 we saw there were some fee related proposals and decided to pass by drop some strong opinions 17:05:43 Is @ack-j:matrix.org / @xmrack:monero.social present? 17:05:51 me: finished up deadlock PR upstream, finished first round review on tx relay v2 (will work with @0xfffc:monero.social on further changes this week), tested and integrated @kayabanerve:matrix.org's new change to the FCMP++ lib that brings memory usage of FCMP++ verification down to 250mb per call to verify (down from ~800mb), [... too long, see https://mrelay.p2pool.observer/e/iebOtMoKd3JQTkxj ] 17:07:40 3. Monero node fuzzing: past, present, & future. Monero Node RPC Endpoints Now Have 100% Fuzzing Coverage (https://magicgrants.org/2025/11/17/Monero-RPC-Fuzzing). 17:08:22 AFAIK, someone from ADA Logics planned to be present at the meeting today. 17:08:25 greetings gentlemens 17:08:58

Yes thanks for the ping 17:11:44

We (Magic) completed the first fuzzing proposal and released AdaLogics report in that blog post. The engagement discovered three RPC issues that affected the availability of monero nodes, which are all now fixed. We are looking to get feedback on our next fuzzing proposal targeting src/wallet src/p2p and src/fcmp_pp 17:12:17

David from adalogics said they might join as well to answer questions 17:14:11

Generally we look to increase code coverage as much as possible, but in a strategic manner 17:15:05 I don't know about the code, but maybe in public appeals for funding, you can say why fuzzing is important in the title. I don't think ordinary people know what fuzzing is. Maybe "Automated search for exploitable vulnerabilities" or something. 17:15:42 more like bugs, depending on what is fuzzed and how they can fin vulnerabilities that cannot be exploited 17:16:22

I’ll word-smith the title a bit 17:16:23 tho in this case the fuzzing done by ada is using the endpoits directly so same access as an attacker 17:17:07 p2p seems to me to be the very next thing to do. 17:17:47 Hi! 17:17:49 @everyone 17:17:50 * jrkl23jlka likes people fuzzing around 17:18:53 hi Guest678, please sit tight and listen to others. also @everyone do not work, it's a discord thing. 17:19:11 I know I'm sorry, I am just messing with a monero discord server that has integrated this chat as a channel :) 17:19:15

P2P fuzzing will be a main focus of the next project. Any crashes discovered there would likely be very high impact 17:20:19 Guest678: Please do not allow any bridges from Discord in this channel to be able to send messages. Only read-only. 17:20:23

I dont see David in here so we can likely skip to the next section if there are no other questions 17:20:53 Are the findings of the fuzz public yet? 17:21:55

We didn’t release specifics as the hackerone issues havent been publicized yet 17:24:00

One thing to note is that these fuzzing harnesses will pay dividends in the long run as code changes are made to the master branch they will automatically be fuzzed using large amounts of compute 17:25:58 ^ fuzzing is great, did that for consensus code, then C P2Pool had some, and found issues on both sides that way. and eternally finding edge cases that now stay as unit tests 17:25:59 Sounding like it was an effective and fruitful start, thanks for pushing this forward! 17:26:54 fuzzing is like gambling. and gambling does push you to the edge cases of your life 17:27:13 so gambling is a good thing 17:27:16 I +1 the main focus being on p2p. Happy to help with fcmp++ as well when they get to it 17:27:21 i meant fuzzing 17:27:43

David is joining shortly if there are any questions for him regarding the report 17:28:24 @ack-j:matrix.org: Thanks for arranging! 17:29:26 The only thing I noticed about the fuzzing is that review and merger of the harness took a while. But that seems common for most PRs to the Monero codebase. 17:32:28 Welcome, @davkor:mozilla.org ! 17:33:27 @rucknium: One potential option for improving speed here would be to place the fuzzing harnesses in a different repository with less scrutiny on code introduced into the repo. In essence they don't have to live the same place as the main code. Am not sure if this would be preferable, but it's an option from OSS-Fuzz's perspective. 17:34:12 @rucknium: thank you! 17:36:11 > <@syntheticbird> Are the findings of the fuzz public yet? 17:36:11 One thing to be aware of here is that OSS-Fuzz itself has a 90 day disclosure deadline, after which limited information on issues will be made public. Following a fix of an issue, OSS-Fuzz will also make limited information public, even if it's earlier than the 90 day deadline. Monero has been integrated into OSS-Fuzz for a nu [... too long, see https://mrelay.p2pool.observer/e/1u-9tcoKbWFXOTVf ] 17:39:56 Keeping this in the main repo seems ideal to me to make sure it remains updated as changes are made. The PR was opened Jul 18, first reviewed and approved Aug 13, merged in Sept. That doesn't seem too outlandish to me. And now that there is an established framework in use for RPC, I would expect the future PR's to be smoother anyway 17:41:38 @jberman: Yup, no problem from our side as well. One potential caveat is that once the harnesses are public someone may launch a huge compute effort to run them while they are still being reviewed. A small race could happen with who runs the fuzzing harnesses a lot the quickest. But I'd probably say that's a minor issue. A [... too long, see https://mrelay.p2pool.observer/e/n-7RtcoKeTBiZEV1 ] 17:42:21 I'll just place here that i know people that didn't wait for the harness to fuzz parts that are currently unfuzzed 17:42:24 Where is the compute power coming from by the way? GitHub? 17:42:39 i'm not aware of any results so far form their parts 17:43:06 @rucknium: on OSS-Fuzz (https://github.com/google/oss-fuzz), Google 17:43:47 so i don't think anyone actually somewhat qualified to exploit a findings with the harness would wait on it to be developed 17:45:09 Hm, so sounds like the alternative would be to keep the changes private somewhere until the harness has run some sufficient amount, and then open it up for review if nothing found 17:46:05 that would slow down integration and try to solve a very unlikely scenario but that is a responsable approach. 17:46:15 @jberman: yeah, this is also what we did previously. 17:46:54

^ david and his team fuzzed the harnesses on their own hardware for a while waiting for the PR to merge 17:47:50 I do think that would be a reasonable approach to use for p2p 17:48:08

Once merged I dont see a problem as no one is going to match the compute of google, but in review limbo there is a race condition 17:49:51 @ack-j:matrix.org: Are there documentation about the computer power of oss-fuzz. I doubt they are giving a dedicated super computer to every open source project registered 17:50:15

It should be noted that this doesn’t introduce any dependency on google and google has no admin access to the monero codebase. They simply clone the monero repo and run the fuzzing harnesses we developed at a massive scale. They do this for free since monero is FOSS 17:51:12 @gingeropolous:monero.social has a nice cluster of solid hardware that could be useful here. Order of ops for p2p could be 1) develop it, 2) run the harnesses for x period of time using ginger's compute cluster, 3) once satisfied, open the PR 17:55:22 Any other comments or questions on this topic? 17:55:24 When we developed the previous harnesses we ran it for XXX amount of hours but also looked at when coverage increase in the harness was starting to slow down, and then determined they don't find any low hanging bugs 17:57:32 @davkor:mozilla.org: Thanks for your work and joining the meeting today. If people have more feedback or questions, how can they reach you? Through @ack-j:matrix.org ? Do you accept DMs to your Matrix account? 17:57:51 thank you @davkor:mozilla.org ! 17:58:34 @rucknium: they can reach me on david⊙ac -- writing to @ack-j:matrix.org is also one way of getting through to me as we have communication channels open. 17:59:11 Thank you. 17:59:16 4. P2Pool consolidation fees after FCMP hard fork. Coinbase Consolidation Tx Type (https://github.com/monero-project/research-lab/issues/108). 18:00:22 I looked through some research papers on the subject. It seems that most papers don't try to fix p2pool. Instead, they suggest using an Ethereum-compatible smart contract: 18:00:35 Luu, Velner, Teutsch, & Saxena (2017) "SmartPool: Practical Decentralized Pooled Mining" 18:00:35 Troutman & Laszka (2021) "PoolParty: Efficient Blockchain-Agnostic Decentralized Mining Pool" 18:00:35 Papathanasiou, Kyriakidou, Pittaras, & Polyzos (2024) "Smart contract-based decentralized mining pools for Proof-of-Work blockchains" 18:00:35 Sakurai & Shudo (2025) "FiberPool: Leveraging Multiple Blockchains for Decentralized Pooled Mining" 18:01:00 I haven't seen anything in these papers that completely satisfies me. 18:01:31 And I don't know if anyone would be willing to try to implement and deploy something like that for Monero. 18:02:05 Any more comments on this topic for now? 18:02:50 Sorry, I was away 18:03:19 I have been looking to do multisig consolidation under FCMP++ N-of-N with presigned txs (and proof done later?) 18:03:51 No more that sketches, I have started implementing FCMP++ parts themselves to experiment. Will ask questions elsewhere if I have any 18:04:40 Thanks, DataHoarder 18:04:45 nice! 18:05:11 no HTLCs, so no tx invalidation, but chaining is workable with fallbacks for non-cooperation 18:06:09 PTLCs? 18:06:10 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:07:10 I have uploaded 2025-11-02, which is the latest update 18:07:39 I had the. proposed most recent weight 18:08:11 Resolving the scaling and fee parameters question is becoming more time-sensitive as other blockers for the second (and most likely final) FCMP stressnet are being successfully addressed. 18:08:22 Without the adjustments for powers of 2 18:09:01 I started reviewing the latest and will complete my initial review within the next couple days 18:09:16 Great 18:10:37 Any questions? 18:10:43 jrkl23jlka: Did you want to comment in this agenda item? 18:10:47 We'd like to make a suggestion on the transaction pool fee distribution functions, mostly unrelated to what is being proposed. The idea of quantisation is to increase anonymity set, by having different users pay the same fees and get mixed in. 18:11:14 But an alternative (and NOT mutually exclusive with quantisation) is to bias the fee probability distribution function towards a uniform distribution (i.e., max entropy state, "white noise" full spectrum), 18:12:00 while still permitting for transaction priority assignements--by placing transactions fees in the range that represents the priority of the transaction, 18:12:01 How does this work with a fee market! 18:12:20 but at a finer resolution by specifically picking underrepresented fee values in the fee distribution, thus promoting that distribution to become more uniform, 18:12:33 much more like a predictable transaction queue representing transaction priorities. 18:12:47 Like that users picking fees in advance for offchain transactions (such as in payment channel or atomic swaps) won't be fingerprinted too badly. 18:12:49 So instead of have five fee levels we have 5 fee ranges 18:13:18 In general, custom wallets picking "the wrong" fee values won't fingerprint their users too bad either because its easier to hide in white noise (=uniform distribution) than on an highly structured, deterministic function. 18:13:26 And clearly this does not requires consensus, just real-time, transaction-pool / blockspace based market dynamics. 18:13:30 They will be fingerprinted anyway since they will reference an outdated merkle state in the FCMP tree 18:13:53 Yes this is not consensus 18:14:50 articmine: not really 5 ranges, all you are trying to do is get a flat fee distribution 18:14:55 It adds noise around the fee levels 18:14:57 Custom wallet implementations that choose a deterministic fee would likely create spikes in the uniform distribution. 18:15:22 independent of quantization levels (u could have many bins, or treat 1 piconero as a bin), and that would work too 18:15:48 articmine: exactly, it adds WHITE noise around fees 18:15:50 It is actually very interesting 18:15:58 "They will be fingerprinted anyway since they will reference an outdated merkle state in the FCMP tree" -> this isn't necessarily accurate, you can pre-sign and construct the membership proof without needing the spend key later 18:16:12 @jberman:monero.social: Ah, thanks. 18:16:53 rucknium: then other wallets fix those spikes by spreading transactions around 18:17:30 and pushing those peaks on the pdfs down 18:17:58 *probability density function 18:19:10 I proposed a 1000 block buffer for median changes over the current 10 block that should help with this 18:19:47 It does create time for this kind of distribution 18:19:59 You're saying that wallet software should actively watch the recent distribution of fees. Maybe a node could cache that and share with wallets. But you would have to have a very limited number of ... 18:20:00 Wait, it honest wallets can observe the spike and "correct" it, the an adversary would also be able to notice the spikes before they are corrected. 18:20:08 if honest wallets* 18:21:35 The idea is to introduce noise. How statically sound this would be is a research project of it's own 18:22:00 Statistically* 18:22:12 we are only talking about real-time fee dynamics 18:22:21 not long-range as articmine 18:22:41 @davkor:mozilla.org: @ack-j:matrix.org: As a note, I'd love to see monerod with musl (as on Alpine) tested. musl sets a much smaller stack size by default which makes monerod (at least in the past) not run properly. Using the fuzzer to ascertain stack size requirements so we can use libc calls to ensure that stack size is provided to each context would be great. 18:22:54 The good thing about this is that it can be implemented after the hard forl 18:23:10 Sorry for the interjection 18:23:44 @jberman:monero.social: which is one of the reasons why weight must be independent of the layers, yep 18:23:58 jrkl23jlka: Yes like a day or so 18:25:12 Fees are based on the long term median so there is more room timewise 18:25:34 we are talking about what is currently in the transaction pool 18:26:07 I don't see a problem here 18:26:09 and fees should be based on market dynamics and transaction priorities, not history 18:28:15 people would pay 50 usd in btc fees on a almost empty tx pool, because the transaction pool was crowed a few hours before, and the past was not the present 18:28:29 The fee is based upon the penalty that the transaction would attract.. This is part of the fee market 18:29:07 Then of course there is supply and demand 18:30:59 It is not like Bitcoin where increasing prices do not increase supply. In Monero increasing price does add block space 18:31:11 So supply is increased 18:31:22 but its about transients in transaction numbers 18:31:36 real-time, instantaneous fees 18:31:40 not scalling 18:31:48 over long time ranges 18:31:50 Yes that is also part of the picture 18:32:23 anyway, i think i made myself clear. uniform distribution is where the we hide the best 18:32:41 The penalty is paid on the short term median which is 100 blocks 18:32:57 So there is very short term scaling 18:33:19 it does not matter what happens 100 blocks ago, if the transaction pool is empty 18:33:22 About 100 minutes 18:33:44 theres available block space and you can pay little fees 18:34:56 jrkl23jlka: The block size limit does depend on the recent and past history 18:35:59 that is an almost orthogonal dimension 18:36:35 I can go over this with you 18:36:47 Any more discussion of this item for now? 18:36:58 no 18:37:09 6. FCMP alpha stressnet (https://monero.town/post/6763165). 18:39:37 1.5 coming soon. ooms largely fixed, i think 18:39:39 @jberman:monero.social already gave an update on stressnet improvements at the beginning of the meeting. Anything else? 18:40:11 My only q is wen carrot? but jeffro not here 18:41:34 Trying to get 1.5 out in the next couple days that should address OOM's and slow sync 18:42:38 We can end the meeting here. Thanks everyone. 18:42:58 Thanks 18:45:46 I'll take a look to the linked papers, rucknium. But as you said they just implement the logic elsewhere (and the few I found myself assume there is an automated chain bridge, centralized or not, to be able to pass rewards) 18:55:08 thank you for the meeting 18:55:54 DataHoarder: you talked about transaction chaining. how far are we from being able to do PTLCs? 18:56:20 s/PTLCs/point-time locked contracts 18:57:19 we need a per output timelock, any current proposals on that? 18:58:10 * jrkl23jlka does not follow monero development closely, so lagging a few years behind 18:58:41 I have not looked at that within the scope of Monero. This implementation also requires full verification by other parties, including ones not directly involved in the multisig (or at least verified origin). It also needs to be fast relatively, though it can be generated ahead of time 18:59:27 I'd recommend then looking at atomic swaps jrkl23jlka 19:00:23 what atomic swaps? 19:00:44 the btc one was using 2 time locks on teh btc side 19:03:28 monero doesnt have HTLCs & isnt coming with fcmp++ fork 19:04:19 but it can have PTLCs jack_ma_blabla 19:07:55 instead of hiding a secret in a preimage of a hash, u hide it in a scalar that can be represented by an ec point. and u leak the scalar through adaptor signatures, like in the atomic swaps 19:29:34 DataHoarder: DataHoarder: Thanks 22:35:51 so a random update on monerosim, sorry i keep missing the meetings. have job job during that time. I was going down a tangent to try and get some mining shim to work from within monerod. I'm going to abandon that and go back to getting the block controller version polished and ready for general use, because I think it might be [... too long, see https://mrelay.p2pool.observer/e/zqmHvsoKTk1vWTdM ]