15:00:25 <br-m> <rucknium> MRL meeting in this room in two hours.
17:00:49 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1275
17:00:53 <br-m> <rucknium> 1. Greetings
17:00:56 <tevador> Hi
17:01:05 <rbrunner> Hello
17:01:16 <plowsof> 👋
17:01:56 <br-m> <spackle> hi
17:03:12 <br-m> <rucknium> ping @jeffro256:monero.social
17:03:24 <br-m> <jeffro256> Howdy
17:03:29 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:03:50 <tevador> me: Helios and Selene updates and Share or Perish.
17:04:11 <br-m> <jberman> waves
17:04:23 <br-m> <jeffro256> Me: polishing and testing Carrot Rust library, preparing for alpha stressnet, reviewing FCMP++ code 
17:04:54 <br-m> <rucknium> me: Wrote an explainer about the 18-block reorg: https://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: https://stressnetnode1.moneronet.info/ (another node at stressnetnode2). Rel [... too long, see https://mrelay.p2pool.observer/e/yejs0boKNUV4QW5U ]
17:05:12 <br-m> <jberman> me: alpha stressnet debugging, submitted some piecemeal crypto PR's used in the FCMP++ integration to the main monero repo
17:06:06 <br-m> <rucknium> 3. Carrot follow-up audit (https://gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb).
17:06:15 <DataHoarder> me: awaiting fixes on monero for checkpoints / checkpointer further testing; also reproducing carrot / FCMP generators on go code
17:07:51 <br-m> <jberman> (nice issue with the generators spotted DataHoarder )
17:08:36 <br-m> <jeffro256> Cypherstack responded to the follow-up audit request with the following deliverables: https://github.com/jeffro256/carrot/blob/master/audits/Cypherstack-v2.0-followup.pdf and https://github.com/jeffro256/carrot/blob/master/audits/Cypherstack-diagram.pdf
17:09:26 <br-m> <jeffro256> The dependency diagram is much appreciated and may help readers understand the flow of enote construction much better 
17:11:11 <br-m> <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 
17:11:14 <br-m> <jberman> this diagram is very nice
17:12:14 <br-m> <vtnerd> Me: got view balance keys tested and working in lws, just need to test outgoing spends as they are tracked differently internally 
17:13:05 <br-m> <jeffro256> Thanks to Cypherstack for this effort!!
17:14:52 <br-m> <rucknium> Yes, thank you. More to discuss on this now, or should we wait until people have more time to review the materials?
17:15:42 <br-m> <jeffro256> That's it for now 
17:16:21 <br-m> <rucknium> 4. FCMP Helios-Selene parameters rigidity (https://gist.github.com/tevador/4524c2092178df08996487d4e272b096?permalink_comment_id=5772654#gistcomment-5772654).
17:17:46 <tevador> It has been decided to use D = -31750123 instead of the current value. I'm in the process of updating the gist.
17:18:38 <br-m> <jeffro256> I can't remember, does this affect the Crandall reduction technique or is it mostly a drop-in change for the parameters?
17:19:21 <tevador> Should be a drop-in change I think.
17:19:54 <tevador> 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.
17:20:54 <rbrunner> 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."
17:20:57 <br-m> <rucknium> Anything more to discuss on this item?
17:22:15 <br-m> <rucknium> 5. Proof-of-Work-Enabled Relay ("PoWER") (https://github.com/monero-project/research-lab/issues/133).
17:22:23 <br-m> <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 
17:23:51 <br-m> <jeffro256> @hinto:monero.social
17:24:19 <br-m> <jberman> (jeffro is referring to this issue: https://github.com/monero-project/research-lab/issues/142)
17:24:52 <br-m> <articmine> Sorry I am late 
17:25:00 <tevador> I'm quite OK with it since kayabanerve clarified the security implications.
17:25:39 <br-m> <jeffro256> W.r.t collision resistance specifically?
17:26:25 <tevador> Yes. FCMP++ relies on the collision resistance of Hp, while RCT does not.
17:26:46 <br-m> <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
17:29:27 <br-m> <jberman> @jeffro256:monero.social: have you budged at all on the issue (per connection vs per txs)?
17:29:28 <br-m> <boog900> Something I think needs to be mentioned is PoW would need to be opt out when done per connection 
17:29:45 <br-m> <boog900> Otherwise we risk the tx getting stuck 
17:30:04 <br-m> <boog900> And it could still get stuck if too many opt out 
17:31:07 <br-m> <rucknium> Gossip networks are very fault-tolerant.
17:31:14 <br-m> <articmine> I see PoWER for large transactions as a necessary evil until we address parallel processing of verification time.
17:31:27 <br-m> <boog900> I would support making pow mandatory for all tx relay connections though 
17:31:45 <br-m> <boog900> Not just for only txs with more than 8 inputs 
17:31:57 <br-m> <articmine> I strongly disagree 
17:32:07 <br-m> <rucknium> But maybe we don't want to have an empirical test of how fault-tolerant they are on mainnet 😅
17:32:29 <br-m> <jberman> @boog900: I would support that for p2p connections, and not for RPC connections
17:33:17 <br-m> <boog900> yeah
17:34:05 <br-m> <jeffro256> @boog900: What do you mean by making it mandatory for all tx relay connections but also opt-out ?
17:34:26 <br-m> <articmine> PoWER makes those who live in the global south second class users of Miner. Just based upon climate 
17:34:34 <br-m> <boog900> @jeffro256: you can opt out but you can no longer send tx pool txs to nodes 
17:34:50 <br-m> <articmine> Second class users of Monero 
17:34:55 <br-m> <boog900> you can ony receive txs and send/receive blocks  
17:35:32 <br-m> <jeffro256> Ah gotcha. So similar to Bitcoin's distinction between tx relay connections and block relay connections ?
17:36:36 <br-m> <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
17:36:49 <br-m> <jeffro256> @jberman: I think I'm now less opposed to per-connection if an implementation can be done elegantly 
17:37:15 <br-m> <boog900> @jeffro256: yeah 
17:37:46 <br-m> <articmine> It is still a burden for someone to send a 2 in 2 out tx in +40 C weather 
17:38:07 <br-m> <articmine> Especially now that this is proposed for all transactions 
17:38:23 <br-m> <jberman> 2 in 2 out tx takes more CPU to construct than the CPU to construct this PoW (!!!!!!!!!!!!!!!!!!!!!!!!!!!!!)
17:38:34 <br-m> <boog900> 1. they can use RPC
17:38:34 <br-m> <boog900> 2. ^
17:38:37 <br-m> <articmine> Per input 
17:38:53 <br-m> <hinto> hello, I don't have any inputs for the design, mostly worried about complexity and hacky interfaces 
17:39:03 <br-m> <articmine> RPC to a node in the first world
17:39:40 <br-m> <boog900> a node in the rest of the world isn't going to suffer from the extra 0.01% CPU load 
17:40:30 <br-m> <articmine> If you force this on all transactions it is way more than .01%
17:41:04 <br-m> <boog900> no its forced on connections who want to send txs, its still 1 per connection 
17:41:12 <br-m> <jberman> The CPU to scan the chain is like 99.9% more intensive than the CPU for this PoW
17:41:25 <br-m> <articmine> So you double the verification time 
17:41:31 <br-m> <articmine> Cost
17:41:43 <br-m> <articmine> To send transactions 
17:42:16 <br-m> <boog900> @articmine: no verifying the PoW only happens on a handshake not when a tx is sent
17:42:49 <br-m> <jeffro256> @jberman: s/%/x perhaps? ;)
17:42:57 <br-m> <articmine> I know, but now it is forced to send
17:43:10 <br-m> <jberman> @jeffro256: haha yes
17:43:16 <br-m> <boog900> @articmine: no its forced if you want to run your own node 
17:43:26 <br-m> <articmine> Correct 
17:43:27 <br-m> <boog900> which takes wayyyyyy more CPU 
17:43:30 <br-m> <jberman> I propose we move on from this discussion. Rehashing the same points x1000
17:44:36 <br-m> <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 
17:45:17 <br-m> <boog900> @articmine: would you rather these non first world nodes be spammed with txs that take wayy longer to verify than PoW
17:45:18 <br-m> <articmine> So we are back to the 2017 mess?
17:46:14 <br-m> <articmine> @boog900: I would prefer the verification time issues be addressed with parallel processing
17:46:32 <br-m> <rucknium> There's stressnet to discuss still and selfish mining mitigations.
17:46:44 <br-m> <articmine> Then the impact of any spam is drastically reduced 
17:46:45 <br-m> <rucknium> 6. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf). Revisit FCMP++ transaction weight function (https://github.com/seraphis-migration/monero/issues/44).
17:47:16 <br-m> <rucknium> I will limit discussion of this item to 30 minutes, if there are no objections.
17:47:33 <br-m> <articmine> @hinto: My comment
17:47:54 <br-m> <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 
17:47:56 <br-m> <articmine> There is no need to limit discussion on this 
17:48:37 <br-m> <articmine> I have nothing to add
17:49:10 <br-m> <rucknium> @articmine:monero.social objected to the 30 minutes limit on this item, so it is open.
17:49:40 <br-m> <jberman> I haven't had a chance to review the latest yet in depth
17:52:19 <br-m> <rucknium> 7. FCMP alpha stressnet planning (https://github.com/seraphis-migration/monero/issues/53#issuecomment-3053493262).
17:52:28 <br-m> <jeffro256> Me neither, will look soon
17:53:12 <br-m> <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
17:54:50 <br-m> <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: https://github.com/seraphis-migration/monero/pull/118
17:55:20 <br-m> <rucknium> Stressnet's hard fork from testnet will happen Friday.
17:56:02 <br-m> <rucknium> The launch announcement is https://monero.town/post/6763165
17:56:09 <br-m> <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): https://github.com/monero-project/monero/pull/10108
17:58:33 <br-m> <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
17:59:59 <br-m> <rucknium> This was a problem in the unaudited code that bridges the Rust FCMP and the monerod C++?
18:00:45 <br-m> <jberman> This in particular was in unaudited code that speeds up a function that's currently in use in monerod
18:02:20 <br-m> <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
18:03:03 <br-m> <jberman> Daemon sync currently calls this function for coinbase outputs
18:03:38 <br-m> <jberman> and some RPC's use it
18:04:03 <br-m> <jberman> Bug 2: CLI transfer/sweep pre-fork was borked (also reported by mayhem69), fixed here: https://github.com/seraphis-migration/monero/pull/122
18:04:04 <br-m> <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
18:04:28 <br-m> <jberman> We can make it an agenda item for next week, I'll come with a fleshed out plan
18:05:18 <br-m> <jberman> Bug 3: borked debug builds reproducing generators incorrectly (reported by @datahoarder:monero.social ), fixed here: https://github.com/seraphis-migration/monero/pull/124
18:06:01 <br-m> <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)
18:07:30 <br-m> <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 🧡
18:08:30 <DataHoarder> ^ I noticed the rust compilation messages as I was compiling monero and had to do a double take :)
18:09:02 <br-m> <rucknium> I set up stressnet node monitors at https://stressnetnode1.moneronet.info/ and https://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.
18:09:50 <br-m> <rucknium> The stressnet discussion room is at #monero-stressnet:monero.social  and ##monero-stressnet on Libera IRC, IIRC.
18:10:14 <DataHoarder> 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
18:10:49 <br-m> <jeffro256> Will do
18:11:14 <br-m> <rucknium> I released my xmrspammer package so that other users could produce spam: https://github.com/Rucknium/xmrspammer . IMHO, it's usable, but only lightly tested. Wait until after the stressnet fork to try it!
18:12:39 <br-m> <rucknium> The plan is still to have a bigger stressnet after this alpha one, right?
18:12:57 <DataHoarder> 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 :)
18:13:23 <br-m> <rucknium> Somehow it needs to be communicated that if people want to participate in only one stressnet, they should participate in the second one.
18:14:14 <br-m> <jeffro256> @rucknium: Ideally, yes 
18:15:37 <br-m> <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 😉
18:17:04 <br-m> <rucknium> Anything else about stressnet?
18:18:26 <br-m> <rucknium> 8.  Mining pool centralization: Temporary rolling DNS checkpoints (https://github.com/monero-project/monero/issues/10064), Share or Perish (https://github.com/monero-project/research-lab/issues/146), and Lucky transactions (https://github.com/monero-project/research-lab/issues/145).
18:19:35 <br-m> <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.
18:20:04 <br-m> <rucknium> Qubic hasn't attempted selfish mining in a week or more and their hashpower is lower now.
18:20:53 <rbrunner> Good if we really are down to rare bugs :)
18:21:13 <br-m> <rucknium> Like I said in updates, I wrote this blog post about the 18-block reorg, aimed at the general Monero community member: https://rucknium.me/posts/monero-18-block-reorg/
18:22:18 <br-m> <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 😆
18:22:46 <br-m> <rucknium> But FCMP txs will have a similar issue. The exact mechanism is different.
18:22:52 <DataHoarder> something like the 19th-21st is when they did the last selfish attempts (minor)
18:23:25 <br-m> <rucknium> Discuss Share or Perish? https://github.com/monero-project/research-lab/issues/146
18:23:30 <tevador> FCMP txs are even more fragile when it comes to 10+ block reorgs
18:24:05 <tevador> Any questions or comments about SoP?
18:24:08 <br-m> <rucknium> tevador: Right. I discuss that at the end of the 20-minute post :)
18:25:08 <DataHoarder> on the topic of the reorg, you can visualize their rings in blocks tool https://blocks.p2pool.observer/tx/d3e574c05b01f5d74815e3894f55e1645f402cdbf0415877f49e752a71b0d376/c46ae7df060e45f6ac40f1340264f8b61267c84bf52e43d2b0ac3155a75f3380/9489923b1773c2575e3320b84357e451b2dc625ba1cb9d2f4d6c352689c5ac7d
18:25:17 <br-m> <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.
18:25:24 <br-m> <jberman> SoP seems the most promising proposal to me so far
18:25:56 <rbrunner> For some long-time solution, right?
18:26:49 <tevador> It's a good long-term solution for attackers <50%.
18:26:54 <br-m> <jberman> Yes
18:26:59 <br-m> <jberman> ^
18:27:35 <tevador> >50% would need the Finality layer or Lucky transactions
18:27:51 <rbrunner> I see
18:28:02 <rbrunner> So not directly comparable
18:28:27 <tevador> It's close to the best you can do with PoW only and a soft fork.
18:28:28 <br-m> <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?
18:28:41 <br-m> <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 https://mrelay.p2pool.observer/e/pN-f1LoKbTc5UDNo ]
18:29:26 <br-m> <bawdyanarchist:matrix.org> Difficulty adjustment is definitely a factor in selfish mining attacks
18:29:29 <rbrunner> Uh, a new can of worms :)
18:31:42 <tevador> The first step towards a better DAA would be to enforce strictly increasing block timestamps.
18:31:56 <DataHoarder> sorry, bridge went down midway, should come back up and removed offending line
18:34:01 <br-m> <jberman> tevador: seems a simple rule to include for next hard fork
18:34:23 <br-m> <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.
18:35:25 <br-m> <jberman> I think tying min fee to network hashpower is a valid research avenue and interesting idea
18:40:53 <br-m> <radanne:matrix.org> Hey folks, just submitted a proposal at https://github.com/monero-project/research-lab/issues/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 https://mrelay.p2pool.observer/e/lKnM1LoKeC1Oa2xH ]
19:17:05 <tevador> Updated Helios and Selene gist with the hopefully final set of parameters: https://gist.github.com/tevador/4524c2092178df08996487d4e272b096
19:17:44 <tevador> The new search conditions are G4 and C3. G4 gives us a green checkmark and C3 gives us nice base points.
19:18:52 <tevador> s/G4/Q4
21:28:58 <br-m> <sgp_> ty tevador!
21:34:14 <br-m> <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
22:26:26 <br-m> <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. 
23:32:12 <br-m> <sgp_> Sure, I only mean to say that the risk remains. I consider short-term instances of 50%+ hashrate to be unfortunately realistic