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

<jberman> I'll have limited availability in today's meeting unfortunately. I've been working pretty much exclusively on FCMP++ & Carrot stressnet issues. Repeating from last week, the issues we're seeing mainly seem to stem from existing issues in monerod. The FCMP++ & Carrot integration has had some hiccups, but for the most part the integration seems to be holding up well with hiccups patched

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

<rucknium> 1. Greetings

<articmine> Hi

<jeffro256> Howdy

<jeffro256> @jberman: I can second this, he's been working like a dog ;) I've also been working on working on existing issues in monerod which the stressnet exposed

<hinto> hello

<vtnerd> Hi

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

<jeffro256> It's been very interesting to say the least, and definitely highlights the importance of fixing existing issues of efficient transaction/block propagation b/c it'll be needed more than ever with 4x bigger txs

<rucknium> me: Keeping stressnet stressed. Keeping stressnet infrastructure (e.g. stressnetnode1.moneronet.info , stressnetnode2.moneronet.info , and seed nodes) alive and well.

<hinto> me: PoWER and looking into ZMQ for Cuprate

<vtnerd> me: legacy and balance keys now fully work in lws. Now working on an official docker image, as btcpayserver really needs it

<jeffro256> Yay!

<articmine> Me working on a write-up on the penalty and scaling.

<rucknium> 3. Proof-of-Work-Enabled Relay ("PoWER") (monero-project/research-lab #133).

<hinto> I've updated my proposal from last meeting: monero-project/research-lab #133#issuecomment-3377869740

<hinto> The P2P interface is slightly different than RPC/ZMQ, it's a 1-time challenge/solution exchange

<hinto> The RPC/ZMQ endpoint provides unique challenges per connection and holds them until an expiry time, solutions are verified at other TX relaying endpoints; these could be cleared occasionally or maybe cleaned if set.size() >= POWER_MAX_ACTIVE_NONCES

<hinto> Unique connections are still left undefined but I think this can be decided elsewhere, for now I assuming some network details

<jeffro256> Maybe I'm misunderstanding the proposal, but keeping a finite set of valid certificates is a DoS vector

<boog900> I still believe requiring RPC connections to be held for PoW is fine

<boog900> And simplifies the protocol a lot

<hinto> @jeffro256: If there is no limit the node's memory can be exhausted

<jeffro256> The protocol shouldn't require holding potential certificates in the first place

<jeffro256> It should be holding already completed PoW only

<boog900> Wallet2 and monero-oxide both hold rpc connections

<hinto> @jeffro256: Doesn't there have to be a limit on this as well?

<jeffro256> Yes, but the attacker would have to do X seconds of PoW to store 16 bytes on your machine

if this certificate/check can be generated from the connection details, it'd not be any extra data other than connection itself, bounded by connection limit

<hinto> @boog900: FYI this would bypass the state problems, RPC could exchange like P2P/ZMQ

even if it has to store x bytes, it'd be bounded by connection limit

<jeffro256> And worst case scenario, they get to re-use PoW for a separate connection after doing many, many thousand of iterations of PoW. Whereas worst case scenario w/ your current proposal is that connections doing 0 PoW can lock out honest peers

<hinto> Ok I see, I misunderstood the idea, I think that's acceptable

<boog900> @hinto: It only means people who don't hold RPC connections can't relay >8 input txs

<jeffro256> The cert also needs to be signed (preferably symmetrically for performance) by the validating node, otherwise the attacker can make up challenges in advance

<vtnerd> I guess lws gets to pass power along to client wallets? Otherwise the server has to do it which isnt ideal

<articmine> What kind of expiry on the cert?

<jeffro256> In other words, creation of challenges should be stateless (besides the node's permanent signing keys), otherwise it poses a DoS vector to honest peers. The onus of storing ones's own validation information should be on the proving peer

19:19:43 <br-m> <jeffro256> The cert also needs to be signed (preferably symmetrically for performance) by the validating node, otherwise the attacker can make up challenges in advance

(I again bring up TOTP as an example of how challenges could be computed with a time factor on the go, based on an agreed "secret" information)

<boog900> Is there an issue I am not seeing by requiring people to hold RPC connections?

<hinto> @jeffro256: Is this necessary on a 128-bit nonce?

<jeffro256> DataHoarder: But why share secret information when secret information does not need to be shared?

the TOTP result is shared

<boog900> @boog900: Wallet2 does it, monero-oxide does it. If we think this is acceptable, then we don't need to handle certificates, used nonces etc

<hinto> @articmine: I think 1-5 minutes from the request would be okay

not the secret part

the agreed secret part doesn't specifically need to be sent over, it can be incoming connection details + local random secret

to re-verify the TOTP() of this you just need the connection details + time it was generated at

<articmine> @hinto: That makes sense

<jeffro256> @hinto: In my stateless proposal, yes. Not necessary in your proposal since it's infeasible to guess a 128-bit nonce generated on a node you don't operate

that'd generate a nonce (of however many bits) you can verify when the proving peer brings back a PoW result (along with the above^)

<jeffro256> DataHoarder: How would the prover know your local random secret without asking you?

<jeffro256> DataHoarder: This is susceptible to front-loading attacks

they don't, the prover doesn't run TOTP

local node, when RPC connection that must be verified comes in, returns result of TOTP(details | secret | time) + time

<jeffro256> So the prover still has to request a challenge, yes?

yes, but this challenge doesn't need storage by node

it's also limited in time directly (As you get time when prover returns PoW, and can instantly remove these)

<jeffro256> Okay then I think we're talking about the same thing

<syntheticbird> @boog900: i love how no one answered you probably because they have doubt in mind but don't manage to put words on it.

<syntheticbird> (i see no issue)

<jeffro256> @boog900: Sorry, what specific actors you do mean by "people" and RPC to which software?

<boog900> Wallets holding RPC connections to monerod

<boog900> If we think this requirement is OK then we can just generate a random nonce on connection like we will do for P2P

<jeffro256> I think it should be optional, especially for local nodes. But I'm okay with supporting PoW for wallet->daemon connections, specifically for transaction submission endpoints

as I suggested last time it's maybe better to have out of meeting conversations, but isn't it generally that 1) node must be able to generate challenges and not keep per-challenge state (single global state is ok as it's fixed byte size) and 2) the prover must not be able to generate new nonces ahead of time (or collect too many without a defined

expiration date) and 3) valid nonces for PoW have to expire after a defined amount

<jeffro256> I wouldn't support it for other endpoints

unrestricted RPC could have it disabled, restricted RPC enabled?

<boog900> It would still work the same as your proposals, with an endpoint to get the challenge and an endpoint to submit

<boog900> Its just the challenge is for a specific connection so you cannot disconnect then reconnect and submit

<hinto> DataHoarder: PoWER is skipped on local/trusted interfaces

<jeffro256> DataHoarder: Agreed. State per success-post-verification is okay though, and is probably necessary. But yeah further implementation details of the exact should probably be discussed on the Github issue, not in here

post verification is bounded to RPC connection limits, so reasonable data usage there would be fine as it comes with a bound

<jeffro256> Not just RPC connection limits, but PoW recently performed

Right. RPC connects/disconnect (doesn't keep TCP connection open) so ports are not relevant.

If given expiration explicitly via generation these can be kept exactly as long as needed then removed away

<boog900> Tbf me and hinto have discussed it and he thought it would be unpopular to require wallets to hold connections.

<boog900> I disagree though and can't see an issue, it would simplify the protocol a lot.

<jeffro256> Oh hold connections?

<jeffro256> Yeah I wouldn't want to implement it like that

<jeffro256> It would probably break a lot of app developers' flows

<jeffro256> Just do PoW when submmiting a tx

<boog900> Wallet2 and monero-oxide both hold connections

<boog900> @jeffro256: As long as you can do more than 1 request per connection you can still do this

<vtnerd> one issue I’m seeing is with ZMQ router/dealer stuff. you can’t use those setups with PoWER probably

<vtnerd> I dont know of anyone using those setups though

<boog900> @jeffro256: Fwiw they will still work as long as you don't send a > 8-input tx

<jeffro256> @boog900: Is wallet2 really doing that? Hmmm... Probably not ideal for remote node privacy

alternatively have send_raw_transaction allow a list of transactions :)

<hinto> FWIW I agree it would simplify everything, although agree with jeffro

<boog900> @jeffro256: Why? Better than reconnecting for every request

<articmine> @boog900: Which is not a serious issue

<hinto> I think we can further discuss on the issue, should we move on?

<jeffro256> @boog900: Why would re-connecting ever be worse for privacy? Re-connecting means that RPC requests from different wallets with the same host have some mixing. It's not much, but it's something

<boog900> @jeffro256: True but that's minimal and breaks my RPC PoWER idea D:

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

<articmine> Any questions on this?

<articmine> In particular the square root weights

<articmine> ...and quadratic fees

<articmine> Seeing none I will continue with my writeup and suggest we move on

<jeffro256> For the record, I still NACK for the same reasons as last week, I just don't have anything new to add at the moment

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

<rucknium> There was a new stressnet release, version 1.2: github.com/seraphis-migration/monero/releases

<rucknium> With large blocks, nodes are having problems staying connected. The release fixes a minor cause of the connection problems, but many more remain.

<jeffro256> Working through issues at the moment. Is there any specific issue someone wants to bring up or re-iterate?

<rucknium> I am glad that you and jberman are invested in this stressnet ;)

<rucknium> As you said, many of the issues are longstanding monerod issues, not specifically FCMP issues

<rucknium> And we saw most of them on last year's stressnet

<rucknium> Last year's stressnet just fixed the truly fatal issues, like irreparable netsplits.

<mayhem69:matrix.org> I'm not sure if its an existing issue with monerod or with the stressnet version but these bans that are happening on stressnet are causing connectivity issues between peers:

<mayhem69:matrix.org> seraphis-migration/monero #180

<rucknium> AFAIK, there is no easy way to clear all of your nodes' bans without restarting the node.

<rucknium> Can some console command and/or RPC method be written to clear all bans?

<rucknium> Even better, write something that can clear bans by CIDR subnet notation. Then you can clear all bans with a large CIDR, but clear specific subnets, too.

<mayhem69:matrix.org> There is a script on of the guys made to clear the bans via the RPC which works but covers up the cause of the bans. If the bans are legit and supposed to happen then that is fine, the script that be used to clear the bans periodically.

get_bans already exists, and set_bans as well. set_bans with ban: false should unban?

could make something that is CIDR aware

<jeffro256> There's this script which I haven't tested yet: seraphis-migration/monero #180#issuecomment-3405320886

<jeffro256> No idea if it works or not

<jeffro256> @rucknium: This would be nice

<mayhem69:matrix.org> Yes that is the script and its using get_bans and set_bans and it seems to resolve the issue. Just figured I would bring it up b/c it is annoying to have unban to get connectivity and not everyone running a node is doing so and as such I find my node gets isolated from the network quite often.

<mayhem69:matrix.org> Anyway if this is expected behavior then that is fine. Just figured I would bring it up in case its not.

<rucknium> An external script is useful, but having a dedicated way to do it would help ordinary stressnet users

<rucknium> No, the bans aren't supposed to happen, but they do because nodes think you are misbehaving when the network has heavy load.

<jeffro256> Might be more serialization issues. We're looking into it. Better logging is a must going forward IMO

<rucknium> IIRC, on last stressnet, the ban timeout was set low manually in a stressnet PR

<jeffro256> Or other levin limits

<jeffro256> @rucknium: That could be done here

<rucknium> Logging can stress a node too, AFAIK. That's double stress :D

<spirobel:kernal.eu> aren't the bans cleared on restart? > <@rucknium> Can some console command and/or RPC method be written to clear all bans?

<rucknium> @spirobel:kernal.eu: Yes, but often you don't want to restart.

<rucknium> Last stressnet, restarting was very annoying since the node re-validated the entire txpool on restart. That's fixed for this one.

<rucknium> I had a few out-of-memory crashes on an 8-GB RAM VPS with log level 2.

<mayhem69:matrix.org> yes I notice bans occuring even when there is much load, seems to happen on my node when its syncing. And then its exacerbated b/c my node will try to connect to a node multiple times where I am banned and then my node bans then and its just a death spiral of bans. I will try to add more info to the issue as I find it but I a [... too long, see mrelay.p2pool.observer/e/4tbFlL8KblM1WXNu ]

<rucknium> Here it is: spackle-xmr/monero #7 "Peer ban duration to 2 minutes"

<jeffro256> Will add to v1.3 TODO list

<jeffro256> thanks

<rucknium> Is there a specific goal with stressnet debugging, such as "network can smoothly handle txpool size X and block size Y"?

<spirobel:kernal.eu> @rucknium: would it make sense to split the concept of peer bans from an exponential back off? usually in a distributed system you would do an exponential back off when a queue gets overloaded.

<rucknium> This isn't the final FCMP stressnet, of course, but as the issues are being chipped away, it could be good to know when the, uh, sculpture is considered complete.

<rucknium> monerod always feels ban-happy to me.

<spirobel:kernal.eu> @spirobel:kernal.eu: this peer ban death spiral sounds more like this type of situation when a back off would make sense compared to a ban

<jeffro256> Not yet, we didnt't have a specific mind in goal going into alpha, but you and everyone else have found a laundry list of good issues to work on in the short term. Perhaps future time period can have more focused goals

<rucknium> Occasional bans on mainnet wouldn't be as much of a problem. On a small stressnet, you are banning one of only a few possible peers.

<articmine> All these improvements on network efficiency also harden Monero against spam and DDOS attacks > <@rucknium> Is there a specific goal with stressnet debugging, such as "network can smoothly handle txpool size X and block size Y"?

<jeffro256> It's hard to control measurement of "smoothness" on an asynchronous network of peers which you don't control

<jeffro256> But yes, I agree that more specific goals should be finalized before a final stressnet

would the final stressnet have any block verification improvements (or multithreading?)

it's still quite noticeable when mining as doing submit_block (or on miners) they will keep mining the old template for a while, as monero still has not verified the submitted block via RPC and this takes 5-20s

<jeffro256> Yes, it should. There are a few big CPU-time improvements in review at the moment

this effectively makes that time in between "lost" for miners

<jeffro256> For example: monero-project/monero #10157 should help that issue w/ large mempools

<spirobel:kernal.eu> how is your impression of the current peer ban list code? I just know from the wallet work, that rpc requests from the wallet also ended up on this ban list and it felt like the bans were sprinkled into the code base. > <@jeffro256> It's hard to control measurement of "smoothness" on an asynchronous network of peers which you don't control

<boog900> IMO monero should do what bitcoin does and relay blocks after checking PoW but before verifying txs

<jeffro256> Assuming the change concept is sound, #10157 will be extended for FCMP++ txs

<jeffro256> There's also: seraphis-migration/monero #101

that is done by P2Pool now boog900

<rucknium> @boog900:monero.social: monerod doesn't do that now?

so everyone benefits, not just P2Pool blocks

<boog900> yeah I know but we shouldn't rely on that IMO

no, it has to verify transactions first

or sending bad blocks to other nodes causes them get banned

<rucknium> In most circumstances, I guess it won't matter much if everything works smoothly with fluffy blocks.

<jeffro256> @boog900: I've also thought about this. It's not a bad idea. I wonder how it would affect network health with a miner of similar hashpower to Qubic ~33%, willing to cause disruption for no return

<jeffro256> @rucknium: No, it verifies all consensus rules and input proofs before relaying

10157 looks good. specifically, if the received block is for the expected next height and all txs in mempool were verified to be valid, shouldn't this block have a quicker verification time? Or is the verification re-triggered?

<jeffro256> DataHoarder: It should yes. Transaction input verification is only re-triggered if the dereferenced chain state for a transaction is changed, which will only happen in a >10-block reorg

then 10157 would cover these delays seen while mining, good.

<jeffro256> If it works, yes, it should.

<rucknium> More on stressnet?

<rucknium> Thank you all community members who are running stressnet nodes 🧡

<rucknium> 6. Mining pool centralization: Temporary rolling DNS checkpoints (monero-project/monero #10064), Share or Perish (monero-project/research-lab #146), and Lucky transactions (monero-project/research-lab #145).

checkpoints, still waiting for fixes. If we can get a proper repro case (via modified submit_block on known monero state) it'd be great, that way can attach a debugger and look at it.

Longer term splitting of the code paths as written in other channels makes more sense later on

Qubic broke something last week on their side and while fixing it they re-enabled selfish mining for a few more days, before it being disabled. They managed several reorgs of varying depths (some 5-7?) with ~1.6-1.8 GH/s.

They currently stay at around ~1.2 GH/s and have decided to withhold bonus XMR payments from miners after a vote to attempt to prevent their price going lower. Mining/marathon schedule unchanged.

<rucknium> Thanks for keeping up with the Qubic movements, DataHoarder. What is "bonus XMR payments"?

Before, if price at end of epoch was > than an amount (at start of epoch) miners would receive some XMR (converted to their token) in their payments. this was part of their profit calculations

if it was below, it was instead converted to qubic and burned. now any xmr they find will always be burned.

(their people kept complaining that miners dumped too much qubic on each payout)

I don't think it's relevant to discuss for MRL, but an interesting note that has made them even less profitable compared to XMR or XMR+merge mining

<rucknium> They are reducing the incentive to mine with Qubic now?

<articmine> DataHoarder: The classic bear raid approach

It was an incentive originally thought to reduce selling pressure (if you don't sell price will go up which means more Qubic for you next week and so on)

it ofc, when they attracted short term miners, caused more selling pressure

This was the reasoning on their side to why stop now, Rucknium: irc.gammaspectra.live/36558af247094870/image.png

but yes. there is no extra incentive except you get Qubic instead of something else

I think further questions around that could go onto -offtopic or -lounge if on topic enough ^\

<articmine> Thanks for the Qubic update.

<rucknium> For next week, should this go on the agenda? github.com/hbs/MoneroMisc/blob/master/CARROT-discussion.md

<rucknium> It suggests allowing user to not have an outgoing view key that can see outbound txs.

<rucknium> There was discussion in #monero-research-lounge:monero.social about it.

<articmine> I say let the discussion in Lounge continue first.

<articmine> If there is some loose consensus there then bring it here

There were some issues found with current schemes that would break current carrot construction if some of the keys were made the same, and the alternative was for users to keep using legacy wallets (with the lack of forward secrecy)

<rucknium> @articmine: Alright.

<rucknium> We can end the meeting here. Thank you everyone.

<articmine> Thanks

articmine: Legacy wallets also get forward secrecy under Carrot (from an attacker who doesn't know a public address). They also get Janus attack protection.

My recommendation would be to allow users to generate a legacy wallet (with k_s and k_v) instead of a new wallet (with the new keys, including the outgoing view key). This has good plausible deniability because all wallets made before the fork are legacy wallets anyways.

New wallets should definitely not be constructed with k_ps = s_ga because: (1) Such use was not part of the audit. (2) Doing so loses internal forward secrecy. (3) It's impractical because it needs the private spend key to scan for owned enotes.

*k_ps = s_vb

<jberman> On stressnet: taking stock and looking at the issues, there is a lot we can solve in the short term/medium term to improve daemon performance before we hit a wall. I think we should continue to knock out these issues and then re-assess upon hitting a wall

<jberman> Clearly the daemon is having issues with a 300mb pool and 5mb blocks, so I think a rational immediate goal is for the daemon to not have issues at these levels

<jberman> Examples of issues with clear fixes that we can solve short/medium term:

<jberman> Example1: daemons dropping a connection that finds a fluffy block >4MB. That is a clear issue with a simple fix (that we've now rolled out in alpha stressnet v1.2)

<jberman> Example2: daemons re-relaying every complete tx in their pool every x interval causing dropped connections. We know how to fix that (tx relay v2 massively helps, and IMO this PR is helpful too: seraphis-migration/monero #174)

<kayabanerve:matrix.org> tevador: That sounds like the reasonable and practical way to make a new wallet without an OVK