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

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

<rucknium> 1. Greetings

Hi

Hello

👋

<spackle> hi

<rucknium> ping @jeffro256:monero.social

<jeffro256> Howdy

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

me: Helios and Selene updates and Share or Perish.

<jberman> waves

<jeffro256> Me: polishing and testing Carrot Rust library, preparing for alpha stressnet, reviewing FCMP++ code

<rucknium> me: Wrote an explainer about the 18-block reorg: rucknium.me/posts/monero-18-block-reorg . Thanks for anhdres for creating all the diagrams and jeffro256 and DataHoarder for reviewing early drafts. Set up performance visualizer for stressnet: stressnetnode1.moneronet.info (another node at stressnetnode2). Rel [... too long, see mrelay.p2pool.observer/e/yejs0boKNUV4QW5U ]

<jberman> me: alpha stressnet debugging, submitted some piecemeal crypto PR's used in the FCMP++ integration to the main monero repo

<rucknium> 3. Carrot follow-up audit (gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb).

me: awaiting fixes on monero for checkpoints / checkpointer further testing; also reproducing carrot / FCMP generators on go code

<jberman> (nice issue with the generators spotted DataHoarder )

<jeffro256> Cypherstack responded to the follow-up audit request with the following deliverables: github.com/jeffro256/carrot/blob/ma…udits/Cypherstack-v2.0-followup.pdf and github.com/jeffro256/carrot/blob/ma…ster/audits/Cypherstack-diagram.pdf

<jeffro256> The dependency diagram is much appreciated and may help readers understand the flow of enote construction much better

<jeffro256> TLDR; The Cypherstack follow-up result was generally positive, but encouraged documenting and implemting additional checks for robustness's sake where it does not greatly affect performance

<jberman> this diagram is very nice

<vtnerd> Me: got view balance keys tested and working in lws, just need to test outgoing spends as they are tracked differently internally

<jeffro256> Thanks to Cypherstack for this effort!!

<rucknium> Yes, thank you. More to discuss on this now, or should we wait until people have more time to review the materials?

<jeffro256> That's it for now

<rucknium> 4. FCMP Helios-Selene parameters rigidity (gist.github.com/tevador/4524c209217…ment_id=5772654#gistcomment-5772654).

It has been decided to use D = -31750123 instead of the current value. I'm in the process of updating the gist.

<jeffro256> I can't remember, does this affect the Crandall reduction technique or is it mostly a drop-in change for the parameters?

Should be a drop-in change I think.

For Crandall, only some parameters need to be changed. The algorithm will work the same way as the new prime has the same basic properties.

kayabanerve in Monday's meeting: " No, it'll be trivial. Just updating constants in Rust, and the ones duplicated in C++ by jeffro256 if any exist."

<rucknium> Anything more to discuss on this item?

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

<jeffro256> Maybe I can bring it up after the meeting as its slightly offtopic for this item, but I'd like to ask tevador where he/she currently stands on the double hash-to-point

<jeffro256> @hinto:monero.social

<jberman> (jeffro is referring to this issue: monero-project/research-lab #142)

<articmine> Sorry I am late

I'm quite OK with it since kayabanerve clarified the security implications.

<jeffro256> W.r.t collision resistance specifically?

Yes. FCMP++ relies on the collision resistance of Hp, while RCT does not.

<jberman> I don't have anything to add on PoWER rn. The status is there are some disagreements over design decisions that we discussed at length last week. We decided at the end that it seems ok for hinto to proceed with the currently proposed design on the PoWER issue, seeking to minimize complexity and we can review that impl

<jberman> @jeffro256:monero.social: have you budged at all on the issue (per connection vs per txs)?

<boog900> Something I think needs to be mentioned is PoW would need to be opt out when done per connection

<boog900> Otherwise we risk the tx getting stuck

<boog900> And it could still get stuck if too many opt out

<rucknium> Gossip networks are very fault-tolerant.

<articmine> I see PoWER for large transactions as a necessary evil until we address parallel processing of verification time.

<boog900> I would support making pow mandatory for all tx relay connections though

<boog900> Not just for only txs with more than 8 inputs

<articmine> I strongly disagree

<rucknium> But maybe we don't want to have an empirical test of how fault-tolerant they are on mainnet 😅

<jberman> @boog900: I would support that for p2p connections, and not for RPC connections

<boog900> yeah

<jeffro256> @boog900: What do you mean by making it mandatory for all tx relay connections but also opt-out ?

<articmine> PoWER makes those who live in the global south second class users of Miner. Just based upon climate

<boog900> @jeffro256: you can opt out but you can no longer send tx pool txs to nodes

<articmine> Second class users of Monero

<boog900> you can ony receive txs and send/receive blocks

<jeffro256> Ah gotcha. So similar to Bitcoin's distinction between tx relay connections and block relay connections ?

<jberman> @articmine:monero.social: the PoW used in PoWER is going to be as CPU intensive as verifying a single large input tx. This has been repeated x1000 times

<jeffro256> @jberman: I think I'm now less opposed to per-connection if an implementation can be done elegantly

<boog900> @jeffro256: yeah

<articmine> It is still a burden for someone to send a 2 in 2 out tx in +40 C weather

<articmine> Especially now that this is proposed for all transactions

<jberman> 2 in 2 out tx takes more CPU to construct than the CPU to construct this PoW (!!!!!!!!!!!!!!!!!!!!!!!!!!!!!)

<boog900> 1. they can use RPC

<boog900> 2. ^

<articmine> Per input

<hinto> hello, I don't have any inputs for the design, mostly worried about complexity and hacky interfaces

<articmine> RPC to a node in the first world

<boog900> a node in the rest of the world isn't going to suffer from the extra 0.01% CPU load

<articmine> If you force this on all transactions it is way more than .01%

<boog900> no its forced on connections who want to send txs, its still 1 per connection

<jberman> The CPU to scan the chain is like 99.9% more intensive than the CPU for this PoW

<articmine> So you double the verification time

<articmine> Cost

<articmine> To send transactions

<boog900> @articmine: no verifying the PoW only happens on a handshake not when a tx is sent

<jeffro256> @jberman: s/%/x perhaps? ;)

<articmine> I know, but now it is forced to send

<jberman> @jeffro256: haha yes

<boog900> @articmine: no its forced if you want to run your own node

<articmine> Correct

<boog900> which takes wayyyyyy more CPU

<jberman> I propose we move on from this discussion. Rehashing the same points x1000

<hinto> @jeffro256:monero.social: to respond to last week, I won't do wallet changes > <@jeffro256> I see the argument, I don't know if I'm entirely convinced, but yeah I can definitely start on that wallet API point

<boog900> @articmine: would you rather these non first world nodes be spammed with txs that take wayy longer to verify than PoW

<articmine> So we are back to the 2017 mess?

<articmine> @boog900: I would prefer the verification time issues be addressed with parallel processing

<rucknium> There's stressnet to discuss still and selfish mining mitigations.

<articmine> Then the impact of any spam is drastically reduced

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

<rucknium> I will limit discussion of this item to 30 minutes, if there are no objections.

<articmine> @hinto: My comment

<jeffro256> @articmine: I also want to move on, but for the record, parallel processing does nothing to mitigate the issue of invalid proof verification DoS

<articmine> There is no need to limit discussion on this

<articmine> I have nothing to add

<rucknium> @articmine:monero.social objected to the 30 minutes limit on this item, so it is open.

<jberman> I haven't had a chance to review the latest yet in depth

<rucknium> 7. FCMP alpha stressnet planning (seraphis-migration/monero #53#issuecomment-3053493262).

<jeffro256> Me neither, will look soon

<jberman> Alpha stressnet v1 launched :) we've had a few bugs which I'll talk about, and after this meeting will tag a v2 release fixing them

<jberman> Bug 1: windows / 32-bit machines couldn't sync as a result of using an unsigned long in a crypto function and expecting it to be 64 bits, issue first reported by mayhem69, fixed here: seraphis-migration/monero #118

<rucknium> Stressnet's hard fork from testnet will happen Friday.

<rucknium> The launch announcement is monero.town/post/6763165

<jberman> Prior to the above bug being identified, I had opened a PR to master implementing that crypto function (and the same bug was present there): monero-project/monero #10108

<jberman> My general thoughts: I would like to have the crypto changes included for the FCMP++ integration audited. I'm thinking about best plan for that, thinking about pointing to snippets of isolated code for an audit

<rucknium> This was a problem in the unaudited code that bridges the Rust FCMP and the monerod C++?

<jberman> This in particular was in unaudited code that speeds up a function that's currently in use in monerod

<jberman> It's more relevant for the FCMP++ integration (and was more important to speed up for the integration), because it's now called for all coinbase outputs (and transparent amounts) during wallet sync and daemon sync

<jberman> Daemon sync currently calls this function for coinbase outputs

<jberman> and some RPC's use it

<jberman> Bug 2: CLI transfer/sweep pre-fork was borked (also reported by mayhem69), fixed here: seraphis-migration/monero #122

<rucknium> Should this be an agenda item next week or open the discussion now? > <@jberman> My general thoughts: I would like to have the crypto changes included for the FCMP++ integration audited. I'm thinking about best plan for that, thinking about pointing to snippets of isolated code for an audit

<jberman> We can make it an agenda item for next week, I'll come with a fleshed out plan

<jberman> Bug 3: borked debug builds reproducing generators incorrectly (reported by @datahoarder:monero.social ), fixed here: seraphis-migration/monero #124

<jberman> That's all the bugs reported so far (and then a small display logging issue during the migration by @ofrnxmr:monero.social which will get to)

<rucknium> IMHO, it was amazing to see the compiler pause the C++ compilation to compile the Rust FCMP and then follow the progress of the FCMP tree building the database. The result of a huge amount of work by many people 🧡

^ I noticed the rust compilation messages as I was compiling monero and had to do a double take :)

<rucknium> I set up stressnet node monitors at stressnetnode1.moneronet.info and stressnetnode2.moneronet.info . Not much to see now since there's nothing happening on testnet, but it will come alive once the stressnet forks off.

<rucknium> The stressnet discussion room is at #monero-stressnet:monero.social and ##monero-stressnet on Libera IRC, IIRC.

on the note of updating carrot document to match: please define what H_p^1/H_p^2/H_p^3 or desired notation actually correspond in code (or pseudocode) as from the document alone it was unclear

<jeffro256> Will do

<rucknium> I released my xmrspammer package so that other users could produce spam: github.com/Rucknium/xmrspammer . IMHO, it's usable, but only lightly tested. Wait until after the stressnet fork to try it!

<rucknium> The plan is still to have a bigger stressnet after this alpha one, right?

also, if you end up seeing blocks with merge mining in FCMP++ stressnet- that means I got some p2pool-like setup to mine there as a bonus work :)

<rucknium> Somehow it needs to be communicated that if people want to participate in only one stressnet, they should participate in the second one.

<jeffro256> @rucknium: Ideally, yes

<rucknium> IMHO, it would be a good idea to do a double fork for that one. One fork to fork off testnet, but normal RingCT rules. Then spam for a few days. Then fork to FCMP rules. It's not an experiment if there's no control 😉

<rucknium> Anything else about stressnet?

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

<rucknium> @ofrnxmr:monero.social and @0xfffc:monero.social are trying to fix a rare bug that can halt block sync when rolling checkpoint enforcing is activated.

<rucknium> Qubic hasn't attempted selfish mining in a week or more and their hashpower is lower now.

Good if we really are down to rare bugs :)

<rucknium> Like I said in updates, I wrote this blog post about the 18-block reorg, aimed at the general Monero community member: rucknium.me/posts/monero-18-block-reorg

<rucknium> I think the post finally explains the purpose of the 10-block lock in understandable terms, just in time for rings to get deprecated 😆

<rucknium> But FCMP txs will have a similar issue. The exact mechanism is different.

something like the 19th-21st is when they did the last selfish attempts (minor)

<rucknium> Discuss Share or Perish? monero-project/research-lab #146

FCMP txs are even more fragile when it comes to 10+ block reorgs

Any questions or comments about SoP?

<rucknium> tevador: Right. I discuss that at the end of the 20-minute post :)

on the topic of the reorg, you can visualize their rings in blocks tool blocks.p2pool.observer/tx/d3e574c05…451b2dc625ba1cb9d2f4d6c352689c5ac7d

<rucknium> Soon I will dig into this and try to set up the Markov Decision Process analyzer for SoP. Now I am focused on helping get stressnet stressed.

<jberman> SoP seems the most promising proposal to me so far

For some long-time solution, right?

It's a good long-term solution for attackers <50%.

<jberman> Yes

<jberman> ^

>50% would need the Finality layer or Lucky transactions

I see

So not directly comparable

It's close to the best you can do with PoW only and a soft fork.

<venture> Hi. SoP doesn't require a consensus change or hardfork correct? "Just" gossip protocol to account for shares and miner's tip selection change?

<rucknium> IMHO, it would be a good idea to evaluate Monero's Difficulty Adjustment Algorithm (DAA) and alternatives for next hard fork. That doesn't fix selfish mining, but it could help a little. And controversial proposal: I think setting minimum tx fee based on network hashpower could be researched so that min fee stays roughly the s [... too long, see mrelay.p2pool.observer/e/pN-f1LoKbTc5UDNo ]

<bawdyanarchist:matrix.org> Difficulty adjustment is definitely a factor in selfish mining attacks

Uh, a new can of worms :)

The first step towards a better DAA would be to enforce strictly increasing block timestamps.

sorry, bridge went down midway, should come back up and removed offending line

<jberman> tevador: seems a simple rule to include for next hard fork

<rucknium> Need to resend this message to IRC: The debate about setting min relay fee higher or lower based on unpredictable changes in Monero's exchange rate could be solved by basing min fee on hashpower changes, IMHO.

<jberman> I think tying min fee to network hashpower is a valid research avenue and interesting idea

<radanne:matrix.org> Hey folks, just submitted a proposal at monero-project/research-lab #147, wishing you all happy reading, and looking forward to some feedback🙏 I hope it's all self-explanatory, as I may be somewhat scarce until the 19th, so my responses may not be instant, but I'll keep an eye on the Git page and he [... too long, see mrelay.p2pool.observer/e/lKnM1LoKeC1Oa2xH ]

Updated Helios and Selene gist with the hopefully final set of parameters: gist.github.com/tevador/4524c2092178df08996487d4e272b096

The new search conditions are G4 and C3. G4 gives us a green checkmark and C3 gives us nice base points.

s/G4/Q4

<sgp_> ty tevador!

<sgp_> for PoP, if an attacker has >50% for a single day, they could very likely cause >10 block reorgs over that 1 day time period right? Just to further establish a remaining risk

<venture> *SoP you probably mean. And yes. But I see it more as a feature than a risk compared to a PoS finality layer in which malicious behaviour is much harder to detect. The definition of "malicious" is also more subjective in PoS imho. Imagine a 34% / 66% split on consensus.

<sgp_> Sure, I only mean to say that the risk remains. I consider short-term instances of 50%+ hashrate to be unfortunately realistic