<rucknium> MRL meeting in this room in two hours.

<jeffro256> I'm sorry, I'm not going to be able to make this MRL meeting

<sgp_> You can skip item 6 unless someone else has something to talk about for that

<rucknium> Meeting time! monero-project/meta #1299

<rucknium> 1. Greetings

<articmine> Hi

hello

<vtnerd> Hi

<jberman> waves

<boog900> hi

<spackle> Hello

<rucknium> 2. Updates. What is everyone working on?

<rucknium> me: Looking at research papers about p2pool mining scalability.

<articmine> I have updated the spreadsheet with the weights and the scaling documents

<vtnerd> Various bugs and small changes to lws and polishing up lookahead in lwsf. Need to move onto carrot/fcmp in lwsf too

we saw there were some fee related proposals and decided to pass by drop some strong opinions

<rucknium> Is @ack-j:matrix.org / @xmrack:monero.social present?

<jberman> 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 mrelay.p2pool.observer/e/iebOtMoKd3JQTkxj ]

<rucknium> 3. Monero node fuzzing: past, present, & future. Monero Node RPC Endpoints Now Have 100% Fuzzing Coverage (magicgrants.org/2025/11/17/Monero-RPC-Fuzzing).

<rucknium> AFAIK, someone from ADA Logics planned to be present at the meeting today.

<syntheticbird> greetings gentlemens

<ack-j:matrix.org> Yes thanks for the ping

<ack-j:matrix.org> 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

<ack-j:matrix.org> David from adalogics said they might join as well to answer questions

<ack-j:matrix.org> Generally we look to increase code coverage as much as possible, but in a strategic manner

<rucknium> 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.

<syntheticbird> more like bugs, depending on what is fuzzed and how they can fin vulnerabilities that cannot be exploited

<ack-j:matrix.org> I’ll word-smith the title a bit

<syntheticbird> tho in this case the fuzzing done by ada is using the endpoits directly so same access as an attacker

<syntheticbird> p2p seems to me to be the very next thing to do.

Hi!

@everyone

<syntheticbird> hi Guest678, please sit tight and listen to others. also @everyone do not work, it's a discord thing.

I know I'm sorry, I am just messing with a monero discord server that has integrated this chat as a channel :)

<ack-j:matrix.org> P2P fuzzing will be a main focus of the next project. Any crashes discovered there would likely be very high impact

<rucknium> Guest678: Please do not allow any bridges from Discord in this channel to be able to send messages. Only read-only.

<ack-j:matrix.org> I dont see David in here so we can likely skip to the next section if there are no other questions

<syntheticbird> Are the findings of the fuzz public yet?

<ack-j:matrix.org> We didn’t release specifics as the hackerone issues havent been publicized yet

<ack-j:matrix.org> 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

^ 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

<jberman> Sounding like it was an effective and fruitful start, thanks for pushing this forward!

<syntheticbird> fuzzing is like gambling. and gambling does push you to the edge cases of your life

<syntheticbird> so gambling is a good thing

<jberman> I +1 the main focus being on p2p. Happy to help with fcmp++ as well when they get to it

<syntheticbird> i meant fuzzing

<ack-j:matrix.org> David is joining shortly if there are any questions for him regarding the report

<rucknium> @ack-j:matrix.org: Thanks for arranging!

<rucknium> 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.

<rucknium> Welcome, @davkor:mozilla.org !

<davkor:mozilla.org> @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.

<davkor:mozilla.org> @rucknium: thank you!

<davkor:mozilla.org> > <@syntheticbird> Are the findings of the fuzz public yet?

<davkor:mozilla.org> 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 mrelay.p2pool.observer/e/1u-9tcoKbWFXOTVf ]

<jberman> 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

<davkor:mozilla.org> @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 mrelay.p2pool.observer/e/n-7RtcoKeTBiZEV1 ]

<syntheticbird> I'll just place here that i know people that didn't wait for the harness to fuzz parts that are currently unfuzzed

<rucknium> Where is the compute power coming from by the way? GitHub?

<syntheticbird> i'm not aware of any results so far form their parts

<davkor:mozilla.org> @rucknium: on OSS-Fuzz (github.com/google/oss-fuzz), Google

<syntheticbird> so i don't think anyone actually somewhat qualified to exploit a findings with the harness would wait on it to be developed

<jberman> 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

<syntheticbird> that would slow down integration and try to solve a very unlikely scenario but that is a responsable approach.

<davkor:mozilla.org> @jberman: yeah, this is also what we did previously.

<ack-j:matrix.org> ^ david and his team fuzzed the harnesses on their own hardware for a while waiting for the PR to merge

<jberman> I do think that would be a reasonable approach to use for p2p

<ack-j:matrix.org> 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

<syntheticbird> @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

<ack-j:matrix.org> 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

<jberman> @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

<rucknium> Any other comments or questions on this topic?

<davkor:mozilla.org> 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

<rucknium> @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?

<jberman> thank you @davkor:mozilla.org !

<davkor:mozilla.org> @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.

<rucknium> Thank you.

<rucknium> 4. P2Pool consolidation fees after FCMP hard fork. Coinbase Consolidation Tx Type (monero-project/research-lab #108).

<rucknium> 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:

<rucknium> Luu, Velner, Teutsch, & Saxena (2017) "SmartPool: Practical Decentralized Pooled Mining"

<rucknium> Troutman & Laszka (2021) "PoolParty: Efficient Blockchain-Agnostic Decentralized Mining Pool"

<rucknium> Papathanasiou, Kyriakidou, Pittaras, & Polyzos (2024) "Smart contract-based decentralized mining pools for Proof-of-Work blockchains"

<rucknium> Sakurai & Shudo (2025) "FiberPool: Leveraging Multiple Blockchains for Decentralized Pooled Mining"

<rucknium> I haven't seen anything in these papers that completely satisfies me.

<rucknium> And I don't know if anyone would be willing to try to implement and deploy something like that for Monero.

<rucknium> Any more comments on this topic for now?

Sorry, I was away

I have been looking to do multisig consolidation under FCMP++ N-of-N with presigned txs (and proof done later?)

No more that sketches, I have started implementing FCMP++ parts themselves to experiment. Will ask questions elsewhere if I have any

<rucknium> Thanks, DataHoarder

<jberman> nice!

no HTLCs, so no tx invalidation, but chaining is workable with fallbacks for non-cooperation

PTLCs?

<rucknium> 5. Transaction volume scaling parameters after FCMP hard fork (github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-11.pdf). Revisit FCMP++ transaction weight function (seraphis-migration/monero #44).

<articmine> I have uploaded 2025-11-02, which is the latest update

<articmine> I had the. proposed most recent weight

<rucknium> 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.

<articmine> Without the adjustments for powers of 2

<jberman> I started reviewing the latest and will complete my initial review within the next couple days

<articmine> Great

<articmine> Any questions?

<rucknium> jrkl23jlka: Did you want to comment in this agenda item?

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.

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),

while still permitting for transaction priority assignements--by placing transactions fees in the range that represents the priority of the transaction,

<articmine> How does this work with a fee market!

but at a finer resolution by specifically picking underrepresented fee values in the fee distribution, thus promoting that distribution to become more uniform,

much more like a predictable transaction queue representing transaction priorities.

Like that users picking fees in advance for offchain transactions (such as in payment channel or atomic swaps) won't be fingerprinted too badly.

<articmine> So instead of have five fee levels we have 5 fee ranges

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.

And clearly this does not requires consensus, just real-time, transaction-pool / blockspace based market dynamics.

<rucknium> They will be fingerprinted anyway since they will reference an outdated merkle state in the FCMP tree

<articmine> Yes this is not consensus

articmine: not really 5 ranges, all you are trying to do is get a flat fee distribution

<articmine> It adds noise around the fee levels

<rucknium> Custom wallet implementations that choose a deterministic fee would likely create spikes in the uniform distribution.

independent of quantization levels (u could have many bins, or treat 1 piconero as a bin), and that would work too

articmine: exactly, it adds WHITE noise around fees

<articmine> It is actually very interesting

<jberman> "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

<rucknium> @jberman:monero.social: Ah, thanks.

rucknium: then other wallets fix those spikes by spreading transactions around

and pushing those peaks on the pdfs down

*probability density function

<articmine> I proposed a 1000 block buffer for median changes over the current 10 block that should help with this

<articmine> It does create time for this kind of distribution

<rucknium> 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 ...

<rucknium> 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.

<rucknium> if honest wallets*

<articmine> The idea is to introduce noise. How statically sound this would be is a research project of it's own

<articmine> Statistically*

we are only talking about real-time fee dynamics

not long-range as articmine

<kayabanerve:matrix.org> @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.

<articmine> The good thing about this is that it can be implemented after the hard forl

<kayabanerve:matrix.org> Sorry for the interjection

<kayabanerve:matrix.org> @jberman:monero.social: which is one of the reasons why weight must be independent of the layers, yep

<articmine> jrkl23jlka: Yes like a day or so

<articmine> Fees are based on the long term median so there is more room timewise

we are talking about what is currently in the transaction pool

<articmine> I don't see a problem here

and fees should be based on market dynamics and transaction priorities, not history

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

<articmine> The fee is based upon the penalty that the transaction would attract.. This is part of the fee market

<articmine> Then of course there is supply and demand

<articmine> It is not like Bitcoin where increasing prices do not increase supply. In Monero increasing price does add block space

<articmine> So supply is increased

but its about transients in transaction numbers

real-time, instantaneous fees

not scalling

over long time ranges

<articmine> Yes that is also part of the picture

anyway, i think i made myself clear. uniform distribution is where the we hide the best

<articmine> The penalty is paid on the short term median which is 100 blocks

<articmine> So there is very short term scaling

it does not matter what happens 100 blocks ago, if the transaction pool is empty

<articmine> About 100 minutes

theres available block space and you can pay little fees

<articmine> jrkl23jlka: The block size limit does depend on the recent and past history

that is an almost orthogonal dimension

<articmine> I can go over this with you

<rucknium> Any more discussion of this item for now?

no

<rucknium> 6. FCMP alpha stressnet (monero.town/post/6763165).

<ofrnxmr> 1.5 coming soon. ooms largely fixed, i think

<rucknium> @jberman:monero.social already gave an update on stressnet improvements at the beginning of the meeting. Anything else?

<ofrnxmr> My only q is wen carrot? but jeffro not here

<jberman> Trying to get 1.5 out in the next couple days that should address OOM's and slow sync

<rucknium> We can end the meeting here. Thanks everyone.

<articmine> Thanks

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)

thank you for the meeting

DataHoarder: you talked about transaction chaining. how far are we from being able to do PTLCs?

s/PTLCs/point-time locked contracts

we need a per output timelock, any current proposals on that?

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

I'd recommend then looking at atomic swaps jrkl23jlka

what atomic swaps?

the btc one was using 2 time locks on teh btc side

<jack_ma_blabla:matrix.org> monero doesnt have HTLCs & isnt coming with fcmp++ fork

but it can have PTLCs jack_ma_blabla

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

<rucknium> DataHoarder: DataHoarder: Thanks

<gingeropolous> 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 mrelay.p2pool.observer/e/zqmHvsoKTk1vWTdM ]