Nostr notes by Schmidt

“...Monero, where no one sees how much you send to whom.” ...

2026-10-27T16:39:09Z

“...Monero, where no one sees how much you send to whom.”

Tom-Oliver Regenauer
https://www.regenauer.press/

Nostr event nevent1qqsqqqy9x39y9e6d0rn9frj0fhd8vg02hl65frulwtkhzqqyy8wzhtgzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqnvl0um

2026-10-27T15:09:51Z

Fair point. Tor or I2P access is on the list. Until then, Tor ...

2026-10-27T13:02:44Z

In reply to nevent1q…2e0f
_________________________

Fair point. Tor or I2P access is on the list. Until then, Tor Browser hides your IP from the server.

Partly. Sites see the cloud browser's fingerprint, not yours. ...

2026-10-27T13:02:41Z

In reply to nevent1q…d8w3
_________________________

Partly. Sites see the cloud browser's fingerprint, not yours. But the provider sees everything you do. Tor Browser is the better default: everyone looks the same.

Password reuse is the most exploited weakness that isn’t ...

2026-10-27T12:47:01Z

Password reuse is the most exploited weakness that isn’t technically a vulnerability

One breach exposes every account with the same password

Bitwarden is open source and free

It's an Android app 📱 Get it on Zapstore, F-Droid or ...

2026-10-27T12:40:38Z

In reply to nevent1q…2tgj
_________________________

It's an Android app 📱 Get it on Zapstore, F-Droid or GitHub. Everything at monostr.com. No web version yet.

Nostr event nevent1qqsqqq8duerfpswhvjvcy4303atr57wdvfvqn0nu8tx47g3c4j3asaczyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzq7grddn

2026-10-27T06:30:06Z

😎

2026-10-27T05:20:48Z

In reply to nevent1q…v76g
_________________________

😎

Email is fundamentally not private Treat it like a postcard ...

2026-10-27T02:00:01Z

Email is fundamentally not private

Treat it like a postcard

Nothing sensitive. Ever.

5 principles once associated with Swiss numbered bank accounts: ...

2026-10-26T19:18:49Z

5 principles once associated with Swiss numbered bank accounts:

Financial privacy
Confidentiality
Discretion
Financial stability
Asset security

Sound familiar?

https://www.getmonero.org/

You can go to my profile and see some accounts in my public list ...

2026-10-26T17:47:52Z

In reply to nevent1q…9lg4
_________________________

You can go to my profile and see some accounts in my public list "Monero on Nostr"

Nostr event nevent1qqsqqq8vr4nk8zjc7557hcg66y55ar79n6jhgddjnlq8plfetue28sszyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqzv38hu

2026-10-26T15:33:23Z

Monero Alltime Hashrate ...

2026-10-26T11:50:25Z

Monero Alltime Hashrate
https://bitinfocharts.com/comparison/monero-hashrate.html#alltime

🙏🏻 Thanks to all for the Monero tips via @npub1zcq…e6z2

2026-10-26T10:05:11Z

🙏🏻 Thanks to all for the Monero tips via monostr (npub1zcq…e6z2)

idk. could be @npub1mf8…chqz

2026-10-26T08:03:09Z

In reply to nevent1q…720f
_________________________

idk. could be jpk68 (npub1mf8…chqz)

https://xmr.fan/news

2026-10-26T06:47:19Z

In reply to nevent1q…eecm
_________________________

https://xmr.fan/news

cc/ @npub14wu…g3ns

2026-10-26T05:56:10Z

In reply to nevent1q…slh7
_________________________

cc/ Mondetta (npub14wu…g3ns)

src https://xnologin.com/jpk68_/status/2113365561631805821

2026-10-26T05:34:02Z

In reply to nevent1q…yy9c
_________________________

src https://xnologin.com/jpk68_/status/2113365561631805821

jpk68 recently put forward a proposal to continue to work ...

2026-10-26T05:33:00Z

jpk68 recently put forward a proposal to continue to work full-time on Monero development
https://ccs.getmonero.org/proposals/jpk68-full-time-1.html

Nostr event nevent1qqsqqqrasg26w5fuytq69lj54q6gyapvt82wcqxyyv05n00nvpg8s4czyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqqyeju3

2026-10-26T05:28:17Z

Feel free to add it 👇🏻 ...

2026-10-26T05:26:08Z

In reply to nevent1q…t2fx
_________________________

Feel free to add it 👇🏻
https://codeberg.org/schmidt1024/monero-ecosystem/issues

And take a look at the readme first!

My Privacy Stack 👇🏻 ...

2026-10-25T16:15:53Z

My Privacy Stack
👇🏻
https://privacystack.rocks/#v1&mobile-os=grapheneos&messenger=simplex,signal,session,threema&browser=tor-browser,brave,vanadium,ungoogled-chromium&search=kagi,brave-search&network=mullvad,ivpn,nymvpn,invizible&passwords=bitwarden,vaultwarden&email=selfhost-mail,neromail,tuta&wallet=monero-com,monerujo,monero-gui,feather&notes=joplin,fromscratch&nostr=amethyst&editor=vscodium&scanner=oss-document-scanner&desktop-os=ubuntu-debloated&2fa=aegis&files=syncthing,nextcloud&sharing=localsend&maps=comaps&appstore=fdroid,aurora,obtainium&keyboard=futo-keyboard&blocking=ublock&media=newpipe,grayjay&mailclient=fairemail

Surveillance is not safety It’s control with better PR

2026-10-24T17:00:01Z

Surveillance is not safety

It’s control with better PR

New issues keep popping up and I fix them right away. But there ...

2026-10-24T07:37:01Z

In reply to nevent1q…emvx
_________________________

New issues keep popping up and I fix them right away. But there are too many updates, so I need to batch the fixes and release them together.

src https://xnologin.com/GrapheneOS/status/2113422926942818811

2026-10-24T06:02:30Z

In reply to nevent1q…lpyz
_________________________

src https://xnologin.com/GrapheneOS/status/2113422926942818811

Nostr event nevent1qqsqqqxm8a5rw7tpz7v7f0xz9j7tcnre4nw4k229tdp3w6hrmfk83wczyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqtdrk5k

2026-10-24T06:02:15Z

Every company that doesn’t sell your data still monetizes it ...

2026-10-24T05:47:01Z

Every company that doesn’t sell your data still monetizes it

Through targeting, through inference, through partners

Unsubscribe links often confirm your email address is active ...

2026-10-23T21:00:01Z

Unsubscribe links often confirm your email address is active

Filter and delete instead

Or use an alias you can kill

Garnet was a fork of Amethyst with a Monero wallet internaly. ...

2026-10-23T19:09:46Z

In reply to nevent1q…y8xx
_________________________

Garnet was a fork of Amethyst with a Monero wallet internaly. Monostr is developed from scratch without a wallet, using monero:... URI. Everything else you can read under https://monostr.com

A guide for self-hosting a (private) Nitter instance ...

2026-10-23T18:57:49Z

A guide for self-hosting a (private) Nitter instance
https://codeberg.org/shitter/shitter/wiki/Self-hosting+a+Nitter+instance.-

Nostr event nevent1qqsqqq8w3sw4jfw67ne96z0yeu4zwgedpnvqxgx7xxs2vj7fyvtcsrczyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqj7772c

2026-10-23T15:53:40Z

Browser fingerprinting tracks you even without cookies Screen ...

2026-10-23T12:47:01Z

Browser fingerprinting tracks you even without cookies

Screen size, fonts, GPU, timezone
combined they’re unique to you

Thats why I built https://neromail.app takes Monero

2026-10-23T11:42:21Z

In reply to nevent1q…78hu
_________________________

Thats why I built https://neromail.app takes Monero

Nostr event nevent1qqsqqqxc2syep4slpr4676pvsgx7pgtd30gd36l32tav4wlf70v9f6qzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqkr7z03

2026-10-23T07:22:31Z

End-to-end encryption means the platform can’t read your ...

2026-10-23T03:00:01Z

End-to-end encryption means the platform can’t read your messages

It doesn’t mean the recipient can’t screenshot them

Trust is still required

Monero txs today: 32,264 ...

2026-10-22T18:12:31Z

Monero txs today:

32,264

Nostr event nevent1qqsqqqq6njz4c9aft0530lqsmjywqy5mg4xdt5xnjx8camn6sj4dpmczyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqq6jdj8

2026-10-22T14:17:53Z

Nostr event nevent1qqsqqqqu8gm20kazhhlcgdgsv54mfpypavekh5cuyv0zlwue4lwvy5szyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzq0dgk2g

2026-10-22T14:11:36Z

Your email address is the spine of your digital identity Every ...

2026-10-22T13:47:01Z

Your email address is the spine of your digital identity

Every account is linked to it

Protect it accordingly

https://pmnr.xmr.rocks

2026-10-22T12:18:48Z

https://pmnr.xmr.rocks

GrapheneOS improves privacy and security patches vulnerabilities ...

2026-10-22T10:50:19Z

GrapheneOS improves privacy and security

patches vulnerabilities
removes compromised certificates
fixes Google Play bugs
strengthens app isolation

https://grapheneos.org/releases#2026102100

XMR/BTC over 12 months 0.0036 → 0.0079 ₿ (+120%) ...

2026-10-22T06:27:48Z

XMR/BTC over 12 months

0.0036 → 0.0079 ₿ (+120%)

Monero is testing a peer-list upgrade to resist network attacks. ...

2026-10-22T05:44:00Z

Monero is testing a peer-list upgrade to resist network attacks. Early simulations look promising, with acceptable performance costs, but more testing is needed.

quoting
nevent1q…8v0k
Performance impact of growing white_list to ~45k peers appears acceptable (especially with cached peerlists). ofrnxmr’s complementary/competing work is blocked by the 101s peer drop (which preferentially drops good peers and selects likely attackers); white-first selection is a workaround, full fix would restore gray-list usability. Debate on whether the drop is effective against eclipse vs. other attacks (spying, txpool manipulation). rucknium’s monerosim runs (Nyx + Moros) show the patch reduces Moros effectiveness so far; longer status-quo runs planned. ofrnxmr’s local-model results on the 101s version look promising; binaries available for monerosim comparison. thomasbuilds offered re-review if needed.

rucknium: Last time, jeffro256 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
rucknium: thomasbuilds asked his LLM bot to write some performance tests. I ran them myself and wrote this in #monero-research-lounge: 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
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 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: > rucknium thomasbuilds asked his LLM bot to write some performance tests. I ran them myself and wrote this in #monero-research-lounge: 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
thomasbuilds: 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: 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 the seed nodes) against seed nodes. Then start an unreachable node a few hours after the attack begins.
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: (outbound-adversaries-unreachable-moros.png)
rucknium: (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.
https://libera.monerologs.net/monero-research-lab/20261021#c716049
nevent1q…vh9e

Monero’s SoP mining rules need deeper attack testing before ...

2026-10-22T05:43:21Z

Monero’s SoP mining rules need deeper attack testing before approval. Simulations help, but researchers want advanced AI and mathematical models to uncover hidden weaknesses.

quoting
nevent1q…ga3c
rucknium reviewed shared attack code (LLM-heavy, grid-search on stubborn mining; OK but not amazing) and argued more exhaustive analysis (MDP or RL-MDP) is needed before endorsement; monerosim is useful but cannot cover all scenarios. tevador updated SoP last week (gingeropolous independently found a fixed issue) and will freeze specs unless a major issue appears. Biggest potential issue is temporary network splits from subjective fork choice (limited compared to PoP). gingeropolous plans more monerosim runs + LLM attacks. Clarifications: colliding minor_version shares → first-seen enters pool (other can be timestamped); fork choice only on new block or new chain (not every share, to avoid thrashing). monerosim optimizations make it runnable on consumer hardware.

rucknium: 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
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.
tevador: 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 '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
tevador: 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: What's your plan for that?
selsta: tevador: jeffro256: this is the LLM proposal, hopefully it's not too sloppy https://www.irccloud.com/pastebin/863OFA8r/
tevador: 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
tevador: If two shares have colliding minor_version, only the first one seen enters the workshare pool.
gingeropolous: awesome thanks
tevador: But the other one is can also be counted as "seen" with a timestamp for the lateness check.
tevador: For the fork choice, my intention was to run it only when a new block or a new chain is received.
tevador: I think recalculating with every share has the potential for nodes to switch between 2 chains too often.
tevador: 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
https://libera.monerologs.net/monero-research-lab/20261021#c716018
nevent1q…pz8x

Monero payment channels: a PR proposes a 3-day lock time, giving ...

2026-10-22T05:42:36Z

Monero payment channels: a PR proposes a 3-day lock time, giving users until Monday to react if a channel is force-closed on Friday. Review pending.

quoting
nevent1q…5z5g
tevador opened PR #507 (base branch fcmp++-stage is correct). Lock time increased to 3 days for better UX (e.g., Friday force-close allows until Monday). jberman will review and include in upstream PRs; concept has had sufficient time for objections. Prior conflicting issues no longer apply after recent changes.

rucknium: Since last time this was discussed, tevador made the PR: https://github.com/seraphis-migration/monero/pull/507
tevador: I'm not sure if the base branch for the PR is correct. It should be whichever branch gets the consensus changes.
tevador: 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
tevador: 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
tevador: Thanks
https://libera.monerologs.net/monero-research-lab/20261021#c716008
nevent1q…r7th

Monero progress: mx25519 merged, FCMP++ integration reviews open ...

2026-10-22T05:41:42Z

Monero progress: mx25519 merged, FCMP++ integration reviews open and security audits underway.

Multisig and Carrot proofs continue; self-send receipt design needs PQ-safety review.

quoting
nevent1q…rzz3
mx25519 merged. Upstream consensus integration PRs open for review (LLM comments addressed). RFQ for phases 2&3 integration audits out and quotes being fielded. Circuit + gadgets Least Authority audit ongoing. Multisig and Carrot tx proofs (prior item) in progress. Astra/LLM proposal for self-send receipts raised concerns about leaking k_v and breaking PQ migration; selsta to refine. Scope documents for audits available via sgp_ if needed.

jeffro256: mx25519 got merged yay!
jberman: FCMP++ upstream consensus integration PR's open for review, LLM comments all addressed
selsta: 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: LOL
interestingband: jberman: Is it possible to public anywhere scope for the upcoming or ongoing audits ? Ideally as is ?
interestingband: 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: human friendly from is ok too
jberman: sgp_: want to share the doc sent out for the RFQ? That doc clarifies scope
interestingband: I just needed that for evaluation of what is audited and what is not
selsta: jeffro256: will let it refine with your concern and double check
jberman: sgp_: RFQ for both the integration audit + the ongoing circuit + gadgets audit would be appreciated (looking for the latter rn)
tevador: 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.
selsta: tevador: will send it in a paste
https://libera.monerologs.net/monero-research-lab/20261021#c715994
nevent1q…0mgm

Sharing Monero tx keys can reveal the sender and change amount in ...

2026-10-22T05:40:49Z

Sharing Monero tx keys can reveal the sender and change amount in 2-output transactions. Wallets should use proper proofs instead. Carrot’s impact is limited to legacy wallets.

quoting
nevent1q…7qkv

3. get_tx_key/check_tx_key doxes sender in 2-out tx (https://github.com/monero-project/monero/issues/11586)

The issue (also impacting Carrot) allows a third party who knows the sender’s primary address and receives the tx key (or equivalent d_e) to identify the change output in 2-out transactions and infer the sender. It was previously noted in the CLI user guide. Discussion covered why audits missed it (long-standing technique, UI convenience of tx keys over proofs, incomplete usage context), the higher impact in Carrot (automatic d_e learning by every recipient), proposed mitigations (extra ephemeral pubkey, drop Janus protection, research-lab Janus alternatives, external self-send removal, alternative InProof constructions), and the practical preference for wallets/services to switch to proper proofs rather than rely on deprecation alone. External self-sends exist mainly for self In/OutProofs. No immediate decision; further thinking / next week. Post-meeting note that Carrot has a separate change-derivation path so the issue is limited to legacy wallets.

syntheticbird: The more you learn, the more you learn
jeffro256: Spec PR is here: https://github.com/jeffro256/carrot/pull/16
interestingband: 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: jeffro256: Will carrot-rs be updated for this, and the earlier re-binding change?
jeffro256: interestingband: 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
tevador: Is there a reason to support external change enotes? Jamtis only has internal self sends.
interestingband: My guess ? Ask Opus 5.5 or any other AI
interestingband: 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.
tevador: 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
rbrunner: 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
tevador: In Carrot, every recipient learns the d_e, this is unrelated to tx key proofs.
selsta: 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
rucknium: 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: 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
selsta: > 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: 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: That's the main reason why audit didn't capture
tevador: 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
tevador: 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.
rbrunner: 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
rbrunner: 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
rbrunner: 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
rbrunner: I think I start to see
rbrunner: That's why only 2-out transactions are in danger
rbrunner: 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: So this proposed fix will make InProofs impossible for most transactions? My bad if I'm misunderstanding something
jpk68: Due to it affecting 2-out transactions
jeffro256: Yes
ofrnxmr: https://github.com/jeffro256/carrot/pull/16 << this one, right jpk?
tevador: AFAICS only InProofs for self sends will be impossible.
jeffro256: Yes?
jpk68: 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
rbrunner: Er ... just ask Claude? :)
syntheticbird: "Claude make monero post quantum. Make no mistakes"
rbrunner: Now that was a bit mean, I know
slowbeardigger: Use google gemini, ofc yall have to use the best one
tevador: 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: 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: any other reply is just an opinion
tevador: 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: 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: 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
tevador: I'm pretty sure there is a solution. It might require an extra SecretDerive call or something like that.
interestingband: thomasbuilds: 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: You are trying to find math ops to meet algebraic equations, while cryptography requires much more and with proofs, otherwise It's all insecure
tevador: I prefer to keep the current 16-byte Janus mitigation.
tevador: It's a very good fit for Jamtis, which reuses the anchor field to encrypt the address index, which is a very efficient solution. (Pre-meeting related context:)
spirobel: 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: > 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: 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: ^ Should it?
interestingband: Why does it affect ? Another audit ?
jeffro256: interestingband: 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: Is it a sweet spot between small and big changes where schedule is affected but audit is still optional ?
interestingband: Or it's a sweet spot of uncertainty where nothing is clear and therefore no one knows what is going to happen ?
interestingband: LOL
jeffro256: interestingband: More this. Also not optional, but parallizable with the 6-month wait period (Post-meeting:)
UkoeHB: jeffro256: I'm not seeing this De sharing issue. Carrot has a separate path for change derivation. https://github.com/jeffro256/carrot/blob/master/carrot.md#784-one-payment-one-change-rule
ofrnxmr: It only affects legacy wallets
ofrnxmr: (i assume that section is about carrot-keyed wallets)
https://libera.monerologs.net/monero-research-lab/20261021#c715878
nevent1q…5s64

You don’t need to be perfect You need to be harder to track ...

2026-10-22T00:00:01Z

You don’t need to be perfect

You need to be harder to track than average

That alone moves you out of most mass surveillance nets

Nostr event nevent1qqsqqqx79pz5efv6dqme7euxcxp8uj29fmxvptl5dxw8vz8huysfz0qzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqnhdafr

2026-10-21T16:28:11Z

Update to PHP 8.2.35/8.3.36/8.4.27/8.5.12 No patch yet? Mitigate ...

2026-10-21T15:28:28Z

Update to PHP
8.2.35/8.3.36/8.4.27/8.5.12

No patch yet?
Mitigate + restrict access
Only EOL PHP must go offline

#PHP

Faraday bags block all radio signals No GPS, no cellular, no ...

2026-10-21T13:47:01Z

Faraday bags block all radio signals

No GPS, no cellular, no WiFi, no Bluetooth

Use one when you need true isolation

Will take a look. Thanks.

2026-10-21T06:37:29Z

In reply to nevent1q…naxy
_________________________

Will take a look. Thanks.

Nostr event nevent1qqsz0w30z6dcht96gcqnsu64sw7daa4sqerlhey54cy7qkjm3hptmxszyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqggvg77

2026-10-21T00:47:01Z

Your ISP is not your friend

Nostr event nevent1qqsqqq9rxd22jdq9dtt77zgz6r0k0hctsw96a6k9qc3vmtggn0yw2aqzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzq6muc90

2026-10-20T17:40:04Z

src https://x.com/CoinDesk/status/2112525559666221563?s=20

2026-10-20T17:22:53Z

In reply to nevent1q…eqmt
_________________________

src https://x.com/CoinDesk/status/2112525559666221563?s=20

The parasitic elite is preparing a theft off nearly a third of ...

2026-10-20T17:22:06Z

The parasitic elite is preparing a theft off nearly a third of every crypto-to-stablecoin swap in France. A legalized shakedown, dressed up as regulation.

Email headers contain your IP address, your email client and your ...

2026-10-20T11:47:01Z

Email headers contain your IP address, your email client and your timezone

More metadata than most people expect

XMR/BTC last 12 months 0.0036 → 0.0075 ₿ (+110%) Monero is ...

2026-10-20T10:45:02Z

XMR/BTC last 12 months

0.0036 → 0.0075 ₿ (+110%)

Monero is crushing Bitcoin
Privacy is back
$XMR $BTC

Nostr event nevent1qqsqqqx6tyspv7xll3205qyu2pucpdty8tdxsa3upsfzmuzg3q2tzeszyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzql5t679

2026-10-20T06:51:37Z

XMR -> 600 USD

HTTPS-only mode costs you nothing Turn it on in every browser If ...

2026-10-19T22:47:01Z

HTTPS-only mode costs you nothing

Turn it on in every browser

If a site breaks, that’s a signal about the site

Nostr event nevent1qqsqqqysv5vu4qf6tzfmce7m0g6n2c0hpszl5e5rqc4mmde9fayn4cczyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzq7n6r6f

2026-10-19T16:34:03Z

Nostr event nevent1qqsqqqzthr5rpgq8y739fp8ushfjtgcufrd7zc559gmyhd6as7hrnegzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqc5pgtt

2026-10-19T13:21:02Z

Signing into your browser account defeats every other privacy ...

2026-10-19T13:00:01Z

Signing into your browser account defeats every other privacy measure

Don’t sync
Don’t sign in

BTC vs. XMR One-year performance Bitcoin: −23.14% Monero: ...

2026-10-19T07:49:07Z

BTC vs. XMR

One-year performance

Bitcoin: −23.14%
Monero: +101.53%

Nostr event nevent1qqsqqqxcewye9vtvts022f6eyghkxqnmx6l0wqleyy20yz0p497638gzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzq342ejn

2026-10-19T07:37:29Z

In reply to nevent1q…tvyf
_________________________

src https://bitinfocharts.com/comparison/monero-transactions.html#3m

Daily Monero Transactions Today: 29,615 ...

2026-10-19T07:37:03Z

Daily Monero Transactions

Today: 29,615

src https://x.com/schmidt1024/status/1926169487285325957

2026-10-19T05:36:20Z

In reply to nevent1q…4rq9
_________________________

src https://x.com/schmidt1024/status/1926169487285325957

🙏🏻

2026-10-19T04:17:08Z

In reply to nevent1q…yz8s
_________________________

🙏🏻

They said this in a leaked video.

2026-10-19T03:55:56Z

In reply to nevent1q…hh73
_________________________

They said this in a leaked video.

Email aliases: give every service a unique address When one leaks ...

2026-10-19T03:47:01Z

Email aliases: give every service a unique address

When one leaks or gets sold, you delete that alias

Nostr event nevent1qqsqqqzwjx9c75ytn32qh2lnmhu78v4k2xmd9as4afjcqarrr9lk4vgzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzq3afj0e

2026-10-18T17:23:07Z

Monero hides sender, receiver and amount by default Not a ...

2026-10-18T17:00:02Z

Monero hides sender, receiver and amount by default

Not a setting. Not an option. The baseline.

Nostr event nevent1qqsqqqpvv3yewgdxxngpgws82djyg6dg4g95wgczmww3gru2hdppw3czyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqe4y3fj

2026-10-18T07:05:58Z

Nostr event nevent1qqsqqqythdnrpsnc2nfuazgl3eswcqjptrn8c9vag30y6jg39tdss3qzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqmxlsez

2026-10-18T04:58:18Z

Privacy is not a premium feature It’s a default right that got ...

2026-10-17T21:00:02Z

Privacy is not a premium feature

It’s a default right that got slowly taken away

The parasitic elites have bankrupted the world. A lot of the ...

2026-10-17T17:56:57Z

The parasitic elites have bankrupted the world.

A lot of the distractions you see in the media are meant to cover up that reality.

Nostr event nevent1qqsqqq8lazetnyu2enwkeuq222t8vs3gkwvlgau9cux5mz6jjxrmw0gzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqd5xjp5

2026-10-17T16:09:05Z

Nostr event nevent1qqsqqqrjnuc9zw5lzhtfpw87xrph3n9jw24pya8t3rdr5dwxc2ytuhqzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqnwjnj8

2026-10-17T13:37:09Z

In reply to nevent1q…da7f
_________________________

src https://info.arkm.com/research/privacy-coins-101-what-are-they-how-do-they-work

They had to bundle ZEC with Dash because they know it’s worth ...

2026-10-17T13:36:20Z

They had to bundle ZEC with Dash because they know it’s worth less than 1% on its own.

🥳 #nevent1q…hm99

2026-10-17T09:52:56Z

🥳

quoting
nevent1q…hm99
We made it into F-Droid 🎉 Tip on Nostr with Monero, no Lightning, no custodian. https://f-droid.org/packages/com.monostr.app/ #nostr #monero

When an app trusts an unpatched 5-year-old phone but blocks a ...

2026-10-17T08:00:01Z

When an app trusts an unpatched 5-year-old phone but blocks a fully patched hardened one, the gatekeeping was never about security

It’s about who controls your device, you or the vendor

Your browser history is a complete profile of your life Delete it ...

2026-10-16T18:47:01Z

Your browser history is a complete profile of your life

Delete it regularly

Treat it like mail you don’t want lying around

SimpleX has no user IDs Not even a phone number Only found if ...

2026-10-16T06:47:01Z

SimpleX has no user IDs

Not even a phone number

Only found if someone has your QR

Monero may get free AI security audits from Anthropic. Most favor ...

2026-10-15T15:46:50Z

Monero may get free AI security audits from Anthropic. Most favor joining, but some worry about privacy, AI training, and corporate influence.

quoting
nevent1q…0sjc
6.2 Anthropic oss-scanner
jpk68 introduced Anthropic’s oss-scanner (https://github.com/anthropics/oss-scanner/), described as similar to oss-fuzz: project maintainers submit a request, LLMs scan the code, and findings are emailed to addresses listed in project.yaml. Bitcoin Core, Botan, libtorrent, and OpenSSL are already enrolled. A Core Team member or tobtoht would need to submit for Monero. A draft commit adding Monero was shared. bF indicated willingness to handle any KYC requirement (whether KYC is actually required remains unconfirmed). syntheticbird raised concerns about Anthropic’s advocacy for closed and regulated AI access and the marketing value of vulnerability counts. Counter-arguments included that the service is free, that Monero can already be scanned without enrollment, that enrollment does not materially affect Anthropic’s regulatory prospects, and that the practical security value is high. ofrnxmr framed it as free audits under a BSD license. syntheticbird stated personal support for enrollment while preferring a fuller discussion at the next meeting so more participants can weigh in. No explicit opposition was recorded. Post-meeting chat continued on incentives and training-data use of code.
Relevant links:
https://github.com/anthropics/oss-scanner/
https://github.com/jpk68/oss-scanner/commit/88898203c5e9db395ceb4c13495abfd310f6a487
https://openai.com/form/codex-for-oss/
https://claude.com/contact-sales/claude-for-oss

jpk68: There's also the Anthropic thing
rucknium: Yes
rucknium: Can you explain Anthropic's oss-scanner?
jpk68: Sure. It's a program similar to oss-fuzz, where project maintainers can submit a request to have it scanned by LLMs automatically. Any findings are sent to the listed emails in the project.yaml file.
jpk68: Several notable projects have already been merged, including Bitcoin Core, Botan, libtorrent, and OpenSSL
jpk68: Considering that quite a few issues have already been found using LLMs, and this would allow us to presumably get feedback from unreleased frontier LLMs, it seems like a good opportunity, IMO
jpk68: Though it's worth noting that a "project maintainer" has to submit the application. Either a member of the Core Team or tobtoht, I guess
rucknium: Seems ok to me.
ofrnxmr: bF said he was ok with doing it
syntheticbird: I'll just explicit the obvious here. There is a marketing incentive for Anthropic to use these open source projects into increasing their count of vulnerabilities found with their models. Anthropic has been advocating for closed and regulated access of AI models. Whether we care about helping participating to this end or being pragmatic about it as a project is something to think about.
syntheticbird: saying this because I only heard the KYC argument so far
jpk68: I suppose you could similarly question Google's intentions with oss-fuzz. We have also not yet established whether KYC is required for this Claude thing
rucknium: Then Monero games its number by classifying all findings as low severity :D
selsta: IIRC bF offered to do the KYC part
thomasbuilds: it's a wrong argument afaik
syntheticbird: I meant discussion
jpk68: I slopped a draft commit for adding Monero to the repo:
jpk68: https://github.com/jpk68/oss-scanner/commit/88898203c5e9db395ceb4c13495abfd310f6a487
syntheticbird: That would actually be very funny to pull
ofrnxmr: > syntheticbird I'll just explicit the obvious here. There is a marketing incentive for Anthropic to use these open source projects into increasing their count of vulnerabilities found with their models. Anthropic has been advocating for closed and regulated access of AI models. Whether we care about helping participating to this end or being pragmatic about it as a project is something to think about.
ofrnxmr: Lets not pretend that m$ isnt already doing this on github
thomasbuilds: the only downside I see is that anthropic finds a big vuln and would not disclose it and report it to gov agencies or whetever.
slowbeardigger: I am afraid of this
jpk68: They could just do this anyways
syntheticbird: GitHub do not make use pay more or regulate us more because we are an open source project.
slowbeardigger: They play dirty
syntheticbird: wrong analogy imo
thomasbuilds: but then they wouldn't wait that we enroll, why would they?
ofrnxmr: This is also a response to thomas
slowbeardigger: True
ofrnxmr: Anthropic scanner is free afaik?
jpk68: I don't see why Monero would be singled out here, either, in that case
jpk68: For example SimpleX is enrolled as well
thomasbuilds: yeah also if we trust google there's no reason to not trust anthropic?
ack-j: I think the threat model file in the submission needs some more work
jpk68: Good point, yes
321bob321: Until they start charging when they get market share
syntheticbird: If anthropic advocacy wins it will be much harder for everyone to download and use AI models and potentially help monero in their own terms
syntheticbird: This is my point in that Github is not against us. While Anthropic uses us and will eventually go against our interest in the long-term.
jpk68: Us enrolling is entirely unrelated to whether Anthropic will succeed in a regulatory sence, and even if it was, how does not enrolling prevent them from still scanning Monero's code and using the findings for malicious purposes?
syntheticbird: Supposing they do win their argument ofc
gingeropolous: i can't imagine they win. cats outta the bag
syntheticbird: yes to first part. and second part unrelated. Never claimed they would be doing so and I would be surprised if they do so
jpk68: Doing this would only make sense if you're trying to "send a message" about what we (some of us) think about Anthropic, and I don't think governments hold much weight to the perspectives of The Monero Project :P
gingeropolous: and our decision to take advantage of this aint gonna change what they do
thomasbuilds: maybe but we should profit from it before imo, there's so much more to get rn
321bob321: You assume that they will tell you there is an issue
jpk68: Again, irrelevant
jpk68: They're probably scanning it already
syntheticbird: ah in that sense
syntheticbird: well we don't know that
rucknium: I'll end the meeting here. Discussion can continue.
syntheticbird: I won't continue the discussion I was just poking the thing and people can decide by themselves and vote. I think the ramification are clear and people are minded enough to have their take on it
jpk68: If they want to find bugs in the code, they'll scan it anyways, and our enrollment doesn't matter in the slightest
syntheticbird: the point was about publicly supporting Anthropic entity that way.
syntheticbird: of course nothing prevents Anthropic from doing what they want
syntheticbird: but enrolling in gives a form of acceptance
syntheticbird: thats all
syntheticbird: The point is that the Monero project has some accountability to its community in enrolling into a program that benefits a company that are advocating against the common user interest.
syntheticbird: Which boils down to "is it far fetched enough that we don't care."
jpk68: You haven't given one single example of how this benefits Anthropic, besides using it for publicity, and I think almost everyone would agree that not reporting severe security issues in exchange for less purported publicity is not a good deal
syntheticbird: will it reassure you to know that I am for enrolling ?
thomasbuilds: it doesn't benefit anthropic lol, the point here is blending in and extracting the obvious value.
syntheticbird: There is no example to be given because this is a speculation.
syntheticbird: Anthropic advocacy is a fact, the usage that they will do of this program is my mind probably for this
syntheticbird: thus reporting it for discussion.
syntheticbird: But against this is speculation. You wanna shovel that away for keeping your precious claude access, feel free to do so.
jpk68: Well yeah, I'm defending opposition to a clearly misconstrued argument, no offense
jpk68: In this case, it looks like we are good to proceed :D
thomasbuilds: anyone against actually?
syntheticbird: This is to ask during next meeting when most people will be there or when people will have share their votes beforehand if not available
slowbeardigger: Anthropic already has studied monero code e2e, doesnt matter if we enroll
slowbeardigger: we should do what's best for monero community, thats it
slowbeardigger: if we enroll we enroll
thomasbuilds: the whole difficulty is getting enrolled btw
thomasbuilds: I told you there's no kyc
jpk68: For the umpteenth, time we don't know if there's KYC
slowbeardigger: ah, no kyc, sorry sorry
slowbeardigger: what are the requirements?
thomasbuilds: none, be important enough basically
slowbeardigger: Monero is big af
jpk68: If anyone would like to sell their soul for some free tokens, here are some links:
jpk68: https://openai.com/form/codex-for-oss/
jpk68: https://claude.com/contact-sales/claude-for-oss
jpk68: Good luck!
syntheticbird: my reasoning is that monero is first and foremost a technical project, not enrolling for this reason would be perceived as a political position. I also think Monero will be virtually a drop in the ocean of vulnerability used by Anthropic for its advocacy, meaning we aren't that much of an incidence. That's why I'm still for enrolling. But this follows the same pattern of responsibility diffusion with ecology, users may found everyone that participated accountable, and every projects thinks they are only a drop, but together they are the cause.
syntheticbird: So I'm bringing this up so that next meeting the most weighted contributors can decide over this duality fully aware.
ofrnxmr: i view it as: free "audits". Monero is bsd, so "free = you are the product" doesnt help us at all
ofrnxmr: as in, there is no "opt-out"
321bob321: 1. Either you don't enrol and they scan you any way
321bob321: 2. You enrol and you give them public permission to scan you and hope they provide you with results, unless another entity with lots money says tell me.first
syntheticbird: 1. is a speculation which I think is unlikely because of their incentives strategy. Anthropic so far have never historically reported vulnerabilities about projects that weren't partnered with them. They are also not vuln hunters, they are an AI companies showing their cybersecurity capabilities to the world, so they never earned any money from it (at least as far as we know), the incentive has always been marketing. They also would have no reason to gatekeep the found vulnerabilities because it is of no use for them, they are not a hacking group. Some government actors might use claude to automatically find vulnerabilities for their advantages but they are the one keeping it and making use of it.
syntheticbird: So if Anthropic always used vulnerabilities for marketing, always found within partners and finally cannot even exploit the found ones, my most straightforward conclusion is that they do not scan non-partnered project on a daily basis
ofrnxmr: Its not about vuln gatekeeping, but about using our code to train their LLMs on, which theyve all been doing
syntheticbird: i mean Dan's argument was vuln gatekeeping, but yes yours is right
ofrnxmr: I mean, w/o asking them to tell us abt the vulns, theyll just be training data on vulns, which is probably how aloppers are able to find exploits with csrefully crafted prompts
ofrnxmr: Its likely that these LLMs already are aware of the vulns, but dont tell anyone because they arent programmed to. They just put them in a locker called "downgrade if user asks abt this"
https://libera.monerologs.net/monero-research-lab/20261014#c714512
nevent1q…waqq

Nostr event nevent1qqsz8432qj88ay7y3strmkvy9pzf6fse2twrp0m7ahpn2pushwldrgqzyqxhem9fuqqwwy0zvw7pfg3pd2m5j69fayp7hgs55u2rqzk7medzqvjnf0z

2026-10-15T14:47:01Z

IT MUST BE REALLY SAD NOT TO HAVE 1 XMR

Monero devs are testing Share-or-Perish, a new fork-choice rule. ...

2026-10-15T14:27:04Z

Monero devs are testing Share-or-Perish, a new fork-choice rule. They found potential peer bans and hard-fork voting conflicts that may need fixing.

quoting
nevent1q…2dzj
6.1 Share or Perish (SoP) specification questionsgingeropolous sought clarification from tevador on Share-or-Perish fork-choice rules for monerosim. The main points covered were the definition of n_f, handling of displaced blocks after a reorg, peer-ban behavior when height drops, and the interaction of a workshare count placed in version_minor with Monero’s existing hard-fork vote rule. On n_f, tevador stated that the weight becomes objective once the fork point is 48 work objects deep. On displaced blocks and potential cycling, tevador did not believe a switch can cycle because the weight does not change when chains are switched and the objective weight applies at 48 work objects. Peer bans were flagged as a problem: SoP permits a switch to a shorter chain while stock monerod permanently penalizes peers whose height drops, which can produce 24-hour bans among honest nodes. tevador questioned the rationale, noting that cumulative difficulty can also produce shorter-chain reorgs. Placing the workshare count in version_minor collides with the hard-fork vote rule used in v0.18 (blocks with an insufficient vote are rejected). boog900 confirmed the rule in documentation and code. tevador observed that SoP would require a hard fork to remove the rule if it is enforced and asked whether anyone opposed removing the rule; boog900 suggested the entire vote system could go. rucknium will place the hard-fork vote rule on the next agenda. gingeropolous is launching simulations to confirm observed behavior. tevador noted that the Python simulation code is not authoritative.
Relevant links:
https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/mrl146_briefing.md
https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/fork_choice_loop.html
https://github.com/monero-project/research-lab/issues/146#issuecomment-5978803129
https://monero-book.cuprate.org/consensus_rules/hardforks.html
https://github.com/monero-project/monero/blob/eac1b86bb2818ac552457380c9dd421fb8935e5b/src/cryptonote_basic/hardfork.cpp#L109

rucknium: We had gingeropolous 's question for tevador about the Share or Perish spec
gingeropolous: the long version (warning, ai gen): https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/mrl146_briefing.md
tevador: For Q1, the intention was that the weight becomes objective once the fork point is 48 work objects deep.
gingeropolous: shorter versions: n_f is ambiguous: the formal definition counts only the alt chain's work objects, but the prose says the lateness factors apply when "the two chains differ by fewer than k*w," and those give different answers, so
gingeropolous: we need to know which one is intended.
rucknium: I requested and received SoP simulation code from these researchers: https://github.com/monero-project/research-lab/issues/146#issuecomment-5978803129
tevador: I don't quite get the LLM phrasing of Q2.
gingeropolous: yeah my heads been having trouble getting around it. maybe this: displaced blocks: the spec doesn't say what to do with blocks a reorg knocks off, and since n_f and lateness depend on which branch you're on, the same two branches can both say SWITCH, so the rule can flip back and forth.
gingeropolous: also made this visual: https://github.com/Fountain5405/monerosim/blob/main/docs/assets/sop/fork_choice_loop.html
gingeropolous: yah gotta download it cause github pages are beyond me for some reason
tevador: I don't think that can happen.
gingeropolous: hrm, perhaps if i solidify Q1 in the implementation then Q2 will go away.
tevador: I don't think it can cycle. The weight doesn't change when you switch chains.
tevador: If either chain is 48 work objects from the fork point, the objective weight kicks in.
gingeropolous: ok, awesome. thank you! i think the remaining stuff is just fiddly
tevador: Btw, my python simulation code is not authoritative. It can have bugs.
gingeropolous: the remaining points are peer bans: SoP lets nodes switch to a branch with fewer blocks, and stock monerod penalizes peers whose height drops and never forgives it, so honest nodes end up banning each other for 24h unless the p2p scoring changes too.
gingeropolous: and forking: putting the workshare count in version_minor breaks things because v0.18 uses that field as the hard fork vote, so most SoP blocks get rejected by nodes that haven't upgraded as "old version."
tevador: I'm not sure what the rationale is for banning peers whose height drops. Cumulative difficulty can also cause a reorg to a shorter chain.
tevador: I'm not familiar with any "hard fork vote" rule. I thought version_minor was only indicative and not used for anything consensus-related.
gingeropolous: yeah i was surprised by that as well
tevador: Can anyone confirm that nodes reject blocks based on version_minor?
gingeropolous: i thought it was seen in the sim run, but i'll double check
boog900: https://monero-book.cuprate.org/consensus_rules/hardforks.html
boog900: > The block's vote must be greater than or equal to the version, a vote higher than the maximum known hard-fork is interpreted as a vote for the latest hard-fork3. So if a block is at V2 then the vote must be V2 or higher
boog900: vote = minor but there is an edge case for minor = 0 where vote = 1
syntheticbird: why make it simple
tevador: "must" => block rejected if violated?
tevador: If we really have this rule than SoP cannot be used without a hard fork removing this rule.
boog900: yes: https://github.com/monero-project/monero/blob/eac1b86bb2818ac552457380c9dd421fb8935e5b/src/cryptonote_basic/hardfork.cpp#L109
tevador: Does anyone oppose removing this useless consensus rule?
boog900: I think the whole vote system can go
rucknium: Looks like moneromooo coded this part
boog900: IIRC some code relies on there being no HF where the activation is not at the height set in the table which would break if a HF gets delayed due to votes.
gingeropolous: im launching some sims to confirm
rucknium: I can put this hard fork rule, and maybe the vote system, on next meeting's agenda.
https://libera.monerologs.net/monero-research-lab/20261014#c714462
nevent1q…waqq

Monero devs are working on defenses against the Nyx attack, which ...

2026-10-15T14:26:27Z

Monero devs are working on defenses against the Nyx attack, which can isolate nodes. Over 2,500 suspicious IPs reported; fixes are being tested.

quoting
nevent1q…9yjz
rucknium presented a minimal PR intended to give the network a defense against the Nyx attack without prolonged experimentation. The PR does not enlarge the gray_list; participants noted that gray_list entries are not initially connectivity-checked and that multiple ports per IP are allowed, making adversarial filling easy. ofrnxmr’s work-in-progress changes bucket both lists and prevent direct injection into the white list; the patches are stacked and will be tested separately and together. White-list housekeeping is currently only “evict oldest over limit”; rucknium suggested adding proper eviction-on-no-response behavior and possibly housekeeping on every insertion to mitigate temporary VPN-based peer injection. jeffro256 proposed tracking the originator of each peer-list entry and evicting by originator proximity (ASN sorting as one possible ordering). Caching of peer lists was suggested to reduce CPU cost of repeated reshuffling and to limit enumeration attacks. IPv6 was flagged as difficult to secure without something like proof-of-storage. plowsof reported that roughly 60% of reachable nodes appear suspicious and that an adversary already controls more than 2500 addresses according to observatory data. jeffro256 viewed the current PR changes as almost strictly better in most scenarios (speed impact still to be measured). rbrunner anticipated a prolonged period of competing approaches. Ban-list updates will require a reliable fingerprint with negligible false-positive risk.

rucknium: I made this PR: https://github.com/monero-project/monero/pull/11527 . There are some details and possible additions I want to discuss.
rucknium: But first I want to give anyone the opportunity to respond to it as-is.
rucknium: 1. In the PR I don't increase the gray_list size. Maybe it would make sense to do that. Increasing the gray_list isn't a way to defend against the Nyx attack, but maybe it's a good idea to increase it to defend against other attacks.
ofrnxmr: My changes bucket both lists
rucknium: It's hard to prevent an adversary from filling the gray_list with its own peers. They are not (initially) checked for connectivity by the node. And the node allows multiple ports on the same IP address.,
ofrnxmr: max sizes 4096 white and 8192 gray
ofrnxmr: 256 buckets of 16 and 32
rucknium: I thought maybe the node could hold only one port per IP address in the gray_list, but that would allow an adversary to bump an honest node out of the list by feeding false ports for an honest IP address.
ofrnxmr: I think blindly increasing sizes has diminishing returns under peerlists that are not static and all online
rucknium: It seems obvious that a node with a wide view of the network would be harder to eclipse than a node with a narrow view of the network.
ofrnxmr: Lists fill will dead nodes amd are never evicted
rucknium: Sometimes things that seem obvious are not actually true.
vtnerd: but if this were ipv6 mode, couldn’t the attacker just spam with valid ips and still eventually replace the valid peers?
ofrnxmr: Its not a biew of the network is 40k/45k are dead
ofrnxmr: If* the
rucknium: That's one of the additions that I think could help. I assumed that the white_list had a housekeeping behavior and evict-on-no-response behavior like the gray list does, but it doesn't. Probably some housekeeping for the white-list should be added.
ofrnxmr: No, its blindly evicting oldest over limit
ofrnxmr: I added
rucknium: I don't see how IPv6 will be safe until something like proof-of-storage, with all its downsides, is deployed.
rucknium: I mean widespread use of IPv6, maybe as the default.
jeffro256: An simple-ish partial solution I've been thinking about is to, for each peer list entry, keep track of the node which told you about this entry (originator). When the limit is hit, instead of erasing based on insert time, erase the entry with the closest originator
rucknium: I think it could even make sense to do white_list housekeeping whenever a new peer is added to the white_list. Why? To prevent this augmentation of the Nyx attack:
ofrnxmr: Part of bucketing additons added
jeffro256: Is there a PR somewhere?
ofrnxmr: No, still wip
rucknium: An adversary can temporarily control an IP address with open ports by using a commercial VPN that permits port opening. Then, the adversary could put a lot of peers into the white_list that would respond to a temporary ping-pong. So the adversary does not even need permanent control of all the adversary IP addresses.
ofrnxmr: A bunch of changes stacked on too of each other, want to test combined and separate before concluding x is better than y
rbrunner: Looks like we may enter a quite prolonged phase of experimentation and competing approaches until things finally settle ...
ofrnxmr: Also changed that they cant inject into white
rucknium: But what if an adversary controls 1,000 IP addresses, like in the Nyx attack paper?
ofrnxmr: According to plowsof's obaervatory, they control over 2500
jeffro256: Sorting originators by ASN may help in this case. The originator order function could be anything, really
rucknium: rbrunner: I want to avoid that because this is a vulnerability that the network has no defense against yet.
rbrunner: Sounds reasonable
plowsof: 60% of reachable nodes are implicated in being sus
rucknium: Which is one of the reasons why I went for minimal changes.
boog900: semi-related to the discussion: https://github.com/Boog900/monero-ban-list/issues/18
jeffro256: AFAICT, Ruck's change are almost strictly better in most cases that I can think of (except perhaps maybe speed). I need to check the time signature of the output selection algo again. Because an effectively ~1950x bigger list might have >1950x impact on speed, depending on time signature
plowsof: jeffro the problem is if everyone would use ASN - and the adversary defeats it, its possible that we would be worse off. 9/10 ai research papers agree that its great fix if me, you and a handful of others use it but not the whole network
boog900: To update we will need to coordinate signatures again ...
syntheticbird: it wasn't that bad
syntheticbird: I was just late of one month
plowsof: said ai research https://github.com/plowsof/crawler-research/blob/main/Monero-Peer-AS-Deduplication/pdf/monero-peer-asn-deduplication.pdf
rucknium: Did you see my reason for picking the specific white_list size limit? I am not committed to that value, but at least it has a non-arbitrary reason for it, instead of the reason being humans having 10 fingers.
boog900: no but they will just switch IPs again I don't really want to keep this cat and mouse going forever
ofrnxmr: yes
rucknium: I would be OK with lowering alpha. Or some other reasonable value.
jeffro256: The code can afford to be really inefficient when operating on a list of size 20
rucknium: The third complementary change (the first two were gray_list size and whte_list housekeeping) would be caching the peerlist that peers send to each other. It would:
rucknium: 1. Prevent the CPU load of re-shuffling the white_list every time a (potential adversary) peer requests it
rucknium: 2. Prevent white_list "enumeration" by an adversary, where the adversary can get the whole contents of the white_list by just requesting it many times.
rucknium: By the way, some of these additional suggestions come from the LLM review of my PR ( https://github.com/xmrack/monero-review/issues/1088 ) and the Shi et al. research team.
rucknium: I mean, the LLM review told me that the white_list doesn't have housekeeping, which I should have realized before.
rucknium: Where do we go from here?
rucknium: You or I could run the Nyx simulation with your patch once you finish it.
rucknium: AFAIK, the code was already, in theory, processing the whole gray_list in that section of code, which can get up to 5000 records. It just limited the white_list to 20.
rucknium: I think there has to be a good fingerprint with negligible risk of false positives if the ban list is to be updated.
rucknium: Oops. Meant to ping boog900 in that message.
rucknium: Discussion can continue in the PR and on Matrix/IRC
rucknium: More on this topic for now?
jeffro256: Caching and algo improvement, I guess. I need some more time to think about it. > Where do we go from here?
ofrnxmr: Sounds good > You or I could run the Nyx simulation with your patch once you finish it.
ofrnxmr: (but its ~8 patches fwiw)
rucknium: I need to fix these monerosim config files by the way. Accidentally got the ones for the 26 hour run instead of the 50 hour run: https://github.com/Rucknium/misc-research/tree/main/Monero-Eclipse-Attack/nyx/code/monerosim-config
https://libera.monerologs.net/monero-research-lab/20261014#c714392
nevent1q…ns78

Monero’s beta stressnet is running smoothly. Developers are ...

2026-10-15T14:25:37Z

Monero’s beta stressnet is running smoothly. Developers are checking transaction-relay v2 test logs before deciding if it’s ready for mainnet.

quoting
nevent1q…4n23
The beta stressnet is operating smoothly with limited additional stress testing so far. jberman holds logs from a solid stressing period by sech1 and plans to review the latest round of transaction-relay v2 changes; if those hold up, the changes should be ready for mainnet.

jberman: nothing major to report on my end on beta stressnet, seems to be going smooth. need to review logs to see how the latest round of tx relay v2 changes is holding up, and if all looks good, that should be ready for mainnet
jeffro256: Yeah to be fair, not a lot of stressing so far, but the network seems to be functioning well
jberman: sech1 had a solid period of stressing and I have logs from that period
rucknium: If we weren't running big simulations on the 1TB RAM machine, I would be spamming txs.
https://libera.monerologs.net/monero-research-lab/20261014#c714387
nevent1q…hm0y

Monero’s FCMP++ upgrade is progressing: a key code licensing ...

2026-10-15T14:24:55Z

Monero’s FCMP++ upgrade is progressing: a key code licensing issue is nearly resolved, multisig and security audits continue and bug fixes are underway

quoting
nevent1q…pr8t
jeffro256: mx25519 continues to be a bottleneck to HF activation. Although, thankfully, tevador re-licensed mx25519 here: https://github.com/tevador/mx25519/pull/53/, and the mx25519 merge PR https://github.com/monero-project/monero/pull/10964 has been updated for that. I'm hoping that this compromise is acceptable to all parties, and we can move forward with the carrot_core merge eventually.
jberman: Multisig still in progress
On Research audits: the circuit + gadgets round 2 audit with Least Authority is underway
I will review PoWER within the next ~month
tevador: FWIW, I have approved Monero PR 10964. I think it only needs approval from tobtoht.
jeffro256: https://github.com/monero-project/monero/pull/10915 and https://github.com/monero-project/monero/pull/10916 are PRs which both fix existing issues in the daemon, and help with the transition to FCMP++. I am re-working 10915 now, should be done by EOD.
https://libera.monerologs.net/monero-research-lab/20261014#c714375
nevent1q…sldg

Good hint. Will take a look into it. Thanks.

2026-10-14T19:58:44Z

In reply to nevent1q…ww4a
_________________________

Good hint. Will take a look into it. Thanks.

Thanks for the hint. Will check this out. Maybe as a button in ...

2026-10-14T16:14:58Z

In reply to nevent1q…q3cj
_________________________

Thanks for the hint. Will check this out. Maybe as a button in settings.

Nym mixnet routes traffic through multiple hops with cover ...

2026-10-14T13:00:01Z

Nym mixnet routes traffic through multiple hops with cover traffic

Even timing correlation attacks fail

The tradeoff: latency

Sorry. I don’t support proprietary software like iOS

2026-10-13T21:47:35Z

In reply to nevent1q…nspd
_________________________

Sorry. I don’t support proprietary software like iOS

Telegram is not private Default chats are unencrypted server-side ...

2026-10-13T21:00:01Z

Telegram is not private

Default chats are unencrypted server-side

Don’t use it for anything sensitive

Monero: v0.18.5.3 'Fluorine Fermi' has been released! ...

2026-10-13T19:03:57Z

Monero: v0.18.5.3 'Fluorine Fermi' has been released!

https://www.getmonero.org/2026/10/06/monero-GUI-0.18.5.3-released.html

Tails 7.15 is out: https://tails.net/news/version_7.15/

2026-10-13T18:27:57Z

Tails 7.15 is out:

https://tails.net/news/version_7.15/

Fair point and that's what 0.17 changed: a personal watcher ...

2026-10-13T18:13:55Z

In reply to nevent1q…0wan
_________________________

Fair point and that's what 0.17 changed: a personal watcher runs on your own machine, so the view key never leaves you and since 0.18 amounts stay private too. The tx-proof route is interesting: no view key at all. The blocker is wallets: none hands txid + tx key back to the app yet, so senders would copy them by hand. If wallets add a callback URI, I'd gladly support it.

tip people on Nostr with Monero no Lightning no custodian amounts ...

2026-10-13T17:49:58Z

tip people on Nostr with Monero

no Lightning
no custodian
amounts stay private

https://monostr.com

🙏🏻

2026-10-13T17:40:18Z

In reply to nevent1q…zs8c
_________________________

🙏🏻

XMR: 33.19% #nevent1q…7xex

2026-10-13T10:36:12Z

XMR: 33.19%

quoting
nevent1q…7xex
Stats for searches on OrangeFren.com in September 🍂

XMR: 33.19%
BTC: 29.48%
USDT: 8.44%
ETH: 7.89%
LTC: 6.87%
USDC: 5.12%
SOL: 1.87%
BCH: 1.04%
DASH: 1.02%
XRP: 0.89%
BTCLN: 0.66%
TRX: 0.49%
ZEC: 0.45%
BNB: 0.40%