<spirobel:kernal.eu> sorry using tx_key was never the right solution. after supplying the key once you cant proof anymore in the future through this route ... also after wallet recovery you dont have access to txkeys anymore

<spirobel:kernal.eu> > <@ofrnxmr> Currently most / all external services ask for tx keys instead of proofs (bisq's auto, explorers, etc). Deprecating would just be deleting the endpoints afaict, and then getting every wallet to provide proofs in their place (cake, monfluo, probably gui, feather, monerujo and every other wallet display they key on the tx details)

<spirobel:kernal.eu> i think the reason this catched on was that it was more accessible in the ui of the wallets ...

<jeffro256> It affects Carrot schedule, so yes > <@rucknium> @jeffro256:monero.social: ^ Should it?

<interestingband:matrix.org> Why does it affect ? Another audit ?

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

<jeffro256> @interestingband:matrix.org: Decision on design change, change to Carrot spec, changes to carrot_core, integration of those changes in wider FCMP++ codebase, etc. Another follow-up audit would be good, but can be done in parallel IMO, depending on how the change is implemented

<interestingband:matrix.org> Is it a sweet spot between small and big changes where schedule is affected but audit is still optional ?

<interestingband:matrix.org> Or it's a sweet spot of uncertainty where nothing is clear and therefore no one knows what is going to happen ?

<interestingband:matrix.org> LOL

<gingeropolous> im kinda double booked during meeting time. my updates - fun with monerosim. SoP work: github.com/Fountain5405/monerosim/b…/assets/sop/mrl_meeting_20261021.md . Also started digging into antiproxy work, mostly laying down baseline data . Also, stressnet.moneroworld.com is a thing . Further scale wins - can [... too long, see mrelay.p2pool.observer/e/vJywxrYLa1M5OUtQ ]

<jeffro256> @interestingband:matrix.org: More this. Also not optional, but parallizable with the 6-month wait period

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

<rucknium> 1. Greetings

<syntheticbird> Hi

<ofrnxmr> Hello

Hi

<jpk68:matrix.org> Hello

<jeffro256> Howdy

<vtnerd> hi

<thomasbuilds:matrix.org> GM

Hello

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

<jberman> waves

<rucknium> me: Doing more analysis for my proposed eclipse attack fix: monero-project/monero #11527

me: Share or Perish and relative locks

<vtnerd> me: adding more tests to the p2p-ssl patch. specifically ping backs (async_connect) and socks (add_connection) need testing. the normal flow (connect) has functional tests

<thomasbuilds:matrix.org> me: more audits

<gingeropolous> me: details above. SoP sims, antiproxy sims, optimizations

<jeffro256> me: Handling monero-project/monero #11586. Opened PR to Carrot spec here: jeffro256/carrot #16. Trying to keep changes simple. Also, reviewing upstream PRs and keeping my PRs up-to-date.

<jberman> me: upstream FCMP++ integration PR's are ready for review, stressnet ongoing

<rucknium> 3. get_tx_key/check_tx_key doxes sender in 2-out tx (monero-project/monero #11586).

<syntheticbird> The more you learn, the more you learn

<jeffro256> Spec PR is here: jeffro256/carrot #16

<interestingband:matrix.org> The 1st question is why it wasn't captured during audit ?

<jeffro256> I should have a carrot_core PR open in the next couple days

<jpk68:matrix.org> @jeffro256:monero.social: Will carrot-rs be updated for this, and the earlier re-binding change?

<jeffro256> @interestingband:matrix.org: I have also asked myself this. My guess is that since it's a technique that was sort of implied in the spec, and used in existing Monero code since forever, it was easy to overlook

Is there a reason to support external change enotes? Jamtis only has internal self sends.

<interestingband:matrix.org> My guess ? Ask Opus 5.5 or any other AI

<interestingband:matrix.org> it was rhetorical question, LOL

<jeffro256> tevador: So you can make InProofs/OutProofs to yourself. Not much else AFAIK

<syntheticbird> Terrible: Your worst enemy (AI) actually has a great point.

I think it would be better to remove the external self sends entirely.

<ofrnxmr> My 2c is that the specific get/check txkey doesnt really need to be deprecated, just that wallets and providers need to stop using it for public proofs (it is a secret key), ans should he giving users a more simple route to tx proofs. (like displaying it on the same page as the tx)

<syntheticbird> @ofrnxmr: let's make the "trusted nodes" checkbox useful

You mean rely somehow on the goodwill of everyobdy doing apps on doing the right thing?

<jeffro256> Yeah I was honestly impressed that Claude found the issue

In Carrot, *every* recipient learns the d_e, this is unrelated to tx key proofs.

github.com/monero-project/monero-si…uides/monero-wallet-cli.md#L96-L100 so it appears this issue was documented in CLI user guide

<rucknium> rbrunner: rbrunner: I agree with your sarcastic meaning. Only way to prevent services from using it is to make it very difficult, and make the upgrade path easy.

<interestingband:matrix.org> @jeffro256: It has been discovered 5 years before that review in my local environment by the same model by accident in the very beginning, but it felt like it's not the biggest thing I'm gonna discover in the end

<jeffro256> tevador: How is it unrelated? d_e is the analougue of the tx_key in Carrot

> Note that this third party, if knowing your own address, will be able to see how much change was returned to you as well.

<interestingband:matrix.org> Also I'm not sure how you can reason what about the fix without having a big picture how your protocol is gonnab be used

<ofrnxmr> rbrunner: No, i mean its a misunderstanding. Everyone copied their homework. Wallet A provided keys, and never proofs, so wallet B did as well. We just need to talk to the wallet providers (and bisq, onion explorer etc) and have them support proofs

<interestingband:matrix.org> That's the main reason why audit didn't capture

I mean it's unrelated to any use of the RPC to share the tx key, it's automatic. Apologies for bad phrasing.

<syntheticbird> selsta: well that kinds of breaks the whole claude is smart myths all of the sudden

<syntheticbird> if it was documented already

<jeffro256> tevador: Oh yeah I see, yeah that's why it was much higher impact than the existing issue

That's the main reason why it needs to be fixed in Carrot. It's no longer "be careful when sharing your tx key".

<ofrnxmr> @rucknium: Its not actually a huge leak iiuc. The service needs to know your primary address, and there cant be a subaddress as a recipient (iirc)

<jeffro256> selsta: Ah nice. NGL I've never looked at this guide in my life, but it's interesting that someone knew about it, but didn't think to put that notice anywhere more prominent

<rucknium> The service might ask for a refund address and users may put their main address in that field.

Not yet fully clear to me. Is this the crucial sentence on that page: "Note that this third party, if knowing your own address, will be able to see how much change was returned to you as well."

<ofrnxmr> Yes

<ofrnxmr> But there are 2 subjects in one. The tx key, and carrot

Hmm. But the "can trace the sender of transaction" part that jeffro mention in his problem description is missing

<ofrnxmr> I think people evaluating carrot fix is more important

<ofrnxmr> rbrunner: They can learn the value of the change output

Anyway, maybe pointing the way to Claude is all that was needed ...

<jeffro256> rbrunner: That is sort of implied by being able to see what the receive address is of the change enote. A third-party can assume that if receiver in 2-out -> other address is change -> owner of address is sender

<ofrnxmr> @ofrnxmr: This is whats currently happening on stressnet for legacy keyed wallets (passively)

<jeffro256> Combine this with small ring info, and smart third-party may be able to probabilistically learn info about tx graph

I think I start to see

That's why only 2-out transactions are in danger

Or, in most danger

<ofrnxmr> @jeffro256: Woukdnt the know (not assume) that the other output is change, and that the address is the owners, since that is the only combo that works

<ofrnxmr> 3+ out, subaddresses, non-change, dont work (..iiuc)

<jeffro256> Only 2-out is in danger b/c of the cryptographic way that the shared ephemeral tx pubkey is constructed

<jpk68:matrix.org> So this proposed fix will make InProofs impossible for most transactions? My bad if I'm misunderstanding something

<jpk68:matrix.org> Due to it affecting 2-out transactions

<jeffro256> Yes

<ofrnxmr> jeffro256/carrot #16 << this one, right jpk?

AFAICS only InProofs for self sends will be impossible.

<jeffro256> Yes?

<jpk68:matrix.org> Is there any other potential solution without these downsides?

<jeffro256> A) Put 2 ephemeral pubkeys for a 2-out tx, doubling scanning time for 2-out txs. B) Removing Janus protection

<jeffro256> tevador: I need to double check, but I think so

<jeffro256> Or C) something I haven't seen yet

Er ... just ask Claude? :)

<syntheticbird> "Claude make monero post quantum. Make no mistakes"

Now that was a bit mean, I know

<slowbeardigger:matrix.org> Use google gemini, ofc yall have to use the best one

Is s_sr^ctx insufficient for an InProof?

<jeffro256> Yes, because an InProof prover requires that the discrete log between D_e and s_{sr} is k_v

<interestingband:matrix.org> list requirements for this part of protocol and verify in the context of involved parties that will use InProof

<jeffro256> There's isn't any ECDH to speak of in an internal scan

<interestingband:matrix.org> any other reply is just an opinion

The purpose of an InProof is to prove that an enote was received, that's not directly related to discrete log.

<jeffro256> @jeffro256: And provide s_sr itself

<thomasbuilds:matrix.org> if this is needed I'm willing to propose a fix with claude

<jeffro256> tevador: It's both. It decodes a received enote, and signs a message with a Schnorr signagture using k_v as the privkey

<thomasbuilds:matrix.org> maybe it finds C > <@jeffro256> Or C) something I haven't seen yet

<jeffro256> If you simply want to prove that an enote was received to an address for a specific amount, then yes, you can provide s^ctx_sr

<jeffro256> But InProof also lets you sign messages that third-parties can't

I'm pretty sure there is a solution. It might require an extra SecretDerive call or something like that.

<interestingband:matrix.org> @thomasbuilds:matrix.org: It did in my case, but it wasn't isolated question

<rucknium> Anything need to be decided about this issue today? Or go think and come back next week?

<jeffro256> If we can use a Janus mitigation from here github.com/monero-project/research-lab/issues/62, and not reveal d_e, then that would work

<jeffro256> But the mitigations which are backwards-comptible with the current addresses typically have some compute or size overhead

<interestingband:matrix.org> You are trying to find math ops to meet algebraic equations, while cryptography requires much more and with proofs, otherwise It's all insecure

I prefer to keep the current 16-byte Janus mitigation.

It's a very good fit for Jamtis, which reuses the anchor field to encrypt the address index, which is a very efficient solution.

<rucknium> 3. FCMP++ to-do list status. Programming tasks (seraphis-migration/monero #53). Reviews and audits (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed). FCMP++ Integration Audit Overview (seraphis-migration/monero #294). Network upgrade [... too long, see mrelay.p2pool.observer/e/7JbCyLYLQS1Kbkpn ]

<jeffro256> mx25519 got merged yay!

<jberman> FCMP++ upstream consensus integration PR's open for review, LLM comments all addressed

Astra suggests self-send receipts using a per-output opening secret plus a `k_v` signature, with the commitment explicitly binding both address keys and the transaction context as a potential C

<jberman> RFQ for phases 2&3 integration audits has gone out and we're fielding quotes

<jberman> Circuit + gadgets Least Authority audit is ongoing

<jberman> Multisig in progress

<jberman> Carrot tx proofs also in progress (the prior discussion item)

<jeffro256> selsta: This would probably break the PQ migration by leaking k_v

<interestingband:matrix.org> LOL

<interestingband:matrix.org> @jberman:monero.social Is it possible to public anywhere scope for the upcoming or ongoing audits ? Ideally as is ?

<interestingband:matrix.org> I mean what exactly will be audited

<jeffro256> Unless A) I'm misunderstanding what's being proposed, or B) there is some way to indirectly bind such that the switch commitments property is held and doesn't reveal k_v directly

<interestingband:matrix.org> human friendly from is ok too

<jberman> @sgp_:monero.social: want to share the doc sent out for the RFQ? That doc clarifies scope

<interestingband:matrix.org> I just needed that for evaluation of what is audited and what is not

jeffro256: will let it refine with your concern and double check

<jberman> @sgp_:monero.social: RFQ for both the integration audit + the ongoing circuit + gadgets audit would be appreciated (looking for the latter rn)

selsta: It would be nice to have it output a proper formalization using Carrot notation. I did not quite get what the AI is proposing.

tevador: will send it in a paste

<rucknium> 4. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

<jberman> Planning to put out a v3.1 release today that includes the already merged fixes into the stressnet branch (including a fix for reopening wallets with GUI)

<rucknium> I messed up the agenda numbering. Two number threes. Anyway, will fix from now on.

<ofrnxmr> @jberman: gui qt6 now too?

<jeffro256> Thanks to selsta for fixing the GUI issue

<ofrnxmr> (Get to test the unrelease "major" gui update)

<jberman> @ofrnxmr: Yep can include that too

<ofrnxmr> Its merged on master on gui repo, so i assume its included, i think

<jberman> Yea I just have to update the branch I'm using for these builds

<jberman> I also want to check logs during the spam period to make sure tx relay v2 is holding up as expected, and then the upstream tx relay PR should be ready for upstream merge

<jberman> I have logs, just need to review them

<ofrnxmr> There were some xmrack review finsing that should be addressed soon

<jberman> I can't recall if there are more beyond the PR's xmrack opened (and have been merged into the stressnet branch as well)

<jberman> FWIW I personally don't mind people posting solid AI reviews in issues in the seraphis-migration repo so we make sure to keep track of them that way

<rucknium> 6. Relative time locks (monero-project/research-lab #161). Consensus code (seraphis-migration/monero #507).

<rucknium> Since last time this was discussed, tevador made the PR: seraphis-migration/monero #507

I'm not sure if the base branch for the PR is correct. It should be whichever branch gets the consensus changes.

It would be nice to have it reviewed and merged for the audit.

<jeffro256> Base branch of fcmp++-stage is good

<jberman> Ya I made some changes over in in the upstream PR's that would conflict with this, and the issue UkoeHB pointed out in #445 shouldn't apply after those changes

Btw, I decided to increase the lock time to 3 days, which is more user friendly (channel force close on Friday gives the user until Monday to react).

<jberman> I can review it and get it included in the upstream PR's as well. At this point this concept has had quite a bit of time for people to voice objection to payment channels imo

Thanks

<rucknium> 7. Share or Perish (selfish mining mitigation) (monero-project/research-lab #146).

<rucknium> I looked a little into the code that the researcher here shared with me: monero-project/research-lab #146#issuecomment-5978803129

<rucknium> It was nice of them to share the code. IMHO, the code is OK, but not amazing.

<rucknium> It looks like there was heavy LLM usage.

I made some updates to SoP in the last week. gingeropolous: thanks for the report, it seems you independently discovered the issue I fixed yesterday.

<rucknium> They try to attack the protocol with stubborn mining and sort of do a grid search of possible parameters that could give the adversary an advantage.

<rucknium> IMHO, it would be premature to endorse SoP without a more exhaustive analysis, like putting it into an MDP (Markov Decision Process).

<rucknium> I think that if you leave stones unturned, a nasty strategy could be lurking under one of them.

<rucknium> And that's the same weakness with @gingeropolous:monero.social 's experiments. AFAIK, there is no way for monerosim to simulate enough scenarios to try to cover everything.

<rucknium> But monerosim is useful for catching other issues, like the block minor version.

<gingeropolous> oh i will drive the bots to find all the stones

Agreed. People can release their LLMs on it. I'll freeze the specs for now unless a major issue is discovered.

<rucknium> The selfish mining strategy against Nakamoto consensus was developed first. Stubborn mining was a small improvement. Then, MDP was deployed against the problem and a little more profit was squeeze out of Nakamoto consensus for the adversary.,

<rucknium> @gingeropolous:monero.social: What's your plan for that?

tevador: jeffro256: this is the LLM proposal, hopefully it's not too sloppy irccloud.com/pastebin/863OFA8r

I think the biggest potential issue of SoP is that the network temporarily splits due to the subjective fork choice rule. The attacker can induce this by release a block at the boundary of being late. But this is a trade off. But unlike PoP, the split is quite limited (1 block + 32 workshares)

<rucknium> IMHO, what's needed is to put SoP into an MDP framework and count the states. If there are too many states to fully solve, then you could try a modified MDP with reinforcement learning. Modified MDP with reinforcement learning has been used recently for more complex selfish mining countermeasures that have too many states to feasibly solve in traditional MDP.

<gingeropolous> current plan is to run the sims with the new spec, and then direct the llm to attack it. But yeah a more formal approach would be welcomed. i could probably plug in that paragraph and it would get to work

<rucknium> Sounds good.

<rucknium> More on this issue?

<gingeropolous> yeah 2 questions

<gingeropolous> it was in the note. When two miners find a pool share for the same slot (same minor_version), does each count, or one per slot? We'll count one, first seen.

<gingeropolous> Should a share arriving re-run the fork choice, or only a block? monerod only re-runs it on blocks, so that's what we'll do first, and we'll measure how often a share would have changed the outcome.

<jeffro256> selsta: This has several issues, I can DM later

If two shares have colliding minor_version, only the first one seen enters the workshare pool.

<gingeropolous> awesome thanks

But the other one is can also be counted as "seen" with a timestamp for the lateness check.

For the fork choice, my intention was to run it only when a new block or a new chain is received.

I think recalculating with every share has the potential for nodes to switch between 2 chains too often.

We can see if this can have some unforeseen effects, like nodes stubbornly sticking to one chain and refusing to switch.

<gingeropolous> yeah. endless sims! I also encourage folks to run monerosim on your own. recent optimizations bring scale to general consumer hardware... you don't need a 1tb ram monster for most stuff

<rucknium> 8. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (arxiv.org/pdf/2609.10260). p2p: increase white_list size and change connection selection algorithm (monero-project/monero #11527).

<rucknium> Last time, @jeffro256:monero.social asked about the potential performance impacts if the white_list grew to 45,000 peers, due to my PR: monero-project/monero #11527

<rucknium> @thomasbuilds:matrix.org asked his LLM bot to write some performance tests. I ran them myself and wrote this in #monero-research-lounge:monero.social : libera.monerologs.net/monero-research-lounge/20261020#c715580-c715601 matrix.to/#/!zxoYuvZdPYtIuWSQnn:mon…ia=monero.social&via=unredacted.org

<rucknium> The performance impact seemed OK to me, especially if the shared peerlists in handshakes and time_sync requests is cached instead of reshuffled on every request.

<rucknium> AFAIK @ofrnxmr:monero.social was working on a complementary and/or competing PR

<ofrnxmr> Yeah, my main roadblock (annoyance) is the 101s peer drop

<ofrnxmr> With it, we have to do white-first peer selection. So i have a series that uses white-first simple because i didnt want to dig into fixing the 101s blind drop. But a complete fix would change that, and allow using gray list again

<gingeropolous> iirc , that was put in to attempt some mitigation against being eclipsed or something.

<ofrnxmr> Well it doesnt work

<rucknium> Why is the 101 second peer drop a problem?

<ofrnxmr> It drops a good peer and selects a likely attacker every 101s

<rucknium> That's assuming you have good peers to start with.

<gingeropolous> ^^^

<thomasbuilds:matrix.org> > <@rucknium> @thomasbuilds:matrix.org asked his LLM bot to write some performance tests. I ran them myself and wrote this in #monero-research-lounge:monero.social : libera.monerologs.net/monero-research-lounge/20261020#c715580-c715601 matrix.to/#/!zxoYuvZdPYtIuWSQnn:mon…ia=monero.social&via=unredacted.org

<thomasbuilds:matrix.org> I'm not very involved in this PR (lots of other work todo!). However if u would need a re-review at some point don't hesitate to ask.

<ofrnxmr> an eclipse assumes you arent being sent blocks (among other things), good peers send blocks

<rucknium> @thomasbuilds:matrix.org: Thank you.

<rucknium> @ofrnxmr: Not necessarily.

<ofrnxmr> Dropping 101s means that we track who sends us good blocks, when they last sent, etc

<rucknium> The objective of an adversary might not require it to withhold blocks.

<ofrnxmr> for an eclipse?

<rucknium> It could be pure spying or just manipulate the txpool

<ofrnxmr> Yeah, but thats a differnet attack. Im any case, the change doesnt keep all 12 connections, but it stop dropping good ones

<ofrnxmr> Currently, at startup, we select 8/12 peers from the white list, then the other 4 from gray. Then drop 1/12 every 101s and select another from gray (iirc)

<rucknium> Not a different attack according to the definition in Franzoni & Daza (2022)

<rucknium> And it's difficult to know if blocks are being withheld, in the short term. That's why you sometimes get that warning in the monerod console about having too few blocks over a period of time, due to randomness of block production rates.

<ofrnxmr> in any case, the series can likely be tested now, with 101s and white-first, but id prefer to change the 101s logic in what id consider to be a complete fix

<ofrnxmr> (i have run local models on it, that showed very promising results)

<ofrnxmr> (On the version that has the 101s drop)

<rucknium> By local models do you mean monerosim?

<ofrnxmr> no, the data is generated w/o running a node

<ofrnxmr> If you want to run it through monerosim as-is, i can share the current state later today

<rucknium> I can run it through monerosim or you can. Up to you.

<ofrnxmr> Ehh, i dont know how to use monerosim and not really interested in figuring it out 😅

<ofrnxmr> It would be your test though - same params etc that you ran yours under, just with my binaries

<rucknium> I'll do it. No problem.

<ofrnxmr> Appreciate it

<rucknium> @ofrnxmr: No. I am going to cheat :D

<rucknium> (This is a joke)

<ofrnxmr> Even if cheating, i think the results should be promising

<rucknium> I tried to see if my patch would defeat the Moros attack, a related attack in the Shi et al. paper that attacks newborn nodes by poisoning seed nodes' white_lists. I set the simulation to attack with the worst case scenario: Nyx attack against all honest nodes and Moros attack (I implemented it as the same as Nyx, just against [... too long, see mrelay.p2pool.observer/e/wsm_yrYLNjZ2aTd2 ]

<rucknium> The 50-hour sim didn't reach equilibrium fast enough. I had enough time to do a 100-hour sim just for the proposed defense and a 50-hour sim for the status quo. I will try to do the 100 hours for the status quo soon.

<rucknium> mrelay.p2pool.observer/m/monero.social/GntqIKOcBTFOElHlHNuztuPj.png (outbound-adversaries-unreachable-moros.png)

<rucknium> mrelay.p2pool.observer/m/monero.social/SgasbveRvyaqrYakzVbUDkgO.png (white-list-unreachable-moros.png)

<rucknium> Here are the results. So far, it looks like the patch reduces the effectiveness of the Moros attack.

<rucknium> That's all from me on this item.

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

<ofrnxmr> Ty

<gingeropolous> thank you!

jeffro256: I'm not seeing this De sharing issue. Carrot has a separate path for change derivation. github.com/jeffro256/carrot/blob/ma….md#784-one-payment-one-change-rule

<ofrnxmr> It only affects legacy wallets

<ofrnxmr> (i assume that section is about carrot-keyed wallets)