<stormyyy:tchncs.de> meowwnero

<kevino:tchncs.de> If carrot++ backwards compatible ?

<kevino:tchncs.de> @jeffro256:monero.social

<kevino:tchncs.de> I mean if users can migrate to such wallet before fcmp++ upgrade goes live

<barthman132:matrix.org> @kevino:tchncs.de: Yes carrot is backwards compatible

<barthman132:matrix.org> x.com/monero/status/1834292929877180697

<ofrnxmr:xmr.mx> @barthman132:matrix.org: I think the question is more "can we create carrot wallets before the hard fork"

<kevino:tchncs.de> @ofrnxmr:xmr.mx: Yea exactly

<kevino:tchncs.de> Probably the new features won't work yet. But if someone wants to create a cold storage or hardware wallet, they could start using it if possible

speaking about Carrot let me try again.... github.com/hbs/MoneroMisc/blob/master/CARROT-discussion.md

<321bob321> Let me see your in and out of wallet your sending the xmr too

<kevino:tchncs.de> nioc: what is this, tldr ?

a suggestion for Carrot implementation that will arguably give better privacy

now read it lol

needs support for it to happen

<usermame0001:matrix.org> can anyone recommend a way to swap bnb to xmr thats not a scam, I tried looking online but like 80% of the comments are scammers

usermame001: swap BNB to LTC

then swap LTC to XMR

<usermame0001:matrix.org> yeah that seems like the way, propably with retoswap or traveno for no kyc or anything better ?Thanks for the reply!

<monero.arbo:matrix.org> I'm confused --- there seem to be plenty of options on trocador for going straight from BNB to XMR

Guess xmr is about to break $400

no price talk here pls

<usermame0001:matrix.org> @monero.arbo:matrix.org: True I just saw it, if the listed exchanges are good and actually dont kyc according to their rating on there that should be easy then

<jeffro256> You could, there's nothing technically stopping you, but you wouldn't be able to spend any XMR you receive in those addresses until the FCMP++ fork. > <@kevino:tchncs.de> I mean if users can migrate to such wallet before fcmp++ upgrade goes live

<kevino:tchncs.de> Ohh i see thanks

<kevino:tchncs.de> So its better usable after hard fork i guess

<jeffro256> In other words, the Carrot key derivation scheme is not backwards compatible with the current consensus protocol, but the Carrot addressing protocol is backwards compatible with current address derivation

<jeffro256> So there's no need to update to a Carrot keyed wallet, unless you want the features, but the Carrot keyed wallets won't be usable until FCMP++

<jeffro256> And as of yet (I'm the one writing it), the reference code is not going to support scanning/spending XMR in legacy outputs which was sent to a Carrot keyed wallet address. But perhaps if there is a widespread desire for people to front-load Carrot keyed wallets and start receiving XMR to them before the fork, then I could definitely write the code to support that

<kevino:tchncs.de> Won't be useful if we can only receve but not spend

<kevino:tchncs.de> Thanks for clarification 👍🏻

Hey everyone, binaries for the latest version v0.18.4.3 are now available at getmonero.org

Highly recommended release that enhances protection against spy nodes when using a local node. <<>> how?

nioc: I'm sure more info will be available soon

nioc: if you mean for GUI, the spy node protection is for using local monerod

I wasn't sure how to explain it that it does not protect you from connection to a malicous remote node

selsta: comment on the site did not mention GUI, does this pertain to CLI as well?

can you link to where you are reading this?

it's under the GUI release notes

and also CLI release notes

since both contain the new monerod version

clicked on (release notes) here > getmonero.org/downloads/#cli

I don't know, it looks correct on my side

was just curious what the improvement was :)

most spy nodes are on a similar IP address

ooooh

is it that PR that like

refuses to disconnect to a node if it's in a similar IP range

to another one

I currently use the blocklist

i think /16?

I don't know if refuses or deprioritizes

for /24 subnet

<rbrunner7> The new peer selection does not refuse to connect. It just selects new peers in a way that lowers the chance of a "spy node" to become the next new one considerably.

<rbrunner7> It does indeed rely on the fact that those spy nodes currently crowd into a quite small number of subnets.

rbrunner7 is what was included the pr you worked on?

<rbrunner7> Yes :)

<rbrunner7> First code from me into an update for quite a long time

<rbrunner7> Half of the credit goes to Rucknium who guided me

<rucknium> nioc , Sindy_ Here is the PR: monero-project/monero #9939 and the research that supports it: github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf

<ravfx:xmr.mx> What is that supercop thing? Required or no to build monerod?

supercop has assembly optimizations for ed25519 in it

i think

Only for x86_64 though

<privacyx> mrelay.p2pool.observer/m/monero.social/JykuXOBPGYAAyRZOsmSVhXAm.png (Screenshot 2025-10-10 083726.png)

<privacyx> Anyone notice this?

it's a bug

related to pool attribution

<privacyx> I thought that might be the case

<ofrnxmr> looks like zcash

I wonder why there is no monero listed on miningpoolstats kappa.lol/C8jDNP

I noticed it yesterday

hmmm

they probably noticed it and delisted monero temporarily

while they fix the crappy graph

<torir:matrix.org> Monero is currently 566 in the list of coins. Below Monero Classic, MoneroV, Grin, and Tari.

I can still access the monero page via bookmark and yes the graph is still messed up