04:22:19 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 04:23:43 > <@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) 04:23:43 i think the reason this catched on was that it was more accessible in the ui of the wallets ... 14:07:57 It affects Carrot schedule, so yes > <@rucknium> @jeffro256:monero.social: ^ Should it? 14:12:45 Why does it affect ? Another audit ? 14:57:28 MRL meeting in this room in two hours. 16:00:16 @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 16:03:38 Is it a sweet spot between small and big changes where schedule is affected but audit is still optional ? 16:04:24 Or it's a sweet spot of uncertainty where nothing is clear and therefore no one knows what is going to happen ? 16:04:31 LOL 16:30:28 im kinda double booked during meeting time. my updates - fun with monerosim. SoP work: https://github.com/Fountain5405/monerosim/blob/main/docs/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 https://mrelay.p2pool.observer/e/vJywxrYLa1M5OUtQ ] 16:31:11 @interestingband:matrix.org: More this. Also not optional, but parallizable with the 6-month wait period 17:00:20 Meeting time! https://github.com/monero-project/meta/issues/1477 17:00:22 1. Greetings 17:00:44 Hi 17:00:50 Hello 17:01:04 Hi 17:01:21 Hello 17:01:21 Howdy 17:01:22 hi 17:01:22 GM 17:01:33 Hello 17:02:28 2. Updates. What is everyone working on? 17:02:31 waves 17:03:17 me: Doing more analysis for my proposed eclipse attack fix: https://github.com/monero-project/monero/pull/11527 17:03:48 me: Share or Perish and relative locks 17:03:59 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 17:04:16 me: more audits 17:04:18 me: details above. SoP sims, antiproxy sims, optimizations 17:04:47 me: Handling https://github.com/monero-project/monero/issues/11586. Opened PR to Carrot spec here: https://github.com/jeffro256/carrot/pull/16. Trying to keep changes simple. Also, reviewing upstream PRs and keeping my PRs up-to-date. 17:04:47 me: upstream FCMP++ integration PR's are ready for review, stressnet ongoing 17:06:06 3. get_tx_key/check_tx_key doxes sender in 2-out tx (https://github.com/monero-project/monero/issues/11586). 17:06:36 The more you learn, the more you learn 17:06:37 Spec PR is here: https://github.com/jeffro256/carrot/pull/16 17:07:22 The 1st question is why it wasn't captured during audit ? 17:07:24 I should have a carrot_core PR open in the next couple days 17:08:09 @jeffro256:monero.social: Will carrot-rs be updated for this, and the earlier re-binding change? 17:08:24 @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 17:08:31 Is there a reason to support external change enotes? Jamtis only has internal self sends. 17:08:41 My guess ? Ask Opus 5.5 or any other AI 17:08:50 it was rhetorical question, LOL 17:09:02 tevador: So you can make InProofs/OutProofs to yourself. Not much else AFAIK 17:09:28 Terrible: Your worst enemy (AI) actually has a great point. 17:09:47 I think it would be better to remove the external self sends entirely. 17:10:08 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) 17:11:01 @ofrnxmr: let's make the "trusted nodes" checkbox useful 17:11:02 You mean rely somehow on the goodwill of everyobdy doing apps on doing the right thing? 17:11:05 Yeah I was honestly impressed that Claude found the issue 17:11:11 In Carrot, *every* recipient learns the d_e, this is unrelated to tx key proofs. 17:11:51 https://github.com/monero-project/monero-site/blob/7dd3c296b47cecd680dec091cb19fecc1714b0eb/_i18n/en/resources/user-guides/monero-wallet-cli.md#L96-L100 so it appears this issue was documented in CLI user guide 17:12:08 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. 17:12:10 @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 17:12:14 tevador: How is it unrelated? d_e is the analougue of the tx_key in Carrot 17:12:17 > Note that this third party, if knowing your own address, will be able to see how much change was returned to you as well. 17:12:41 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 17:12:46 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 17:12:50 That's the main reason why audit didn't capture 17:13:03 I mean it's unrelated to any use of the RPC to share the tx key, it's automatic. Apologies for bad phrasing. 17:13:05 selsta: well that kinds of breaks the whole claude is smart myths all of the sudden 17:13:11 if it was documented already 17:13:38 tevador: Oh yeah I see, yeah that's why it was much higher impact than the existing issue 17:14:56 That's the main reason why it needs to be fixed in Carrot. It's no longer "be careful when sharing your tx key". 17:15:40 @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) 17:16:12 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 17:16:29 The service might ask for a refund address and users may put their main address in that field. 17:17:53 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." 17:18:15 Yes 17:20:13 But there are 2 subjects in one. The tx key, and carrot 17:20:17 Hmm. But the "can trace the sender of transaction" part that jeffro mention in his problem description is missing 17:20:26 I think people evaluating carrot fix is more important 17:21:06 rbrunner: They can learn the value of the change output 17:21:16 Anyway, maybe pointing the way to Claude is all that was needed ... 17:21:20 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 17:21:46 @ofrnxmr: This is whats currently happening on stressnet for legacy keyed wallets (passively) 17:22:04 Combine this with small ring info, and smart third-party may be able to probabilistically learn info about tx graph 17:22:18 I think I start to see 17:22:58 That's why only 2-out transactions are in danger 17:23:06 Or, in most danger 17:23:20 @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 17:23:38 3+ out, subaddresses, non-change, dont work (..iiuc) 17:23:39 Only 2-out is in danger b/c of the cryptographic way that the shared ephemeral tx pubkey is constructed 17:23:49 So this proposed fix will make InProofs impossible for most transactions? My bad if I'm misunderstanding something 17:24:05 Due to it affecting 2-out transactions 17:24:09 Yes 17:24:14 https://github.com/jeffro256/carrot/pull/16 << this one, right jpk? 17:24:42 AFAICS only InProofs for self sends will be impossible. 17:25:35 Yes? 17:25:36 Is there any other potential solution without these downsides? 17:26:20 A) Put 2 ephemeral pubkeys for a 2-out tx, doubling scanning time for 2-out txs. B) Removing Janus protection 17:26:40 tevador: I need to double check, but I think so 17:27:29 Or C) something I haven't seen yet 17:27:45 Er ... just ask Claude? :) 17:28:07 "Claude make monero post quantum. Make no mistakes" 17:28:11 Now that was a bit mean, I know 17:28:31 Use google gemini, ofc yall have to use the best one 17:29:09 Is s_sr^ctx insufficient for an InProof? 17:30:36 Yes, because an InProof prover requires that the discrete log between D_e and s_{sr} is k_v 17:30:47 list requirements for this part of protocol and verify in the context of involved parties that will use InProof 17:30:52 There's isn't any ECDH to speak of in an internal scan 17:31:09 any other reply is just an opinion 17:32:20 The purpose of an InProof is to prove that an enote was received, that's not directly related to discrete log. 17:32:32 @jeffro256: And provide s_sr itself 17:32:53 if this is needed I'm willing to propose a fix with claude 17:33:31 tevador: It's both. It decodes a received enote, and signs a message with a Schnorr signagture using k_v as the privkey 17:33:49 maybe it finds C > <@jeffro256> Or C) something I haven't seen yet 17:34:05 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 17:34:24 But InProof also lets you sign messages that third-parties can't 17:35:05 I'm pretty sure there is a solution. It might require an extra SecretDerive call or something like that. 17:36:28 @thomasbuilds:matrix.org: It did in my case, but it wasn't isolated question 17:38:55 Anything need to be decided about this issue today? Or go think and come back next week? 17:39:10 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 17:39:58 But the mitigations which are backwards-comptible with the current addresses typically have some compute or size overhead 17:40:20 You are trying to find math ops to meet algebraic equations, while cryptography requires much more and with proofs, otherwise It's all insecure 17:41:20 I prefer to keep the current 16-byte Janus mitigation. 17:42:59 It's a very good fit for Jamtis, which reuses the anchor field to encrypt the address index, which is a very efficient solution. 17:45:17 3. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). FCMP++ Integration Audit Overview (https://github.com/seraphis-migration/monero/issues/294). Network upgrade [... too long, see https://mrelay.p2pool.observer/e/7JbCyLYLQS1Kbkpn ] 17:45:39 mx25519 got merged yay! 17:46:10 FCMP++ upstream consensus integration PR's open for review, LLM comments all addressed 17:46:30 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 17:46:31 RFQ for phases 2&3 integration audits has gone out and we're fielding quotes 17:46:58 Circuit + gadgets Least Authority audit is ongoing 17:47:29 Multisig in progress 17:48:11 Carrot tx proofs also in progress (the prior discussion item) 17:48:33 selsta: This would probably break the PQ migration by leaking k_v 17:48:54 LOL 17:49:28 @jberman:monero.social Is it possible to public anywhere scope for the upcoming or ongoing audits ? Ideally as is ? 17:49:53 I mean what exactly will be audited 17:50:03 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 17:50:07 human friendly from is ok too 17:50:22 @sgp_:monero.social: want to share the doc sent out for the RFQ? That doc clarifies scope 17:50:44 I just needed that for evaluation of what is audited and what is not 17:51:07 jeffro256: will let it refine with your concern and double check 17:52:49 @sgp_:monero.social: RFQ for both the integration audit + the ongoing circuit + gadgets audit would be appreciated (looking for the latter rn) 17:54:01 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. 17:54:25 tevador: will send it in a paste 17:56:20 4. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). 17:57:25 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) 17:57:27 I messed up the agenda numbering. Two number threes. Anyway, will fix from now on. 17:57:45 @jberman: gui qt6 now too? 17:57:50 Thanks to selsta for fixing the GUI issue 17:58:11 (Get to test the unrelease "major" gui update) 17:58:28 @ofrnxmr: Yep can include that too 17:58:52 Its merged on master on gui repo, so i assume its included, i think 17:59:16 Yea I just have to update the branch I'm using for these builds 18:00:02 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 18:00:40 I have logs, just need to review them 18:01:23 There were some xmrack review finsing that should be addressed soon 18:02:15 I can't recall if there are more beyond the PR's xmrack opened (and have been merged into the stressnet branch as well) 18:03:20 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 18:05:16 6. Relative time locks (https://github.com/monero-project/research-lab/issues/161). Consensus code (https://github.com/seraphis-migration/monero/pull/507). 18:05:39 Since last time this was discussed, tevador made the PR: https://github.com/seraphis-migration/monero/pull/507 18:06:23 I'm not sure if the base branch for the PR is correct. It should be whichever branch gets the consensus changes. 18:06:50 It would be nice to have it reviewed and merged for the audit. 18:07:12 Base branch of fcmp++-stage is good 18:07:39 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 18:08:11 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). 18:09:06 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 18:09:18 Thanks 18:11:25 7. Share or Perish (selfish mining mitigation) (https://github.com/monero-project/research-lab/issues/146). 18:12:27 I looked a little into the code that the researcher here shared with me: https://github.com/monero-project/research-lab/issues/146#issuecomment-5978803129 18:12:58 It was nice of them to share the code. IMHO, the code is OK, but not amazing. 18:13:18 It looks like there was heavy LLM usage. 18:13:40 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. 18:14:02 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. 18:15:04 IMHO, it would be premature to endorse SoP without a more exhaustive analysis, like putting it into an MDP (Markov Decision Process). 18:15:45 I think that if you leave stones unturned, a nasty strategy could be lurking under one of them. 18:16:35 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. 18:16:52 But monerosim is useful for catching other issues, like the block minor version. 18:17:13 oh i will drive the bots to find all the stones 18:17:13 Agreed. People can release their LLMs on it. I'll freeze the specs for now unless a major issue is discovered. 18:17:58 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., 18:19:28 @gingeropolous:monero.social: What's your plan for that? 18:19:38 tevador: jeffro256: this is the LLM proposal, hopefully it's not too sloppy https://www.irccloud.com/pastebin/863OFA8r/ 18:20:33 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) 18:21:26 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. 18:22:00 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 18:22:44 Sounds good. 18:23:27 More on this issue? 18:24:01 yeah 2 questions 18:24:15 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. 18:24:34 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. 18:27:25 selsta: This has several issues, I can DM later 18:27:28 If two shares have colliding minor_version, only the first one seen enters the workshare pool. 18:28:07 awesome thanks 18:28:27 But the other one is can also be counted as "seen" with a timestamp for the lateness check. 18:29:34 For the fork choice, my intention was to run it only when a new block or a new chain is received. 18:30:46 I think recalculating with every share has the potential for nodes to switch between 2 chains too often. 18:32:16 We can see if this can have some unforeseen effects, like nodes stubbornly sticking to one chain and refusing to switch. 18:33:36 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 18:34:35 8. Shi et al. (2026) "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero’s P2P Network!" (https://arxiv.org/pdf/2609.10260). p2p: increase white_list size and change connection selection algorithm (https://github.com/monero-project/monero/pull/11527). 18:35:35 Last time, @jeffro256:monero.social asked about the potential performance impacts if the white_list grew to 45,000 peers, due to my PR: https://github.com/monero-project/monero/pull/11527 18:36:52 @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 : https://libera.monerologs.net/monero-research-lounge/20261020#c715580-c715601 https://matrix.to/#/!zxoYuvZdPYtIuWSQnn:monero.social/$R8_SLuB2_WqhPKgBzn84jp4mbpNCzvoRHPDcKf7PGEc?via=matrix.org&via=monero.social&via=unredacted.org 18:37:34 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. 18:37:57 AFAIK @ofrnxmr:monero.social was working on a complementary and/or competing PR 18:38:56 Yeah, my main roadblock (annoyance) is the 101s peer drop 18:40:02 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 18:40:17 iirc , that was put in to attempt some mitigation against being eclipsed or something. 18:40:30 Well it doesnt work 18:40:31 Why is the 101 second peer drop a problem? 18:40:50 It drops a good peer and selects a likely attacker every 101s 18:41:08 That's assuming you have good peers to start with. 18:41:14 ^^^ 18:41:15 > <@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 : https://libera.monerologs.net/monero-research-lounge/20261020#c715580-c715601 https://matrix.to/#/!zxoYuvZdPYtIuWSQnn:monero.social/$R8_SLuB2_WqhPKgBzn84jp4mbpNCzvoRHPDcKf7PGEc?via=matrix.org&via=monero.social&via=unredacted.org 18:41:15 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. 18:41:32 an eclipse assumes you arent being sent blocks (among other things), good peers send blocks 18:41:35 @thomasbuilds:matrix.org: Thank you. 18:41:55 @ofrnxmr: Not necessarily. 18:42:07 Dropping 101s means that we track who sends us good blocks, when they last sent, etc 18:42:26 The objective of an adversary might not require it to withhold blocks. 18:42:39 for an eclipse? 18:43:01 It could be pure spying or just manipulate the txpool 18:43:40 Yeah, but thats a differnet attack. Im any case, the change doesnt keep all 12 connections, but it stop dropping good ones 18:44:13 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) 18:44:20 Not a different attack according to the definition in Franzoni & Daza (2022) 18:45:53 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. 18:46:03 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 18:47:01 (i have run local models on it, that showed very promising results) 18:47:27 (On the version that has the 101s drop) 18:47:52 By local models do you mean monerosim? 18:49:09 no, the data is generated w/o running a node 18:49:30 If you want to run it through monerosim as-is, i can share the current state later today 18:49:56