<soh01:matrix.org> this*

<soh01:matrix.org> Hi, is there where the lab meeting will proceed?

soh01: yes, in about 12hr

<soh01:matrix.org> thanks Ukoe

<fatcow:matrix.org> tevador: might be interesting for your channel proposal > <@fatcow:matrix.org> mrelay.p2pool.observer/m/matrix.org/lcKJXQKuTumeomzRdZCdShvH.zip (monero-channel-lean-proofs.zip)

<rucknium> Trail of Bits audit of the FCMP++ integration Phase 1: github.com/trailofbits/publications…nerofcmp++crypto-securityreview.pdf

<rucknium> It was already shared in the #no-wallet-left-behind:monero.social channel.

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

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

<rucknium> 1. Greetings

<vtnerd> hi

<boog900> hi

hallo

Hi

Hello

<jpk68:matrix.org> Hello

<syntheticbird> Hi

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

<jfuffjcjkdrngisozkfng:matrix.org> Hi

<jberman> waves

<rucknium> me: Keeping stressnet stressed and investigating bugs on it. Read Shi, Zhang, Ge, Lan, Zhang, & Wang (2026) "Deanonymizing Monero Transactions in Tor Network." (arxiv.org/abs/2607.07062)

<articmine> Hi

stressnet/scanning updates and checking all the new incoming changes to FCMP++/Carrot for post-stressnet changes (and updating my libraries)

me: mx25519 + relative time-locks

<vtnerd> me: hopefully done with p2p-write-starvation, and working on checking all my outstanding prs/branches (mainly ssl and fcmp++)

<boog900> I posted an update on Cuprate's RPC here: monero-project/meta #1428#issuecomment-5107322419 it has graphs which compares how both scale with more wallets, thought it could interest some people here.

<jpk68:matrix.org> Me: continued work on I2P-related things, reviewing a few PRs, squashing some bugs in hardware wallet code

<gingeropolous> me: started using monerosim to test some things. fiddled with / added cuprate support

<jberman> me: continuing FCMP++ integration PR, the Trail of Bits audit was released: github.com/trailofbits/publications…nerofcmp++crypto-securityreview.pdf. With @rucknium's help, should hopefully have beta stressnet v2.1 out by next week that solves the wallet's sporadic errors (reviewing to make sure all fixes are working as intended)

<rucknium> FCMP++ to-do list status. Programming tasks (seraphis-migration/monero #53). Reviews and audits (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed). FCMP++ Integration Audit Overview (seraphis-migration/monero #294).

<rucknium> Agenda item 3 ^

<rucknium> Last meeting, some participants wanted to wait for the Trail of Bits audit before making decisions on some FCMP timeline items. It's here now: github.com/trailofbits/publications…nerofcmp++crypto-securityreview.pdf

<rucknium> Is right now a good time to discuss it?

<jberman> Here's the latest FCMP++ integration PR with some discussion there on next steps to get that code in: monero-project/monero #10359

<jberman> Sure

<rucknium> Does anyone want to elaborate on what Trail of Bits means by the Rust-C++ Foreign Function Interface (FFI) being "fragile"?

<rucknium> And that was the only issue they found that was not completely resolved by a fix.

<jberman> They mean that if the upstream type changes and/or is written to on the C/C++ side, it may be rendered incorrect. Since the upstream type comes from another lib (a fork of crypto-bigint), we'd have to be careful of that occurring. The static asserts included are a strong defense in the event of such a scenario

<rucknium> I will ping @jeffro256:monero.social too

<syntheticbird> I like their concerns but serialization would kill performance

unsafe{ performance }

<rucknium> So we need version pinning on the external library. I think you already do that anyway.

<jpk68:matrix.org> It would be nice if the code could be vendored into a separate repo (not src/fcmp_pp/fcmp_pp_rust, I mean the dependencies)

@jpk68:matrix.org: Given that even this recent PR had mismatching versions of several core packages, vendoring critical dependencies would be a plus

<jberman> @rucknium: Yes, we do pin versions. We'll probably need to update to a more recent version of the upstream lib at some point (I think we need to already), and so we'd want to double check it with that latest version we update to

Changes to these would be more obvious in reviews and allow dev copies in other platforms to not depend on crates.io or the specific git/forge they are stored, but have code local

<rucknium> IIRC, @tobtoht:monero.social is keen on vendoring external libraries.

<syntheticbird> rightfully

<rucknium> More comments about the ToB audit?

<jberman> Vendoring sounds fine to me. @kayabanerve:matrix.org may have thoughts there too

So watching the original libs for importing changes to "vendor in" again is the lesser evil?

About the uninitialized receiver/output, that's a kind of scary find. I found similar issues on other languages/code while implementing parts of Monero (which caused some fun aftermath words.filippo.io/dependabot )

ToB recommends additional steps to prevent issues like this in the future/more static tooling. Would that sort of hardening be sought for?

<jpk68:matrix.org> I would also like to bring up the impact of FCMP++ Rust code on binary sizes. I seem to remember tobtoht suggesting we remove the 'utility' binaries from release archives on the site to save space because of the increase.

Specially as a lot of the Monero crypto code, while sounds, comes from the legacy times where it was all uncommented single-letter variables, which took time to untangle (see biased hash / elligator 2 for the hash to point / key image)

<jpk68:matrix.org> IMO, we should reconsider applying the strip option to the release profile, and maybe fat LTO

<jberman> Imo more relevant than the ToB audit as it relates to FCMP++ audit work generally:

<jberman> @xmrack:monero.social identified a detectable double spend vuln in the consensus integration code, highlighted here: seraphis-migration/monero #446

<jberman> This (consensus integration) would have fallen under the scope of "Phase 3" in the integration audit plan

<rucknium> If I may ask, did an LLM assist with finding @ack-j:matrix.org 's bug?

👍️ > <@jberman> @xmrack:monero.social identified a detectable double spend vuln in the consensus integration code, highlighted here: seraphis-migration/monero #446

<rucknium> Trying to understand the role of LLMs in finding these types of bugs.

<jeffro256> Howdy, sorry I'm late

<jberman> @rucknium: Yes

<syntheticbird> what LLM ?

<jeffro256> He mentioned using Opus on a different FCMP report

<jeffro256> So maybe Opus?

It doesn't matter, all of the available top-tier LLMs should be used to check this code for vulnerabilities. And multiple times.

<syntheticbird> alr

<syntheticbird> sech1, i agree on that and i am not trying to frame one model to be better than another, it's just curiosity.

<jberman> sech1: I'm in favor of this as well

<syntheticbird> speaking of LLM audit I came across github.com/evilsocket/audit recently

<syntheticbird> for those who have the tokens probably worth a try

that looks neat for a more automated setup

<rucknium> Just thinking out loud: If today's LLM catches critical bugs now, and tomorrow's LLM is even better, then what happens when tomorrow's LLM finds a critical bug after the hard fork occurs?

<rucknium> I don't like this new reality :(

There should not be just LLM review, it's in addition to any other normal reviews

<syntheticbird> Continuing on thinking loud: useless to recall how blueteam and other malicious actors caused a surge in critical vulnerability exploits on many DeFi projects when Opus started coming out

<syntheticbird> blueteam = v12 = zellij

<syntheticbird> zellic*

@rucknium: This can be changed to "If today's cryptographers catches critical bugs now, and tomorrow's cryptographers learn new research then what happens when tomorrow's cryptographers finds a critical bug after the hard fork occurs?" and still has the same meaning, use all available way to audit and protect/cover.

<gingeropolous> difference is, joe shmoe can run an llm ... but joe shmoe isn't a cryptographer

<rucknium> Does Monero code need to do what aerospace code does and over-engineer all the code and code-writing processes in safety-critical areas?

☝️ > <@rucknium> Does Monero code need to do what aerospace code does and over-engineer all the code and code-writing processes in safety-critical areas?

<vtnerd> I would also expect diminishing returns on the llm advancement, but that's just a fut feeling

<vtnerd> *gut

There's areas that can be upgraded/covered and others that cannot without consensus-breaking changes (or tightening that need to be hidden)

<boog900> You would be asking for like a full rewrite :)

<jeffro256> We could have said the same thing about cryptographic research by humans, albeit on a slower timeline. If cryptographic knowledge gets better and better, what hppens when people figure out ways to break current cryptography? The answer has to be vigilance and the constant cat-and-mouse game, like it always has been

<syntheticbird> @boog900: yeah this lmao

Specially if you cannot "hide" such changes in patches like done in the past (for example, the double-spend bug related to twisted outputs)

This boomer would advice, in addition to everything already said, to take each and every chance to avoid complexity

<rucknium> We are at a specific inflection point in time. Like when old-style crypto was being broken.

not sure if this was linked yet but ack-j also has a fundraiser for fuzzing, including fcmp++ (though afaik this won't include LLMs, just regular fuzzing) donate.magicgrants.org/monero/projects/fuzzing-monero-2

<syntheticbird> DataHoarder[m]: well there was an instance of hiding failure

<syntheticbird> in the past

<rucknium> I don't mean to throw a wrench in the gears, but there have been at least 3 privacy coin counterfeiting bugs revealed this year (Litecoin MWEB, Zcash Orchard, Beam).

And with today's automation flows you can even review binary changes and recover original flow/intent to do even tighter analysis/diffing across releases to catch not mentioned changelog items.

<syntheticbird> @rucknium:monero.social, I agree with you that crypto out of all other domains are the ones being hit the hardest on AI vulnerability findings because of the extreme investment to reward ratio. We can't just ignore it

@rucknium: Then I'd repeat my above concern with the uninitialized output, which could have caused "fun" issues, and work on ways that such issues could have been captured early on

<syntheticbird> i sounds like an AI bro and I hate it

Some process that can run concurrently, or within PRs as well in a lighter form, and generally review incoming areas or overall integration using classical methods or anything needed. Even pointing out general "Smell" should be a cause of concern if we are talking about safety-critical areas.

<rucknium> Full disclosure: I sort of predicted this problem and my old mindset is coming back. I'm not a cryptographer nor a real programmer, so what do I know? :D

<syntheticbird> DataHoarder[m]: generally my philosophy is that if safety is critical, your must increase formal verification coverage

<jpk68:matrix.org> Sorry for bringing this up for the hundredth time, but as others have stated, it's extremely important to reduce unnecessary code complexity (which can shelter exploits). I think introducing Rust with FCMP++ is doing exactly the opposite of this; potentially investing in the code being rewritten to avoid such complexity would maybe be worthwhile.

<boog900> No that would take too long

<jpk68:matrix.org> FCMP++ already brings a huge number of changes in critical pathways; the FFI stuff is not helping the matter

@syntheticbird: then such formal verification should be in PR, I agree. And that should be included along

<jpk68:matrix.org> @boog900: Not before the hardfork per se, I just mean eventually

<boog900> eventually I agree

<boog900> I want multiple impls

<jpk68:matrix.org> I would totally be against delaying the hardfork for that

<syntheticbird> @boog900: I want variable time for nodes

> <@jpk68:matrix.org> Sorry for bringing this up for the hundredth time, but as others have stated, it's extremely important to reduce unnecessary code complexity (which can shelter exploits). I think introducing Rust with FCMP++ is doing exactly the opposite of this; potentially investing in the code being rewritten to avoid such complexity would maybe be worthwhile.

I generally agree that the Rust monero-oxide/Cuprate rewrite is vastly easier to read/follow than C++ specially when using undocumented load-bearing crypto operations from cryptonote era :)

<jpk68:matrix.org> selsta: And fuzzing as well, of course ^

<syntheticbird> its 44 shouldn't we move to another topic ?

<syntheticbird> @rucknium:monero.social:

<boog900> On the list of big C++ work that needs to be done I wouldn't put an FCMP rewrite high though

<rucknium> IIRC, @jeffro256:monero.social wanted to get input on timeline for integration audit parts 2 and 3

<rucknium> So we should get that input in this agenda item unless @jeffro256:monero.social does not want it at this meeting.

<jeffro256> Yes, I asked the question last MRL IIRC, whether the 6-month wait period should depend on the completition of audit parts 2 and 3. I don't think it should, but I think we should plan for audits 2 and 3 to completelt at least 3 months before the HF activation date, and plan for a period of follow-up development where we fix issues, if any, from those audits parts.

<rucknium> And we were promised a Gantt chart :)

<jeffro256> ;)

<jeffro256> html-preview.github.io/?url=https:/…/blob/master/fcmp%2B%2B-carrot.html

<syntheticbird> lmao

<jberman> @jeffro256: I have the same view

<jeffro256> Some people wanted to see the first audit report findings before making the decision. I think that link has already been shared, correct?

<syntheticbird> Yes > <@rucknium> Agenda item 3 ^

<syntheticbird> below i miss click

<rucknium> @jeffro256: Yes

<jeffro256> With that current Gannt chart I shared, according to discussions in NWLB yesterday, I have the 6-month wait period before HF activation depend on the first HF-enabled merge to master. I have a 1 month node/p2p/consensus code freeze dependent on that merge too. I have a 2 month code freeze on wallet features and any audit-related follow-up development before the HF activation

<jeffro256> Does all of that sound reasonable?

<rucknium> @jeffro256:monero.social: Thanks for the detailed chart

<rucknium> @jeffro256: Sounds ok to me

<jeffro256> That puts FCMP++ HF activation at the beginning of February if we stay on this schedule

<rucknium> Anyone else want to comment on @jeffro256:monero.social 's proposed plan?

<jeffro256> Which means locking in for a lot of code merging for the next month

<rucknium> And if not, anything else to discuss during this agenda item?

<rucknium> 4. Relative locks with FCMP++ (monero-project/research-lab #161).

<rucknium> tevador

I posted updates on github. I don't want to delay the meeting, so the only thing I'd like to discuss is this proposal: monero-project/research-lab #161#issuecomment-5100079175

<rucknium> I have a question about tx distinguishability with the payment channel relative locks. Do the payment channel lock txs have to set the FCMP tree anchor when they are created, or can they be updated with pre-signing?

<rucknium> Maybe my question isn't very clear, but I hope I conveyed what I was getting at.

No, the FCMP tree anchor is always selected just prior to tx submission.

<rucknium> Thanks.

The FCMP "reference_block" field is not signed with the spend authorization proof.

Would a soft-introduction of such locks mean that we would have a mixed network, some nodes would honor the locks, some not? And if yes, would that fly?

*soft-fork-introduction

That's not how soft forks work. Soft fork activates when >50% of miners start following the rule. Everyone else then follows the longest chain.

<jeffro256> > <tevador> I posted updates on github. I don't want to delay the meeting, so the only thing I'd like to discuss is this proposal: monero-project/research-lab #161#issuecomment-5100079175

<jeffro256> I think that the idea in this PR seraphis-migration/monero #445 is fine. Since, the non-standard behavior happens when unlock_time=1, restricting the unlock_time to equal 0 is a soft-fork back to standard behavior.

<rucknium> By the way, we know roughly what percentage of spent outputs are more than 24 hours old, thanks to the OSPEAD estimates. It is 1/3rd.

<rucknium> Check the bottom part of the plot here: rucknium.github.io/OSPEAD/CCS-miles…decoy-distributions-top-1-3-not-log

Ah I see, that's a difference to normal functionality introduced in updates.

For Bitcoin, ~20% of spends are >24 hours

<boog900> IMO I don't think we really need or should have decoys which say they were locked when they were not.

<jeffro256> Makes sense. Higher volume coin, which has more exchanges per user, has lower median spend time

I think we don't need to discuss the details of time-locks now, only if it's worth reserving unlock_time = 1 for it.

<boog900> I am ok with reserving unlock_time = 1

<rucknium> @boog900:monero.social: I am leaning toward your position on that. You are kind of forcing some users to disclose to their tx recipients that their outputs are more than 24 hours old. That's a small privacy leak, but it's a little unfair because it's for the benefit of the payment channel users.

<jeffro256> I am also okay with it as long as no reference wallet software uses it

Uses it? How could that happen?

<rucknium> @jeffro256:monero.social: Also Monero has its 10-block lock and you cannot spend txs in the same block. IIRC, about 8% of BTC outputs are spent in the same block they are created in.

<boog900> @rucknium: Exactly, especially as, from what I read in the proposal, locked txs are only published in the case where there is misbehaviour

Btw, only payment channel force closes reveal use unlock_time = 1, which would presumably be a tiny percentage of all payment channel closes.

<jberman> A risk with the proposed upgrade plan IIUC: if a minority of nodes update, then start seeing txs with unlock_time=1 and reference_block<720, then those nodes would be split from the network

<jeffro256> Also, ostensibly , in a payment channel close, the tx output recipients would be yourself, so you're not leaking that info to a counterparty

<rucknium> IMHO, tx heterogeneity matters most when it's a consistent pattern for every tx created by a user's wallet. If a user creates an unusual tx once, but not before or afterward, then you don't have the tx linking issue.

jberman: that's a general soft fork issue, not really related to the proposal. Generally, soft forks activate based on >>50% miners signaling support.

To clarify: if >50% of miners support the soft fork, non-updated nodes follow the rule because the longest chain follows the rule.

<jberman> Fair

<rucknium> Is it intended to change the name of the unlock time variable in the code to reduce confusion?

<jberman> I'm OK with reserving unlock_time = 1 also

<rucknium> I am ok with tevador 's proposal monero-project/research-lab #161#issuecomment-5100079175

I think it's OK to keep the name "unlock_time".

<earthman:unredacted.org> sech1: Take a look at your donos. Stay silent about the amount please

<earthman:unredacted.org> @earthman:unredacted.org: It is for monero audits, P2Pool and a part for yourself

<earthman:unredacted.org> You can share with DataHoarder[m] if you want

<rucknium> More discussion of this item?

🙇 > <@earthman:unredacted.org> You can share with DataHoarder[m] if you want

<rucknium> 5. Shi, Zhang, Ge, Lan, Zhang, & Wang (2026) "Deanonymizing Monero Transactions in Tor Network." (arxiv.org/abs/2607.07062)

<rucknium> @jpk68:matrix.org and @syntheticbird:monero.social

<syntheticbird> I've read the paper and I have a piece to say

<jpk68:matrix.org> I did end up looking through the paper, and from what I can tell, the heuristics outlined are mostly legit. It's basically a three-part pipeline that attempts to correlate outgoing transactions to Tor identifiers, and then those identifiers to IP addresses.

<jpk68:matrix.org> The first out of three was indeed patched well over a year ago (by vtnerd in #9632), which seems to fix the issue of hidden-service nodes leaking their own onion addresses

<rucknium> I read this paper. I want to give others the opportunity first to comment

<syntheticbird> @jpk68:matrix.org: I disagree

<jpk68:matrix.org> However, the other two appear to be unpatched to this day. The remaining heuristics include the fact that proxies are not chosen uniformly from "neighbour" peers (instead, based off of a self-reported and unverified block height parameter), and there is also no rate limit sync/ping messages, which lets Tor relays see a timing [... too long, see mrelay.p2pool.observer/e/wOPvxJsLdFB2WDFr ]

<jpk68:matrix.org> So, if I understand correctly, we should immediately try to patch the proxy selection bias (and also add more checks for false self-reported block heights), plus add rate limits for random timed sync request flags per connection

The fake-height bias is quite puzzling to me, I couldn't find it in the code.

<rucknium> I don't know how to fix the fake-height bias except to ask the Tor peer to send all the "new" blocks over Tor, which would take a while. And it's only an attack-augmenting technique. Just reduces the number of machines you need to execute the attack.

<syntheticbird> From my understand the fix from vtnerd was to shuffle the onion address place in the local peerlist being sent at TSR. But unless my understand is incorrect, this do not remove the fact that the onion address is being sent at every TSR. Which makes it longer to correlate but still doable.

<jpk68:matrix.org> tevador: The code I looked at for this was in cryptonote_protocol_handler.inl, lines 456 to 494

<jpk68:matrix.org> There appears to be no upper bounds check in process_payload_sync_data()

<rucknium> @syntheticbird:monero.social: You mean you could keep requesting peer lists and see which peer address always appears in every response?

<syntheticbird> @rucknium: Exactly.

<syntheticbird> I think the paper is elegant and exploit weaknesses effectively. I will not able to convince people here that will consider this as a nothing burger because you need to workout with adversarial Tor guards.

<jpk68:matrix.org> @syntheticbird: IIUC, this still mostly fixes the first step out of three, yes?

<syntheticbird> I think the Tor Project is compromised and this paper actually shows an attack that while not scaling to the entire network can be added to the arsenal of Chainanalysis and Co

jpk68: I read that and I don't think that's it.

<syntheticbird> @jpk68:matrix.org: This only make the correlation takes longer, it do not erase it

<rucknium> IMHO, compromising the Monero node's Tor guard node is the least plausible part of the attack. Not feasible without a lot of machines. Tor specifically tries to defend against that.

<syntheticbird> identity_role stage

<jpk68:matrix.org> Yeah, but it eliminates the ability for it to be done passively

The correct fix for the onion address leak would be to insert own address before truncating the list to 250 peers.

<syntheticbird> @rucknium: That is if you believe Tor project to be genuine but that is another topic entirely. There multiple points i would like to address

With randomized insertion*

<rucknium> But IMHO, even if you don't get the true IP address of the node, you could probably still link a user's txs together if they come from the same node. So there are still issues to be addressed.

<boog900> this github.com/monero-project/monero/bl…ote_protocol/levin_notify.cpp#L151? > <tevador> The fake-height bias is quite puzzling to me, I couldn't find it in the code.

<monerobull:matrix.org> What would you guys recommend if the goal is to hide transaction origins and you don't care about the ISP knowing you run a node? --proxy, --tx-proxy (even though there is this attack, or maybe even both?

<rucknium> I liked that they "defeated" the noise protocol by actively sending timed messages. But the noise protocol wasn't intended to defeat an active adversary. It was designed to hide info from a passive ISP_level observer AFAIK.

<vtnerd> the biggest issue with linking tx to identity is that you can effectively “break” the ring. this closes with fcmp++

<syntheticbird> I join you @rucknium:monero.social, The bias selection is the most serious issue in my opinion and I would go as far as saying this bother me that they can so easily distribute 5000 new onion addresses to a node and it not asking any questions.

<boog900> @boog900: maybe should add a few blocks of allowance

<syntheticbird> Understand by that that I think the node should do some basic sanity check and reject a peerlist if its entirely composed of onion addresses it never heard of (at least when its own peerlist is full)

<rucknium> @syntheticbird:monero.social: I also liked that the paper gave a specific hardware requirements list to Sybil attack Monero onion hidden services. That's a point that @boog900:monero.social and I made in our MoneroKon presentation last year, but we didn't have the numbers.

@syntheticbird: in P2Pool we only add onion addresses when they get included in a share (which has certain POW) and these timeout after a while when they leave certain window

not doable here, ofc, as otherwise spamming onions is free

<rucknium> That presentation is "Defeating Spy Nodes on the Monero Network" github.com/Rucknium/presentations/b…oog900-MoneroKon-2025-Spy-Nodes.pdf vimeo.com/1095371245

<syntheticbird> @rucknium: where ?

boog900: Thanks, that looks like it.

<rucknium> The hardware requirements are on page 9

<syntheticbird> Or right thanks I skipped that part

<syntheticbird> the hardware part

<syntheticbird> and forgot about it

<syntheticbird> DataHoarder[m]: why wouldn't it be doable ?

<boog900> We could not share onion addresses with connections we intend to send txs to at all and close the connection after 1 tx

you'd need to attach these onions to some sort of timed pow that adjust based on a rate, so... monero blocks :)

<jpk68:matrix.org> The paper also mentioned some mitigations (which are beyond my understanding) related to extending the Dandelion++ stem phase ambiguity

<boog900> @boog900: litterally just send the tx

mining a monero block to get included is quite expensive

<vtnerd> > <@rucknium> I liked that they "defeated" the noise protocol by actively sending timed messages. But the noise protocol wasn't intended to defeat an active adversary. It was designed to hide info from a passive ISP_level observer AFAIK.

<vtnerd> they do this to get the last peer (which has been patched), how is this still effective? you’d need a passive+active adversary to use timed sync messages … ?

<syntheticbird> DataHoarder i get it thx

<rucknium> The paper says to 1) Eliminate the own-address identification (at least partially addressed already) 2) Extend the Dandelion++ protocol to the Tor tx-relay side (would slow down tx propagation and be complicated to implement), and

<rucknium> 3. Limit the timed sync requests in the Noise protocol to prevent the active watermarking of tor connections.

<syntheticbird> Yeah I am impressed by the watermarking part

<rucknium> @boog900: @boog900:monero.social: How persistent are Monero peer IDs on the Tor side?

<syntheticbird> This is the type of attack you would never thinkg about because of how cumbersome it sounds yet it works

<boog900> everyone sets a PeerID of 1

on tor, peer id = 0, no?

1*

<syntheticbird> @syntheticbird: All peer id are 1

<syntheticbird> wrong answer + lag

<boog900> how does bitcoin protect itself?

<boog900> or does it not? It allows everything over Tor too

<syntheticbird> I don't think it does

<boog900> blocks etc

<syntheticbird> May I propose a radical solution to resolve 2 and 3

<vtnerd> I thought of this, thus the attempt to do white noise, but its certainly difficult to patch ontop of an existing p2p thing > <@syntheticbird> This is the type of attack you would never thinkg about because of how cumbersome it sounds yet it works

<vtnerd> its impressive they indeed were able to do watermarking, as I just looked at wireshark and determined it was plausible

<vtnerd> it may be impossible to stop, because the remote side can always send data

<earthman:unredacted.org> Do we track onion nodes? > <@syntheticbird> I join you @rucknium:monero.social, The bias selection is the most serious issue in my opinion and I would go as far as saying this bother me that they can so easily distribute 5000 new onion addresses to a node and it not asking any questions.

<rucknium> @vtnerd:monero.social: I think I agree with you that the watermarking would only be useful combined with Tor guard node compromise and discovering the onion address of the target node. > <@vtnerd> they do this to get the last peer (which has been patched), how is this still effective? you’d need a passive+active adversary to use timed sync messages … ?

<earthman:unredacted.org> Is there a list of all onion nodes?

<rucknium> @earthman:unredacted.org: I don't know of anyone actively probing the number of onion nodes. I mean, anyone on the MRL-friendly side of things.

<syntheticbird> @syntheticbird: I think that over Tor white noise needs to be extended to every message and enforce penalty on not respecting a give frequency.

monero.fail lists some onion ones

<earthman:unredacted.org> Aren't there already 5000 malicious ones? Who is tracking > <@syntheticbird> I join you @rucknium:monero.social, The bias selection is the most serious issue in my opinion and I would go as far as saying this bother me that they can so easily distribute 5000 new onion addresses to a node and it not asking any questions.

<syntheticbird> It make no sense that you can send a TSR every 20 sec

<rucknium> monero.fail and similar services have lists of the RPC onion addresses of Monero nodes, but that is different from the tx-relay addresses

<boog900> @syntheticbird: please no 😭

specially ones with RPC

<vtnerd> @syntheticbird: yes, likely this, otherwise we should just give up and try nym or something

<rucknium> AFAIK

<syntheticbird> @boog900: "if someone's oppose to this wedding now is time to speak"

I don't think we should focus on attacks that require a compromised guard.

<boog900> I just don't want to add that logic to Cuprate and would question if it would even work with how dynamic our message sizes are

<syntheticbird> If we send periodicly fixed size messages at a given frequency even tho we don't send any message at all we break watermarking and don't need dandelion because no one will be able to do a timing correlation attack. It does however expose monero usage pattern to any relay observer

<syntheticbird> tevador, 2 years ago Tor project reported that 30% of its nodes were own by a single entity.

<syntheticbird> We need to accept the reality that Tor is not the holy grail

@syntheticbird: what is this frequency? if it's a local clock started when node started, this can be used as a fingerprint source

<monerobull:matrix.org> @monerobull:matrix.org: Any ideas?

I'm not saying it's not a problem.

<syntheticbird> DataHoarder[m]: that would be random and negotiated at handshake

<jpk68:matrix.org> @monerobull:matrix.org: I mean, you could also try and use I2P

@syntheticbird: an active prober with ISP viewpoint would be able to abuse this, specially if random

it'd be able to randomize to an interval that is unique, and change it every once in a while

<syntheticbird> DataHoarder[m]: true, well my idea is shit

@jpk68:matrix.org: I had to disable I2P (C one) due to active RCE... maybe time to try the (ugh) java one

<jpk68:matrix.org> Yes, the C++ implementation's security is... not ideal

<syntheticbird> I still think we should instantiate penalty on TSR being sent with a delta time from average that is too high

<syntheticbird> * the peerlist sanity check i mentioned before

<syntheticbird> if your peerlist is full there is no reason someone is just giving you 250 new nodes you never heard of

<rucknium> Would the peerlist sanity check be very effective? An adversary could just fill your peer list slowly instead of quickly.

<vtnerd> it makes watermarking harder has they get one shot per connection. and it makes filling up the table take longer (but not prevent)

<vtnerd> or I guess they could still watermark if they are more patient

<syntheticbird> Yes they can adapt without a doubt. I just think this makes the time cost considerably larger and feels like common sense enough that this mitigate trivial adversarial

longer is not long enough unless it's effectively untractable

specially for daemons/servers with 24/7 uptime

<boog900> @syntheticbird: I have suggested this too for clear net

<boog900> I think it's what bitcoin does

<vtnerd> one thing that no one mentioned is that not setting up inbound connections likely provides better privacy

<boog900> it makes you slightly more vulnerable when starting up but more secure to attacks after that

<syntheticbird> nice i didn't know that

<rucknium> Nym has ports 18080, 18081, and 18089 open for Monero nodes: forum.nym.com/t/nip-3-nym-exit-policy-update/1462

<syntheticbird> The issue with Nym is that the target you connect to is not anonymous

<syntheticbird> only outgoing connections are protected

<rucknium> We can continue to think about this one. I'll keep it on the agenda for next meeting.

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

<rucknium> @jberman:monero.social and I think we have the bug fixed where wallets forget that they spent an output and try to spend it again, causing a double-spend error on the Node side.

<rucknium> Over 1.2 million txs from 48 separate wallets were sent to nodes with the patches and the problem did not occur in any of them.

<jberman> Shooting for v2.1 by next week's meeting, with above issue (finally) solved

haven't seen any major altchains over past few weeks

<rucknium> DataHoarder[m]: Fewer miners, probably, Not strong evidence that alt chains are rarer.

<rucknium> @jberman:monero.social: What are the goals for stressnet beyond v2.1?

I agree. There is some new miners or ones with low hashrate now listed on stressnet.p2pool.observer/pools

<rucknium> Do we have a specific block size goal?

<rucknium> I am moving things around so I can broadcast even more txs, but it will be tedious. And I'll occupy most of the MRC resources if we go a lot higher.

<jberman> I didn't have a specific block size goal in mind. Stability under consistent stress (which the stressnet has experienced) was the target I was shooting for. And this set of issues seemed like the most significant lingering. Obviously we can continue with fixing the most blatant issues (e.g. slow perf when the pool is huge), bu [... too long, see mrelay.p2pool.observer/e/noaGxpsLd0NDZ3ln ]

Syncing a wallet via monero-cli has had some abysmal performance when I tried a few days ago, even after some patches @ofrnxmr:monero.social provided. It surely does more work than just what I am doing myself, but for the explorer I am currently syncing up 130 different wallets at once on stressnet, without much CPU usage on my block explorer (With a lookahead depth of +5000 accounts)

Besides the high RAM usage of cli wallet, most of the debugging pauses I did landed on hashmap growth/insert code.

<rucknium> DataHoarder[m]: You feel my pain :D

the good performance allowed to scan one OUTPUT per two seconds

before it was one output every few minutes...

That might be a limiting factor if @rucknium:monero.social tries to grow the spamming further :)

<rucknium> It shouldn't be that bad

<ofrnxmr> every few mins is related to changing the lookahead

<rucknium> That is outputs that the wallet owns or does not own?

outputs they own, it skips successuly not owned ones

<boog900> monerod scales awfully with more wallets

for ones it owns it uses just one core, 100% of it, doing hashmap work :)

not monerod mind you, wallet-cli

<jberman> Def does sound like a bug with subasdress expansion there. And plausibly other wallet sync perf stuff affecting fiatdemise in the stressnet channel can take a look at

<jberman> Subaddress*

that lookahead growth shouldn't add +1 whenever an output is received, we should be growing 1.5x or something to not trigger this growth so often

<ofrnxmr> @jberman:monero.social the patch i gave him is yours

<rucknium> @ofrnxmr: @ofrnxmr:monero.social: Do you know if I am affected if I reduce the lookahead compared to the default lookahead?

<ofrnxmr> If you change the lookahead at all, it causes issues

I increased account lookahead to try to sync one of @rucknium:monero.social's spam wallets :)

<rucknium> And I thought I was being more efficient

as with defaults it didn't reach enough to start catching all outputs

<ofrnxmr> @ofrnxmr: (i think)

<ofrnxmr> Been a while since i tested

either way can discuss more about that lookahead behavior/perf in stressnet channel

<jberman> I remember that one. That was an upstream issue ya? Potentially new wallet side changes still playing a role > <@ofrnxmr> @jberman:monero.social the patch i gave him is yours

just raising it as an issue for maxing out block sizes/spam

<ofrnxmr> Yeah

<ofrnxmr> A regression from the set subaddress-lookahead pr

<rucknium> Maybe I'm not affected because once I get spamming going, I don't produce more subaddresses.

@rucknium: tbh the efficient way (for your wallet) to spam would be to send everything to main address+just a few subaddress, then specifically spend outputs, not accounts. Ofc, what you are doing is now also stressing the wallet, so hey, it did accomplish that :)

@rucknium: Due to the way the spammer does it it doesn't change the lookahead directly as it generates the indices directly, but creating it anew without the spammer driving it requires increasing it. still shouldn't cause this abysmal degradation

<kayabanerve:matrix.org> Vendoring Rust crates sounds fine to me, in a repository or under Monero. There's support for that in cargo and I've done it before. I think aggressively pruning unused libs with patch files may really drop the LoC to just the libs we actually use. For example, we have 150k lines of Rust's bindings to libc, and I don't believe [... too long, see mrelay.p2pool.observer/e/hZ6pxpsLNGZQRGc5 ]

<kayabanerve:matrix.org> This is an interruption, sorry. I got a ping like, an hour ago, and just wanted to leave the comment.

<ofrnxmr> simply running mnew address 1000 after changing the lookahead will show you the regression

<rucknium> So my own wallets aren't really affected, but I affect you who are trying to follow my wallets. If I understand right.

@rucknium: via wallet cli, correct, as it exists in fcmp++ beta branches/releases. Using other means (like my code that also includes subaddress growth) is efficient or doesn't show the same perf hit

and for context, it's a view-only wallet what I am restoring/tracking

<rucknium> My spamming wallets use monero-wallet-rpc, not monero-wallet-cli by the way.

<rucknium> I don't know if that matters at all for this issue

<rucknium> Anything more on this agenda item for now?

<jberman> Datahoarder can you create an issue for this one plz so we can keep track of it there

in seraphis fork?

<jberman> Yes please

👍️ > <@jberman> Yes please

<jberman> Ty

<jberman> Nothing more from me

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