<ravfx:xmr.mx> OVK, "something" View Keys?

<ravfx:xmr.mx> If so yes, so much fud about that

yes

everyone's going crazy over OVK

<jeffro256> @ravfx:xmr.mx: Yup

<jeffro256> It's crazy how a couple FUD posts spread so fast compared to months of steady educational information

years

Jamtis also had the same

<ravfx:xmr.mx> Even long time moneroers on my rooms went all on on that fud

<ravfx:xmr.mx> It propagate so easily lol

<ravfx:xmr.mx> I assume some ztrasher trying to bring monero lower because it hold ~previous ath

they can TODAY force the issue of such an addressing scheme btw

I don't even mean rings

but they can ask to use compliant wallets that implement that, if they so much wanted it

"We should not make it easy for them" cool then let's have OVK be something that you can only get via the cli wallet :P

then goalposts shift

you saw it yesterday, now it's "yeah we shouldn't have any viewkey"

so ... that forces you to move to no subaddresses

or wallets that get lost if you don't backup every move

<just_another_day:matrix.org> You all are assuming it's a fud and not a real concern for some reason

the concern is around regulators forcing it on people, and these don't care how it gets done

"that is your problem buddy now move to this wallet that implemented it regardless"

the "view" key allows decoding and decrypting an output details, then mapping it to a subaddress; the spend key allows generating key images and signing with these

<ravfx:xmr.mx> So the view key are required for subaddress operation?

the split is now made in that generate -> sign specifically to address computation of your spend key via quantum-capable opponents

yes

that is exactly how it works

<ravfx:xmr.mx> So it must stay there lol, just dont paste it on reddit

and why creating a million subaddresses doesn't slow down sync

01:39:32 <DataHoarder> the split is now made in that generate -> sign specifically to address computation of your spend key via quantum-capable opponents

^ and such the generate image key is made

<lza_menace> @sgp_:monero.social i was testing skylight and it doesn't seem like it can connect to an onion address - it will connect to clearnet over tor but not onion direct. can you confirm if this is correct or user error?

<lza_menace> i had an onion address entered and the wallet would not accept it

now even if an actor can attack that, they can't go backwards to your spend key that are unrelated to that

it is also just that sharing your view incoming key + generate image key allows for finding if outputs have been spent, but that's it

01:37:06 <br-m> <just_another_day:matrix.org> You all are assuming it's a fud and not a real concern for some reason

a couple of weeks ago it was spammers talking about quantum security and how monero had not done anything about it and wasn't planning to

Carrot with the partial hardening, plus addressing method to allow relatively seamless migration: exists

🕵️

specific feature that makes it work: yeah remove that (and now the quantum people are not talking)

the fud can be joined by others with well intentions and amplified, specially where this is not an "extra" feature bolted onto

<just_another_day:matrix.org> I see. I didn't even know about the quantum fud

<just_another_day:matrix.org> I haven't yet looked into the quantum migration plan

the concern is valid but it's specifically being blown out of proportions by first misunderstanding how it works or what it does, and second assumption that regulators will stop there

and also: that it not being implemented by X doesn't mean Y implements it (or a different scheme, like a wallet that auto-submits the proofs) and demands compliance

specially when all people talk is about "CEX and Merchants"

these could run their own custom stack, wallets, addressing schemes, or anything in between and you'd not even notice and doesn't need to be in monero-core

also Jamtis/Quantum addressing scheme monero-project/research-lab #151

Carrot (with descriptions for carrot-native and legacy) github.com/jeffro256/carrot/blob/master/carrot.md

current Post-Quantum Turnstile design for Carrot gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

<just_another_day:matrix.org> > <DataHoarder> and also: that it not being implemented by X doesn't mean Y implements it (or a different scheme, like a wallet that auto-submits the proofs) and demands compliance

<just_another_day:matrix.org> It's a valid point. Still, I believe the "political cost" of moving users to a complaint wallet is higher than requiring a single key that almost every wallet provides, only once per address. I'm glad that we at least have common ground in actually understanding what this FUD/concern is about

If it's about making it easier, make it a cli-only feature :')

or like for hw wallets, like you need to edit the source code to printf it out to console (or I had to) as the GUI displays all zero's as the view key even while it has it in memory

(and compile monero)

<just_another_day:matrix.org> Yeah, I think it's a good middle ground

<kiersten5821:matrix.org> in life ux is everything 🚬

<jeffro256> You could actually still have subaddresses. It's just that scanning for received coins would necessitate loading the private spend key, which would make HWs / cold wallets / multisig wallets effectively useless. It would also be super insecure for software wallets. > <DataHoarder> so ... that forces you to move to no subaddresses

<jeffro256> I'm not assuming it is FUD, I know that it is FUD based on cryptographic reality, and not baseless speculation about niche scenarios > <@just_another_day:matrix.org> You all are assuming it's a fud and not a real concern for some reason

yeah, that was brought up earlier, you'd also have to generate the wallet in a specific way

(off current topic) every time I see the quote reply on the irc bridge it makes me happy, it usually brings up the perfect amount of context on replies

<jeffro256> @just_another_day:matrix.org: Legacy wallets will not and cannot have OVKs in the sense that you are thinking of

OVKs will solve the issue with view-only wallets having inflated balances

without having to constantly export key images

<jeffro256> If you do nothing besides update your Monero software, you will not have scary OVKs forced upon you

^ and use monero software, not third party wallets or those "all in one" programs. who knows what they end up with even if they are good today

also jeffro256: you won't be able to use a PQ Turnstile in case it ever needs to be used, and you don't move beforehand to Jamtis or a system that can migrate

(plus, you also have your previous historical txs, made visible by quantum opponents, instead of Carrot which explicitly does further to combat this, specially if you are sweeping to yourself!)

<kiersten5821:matrix.org> Cindy: so this will make the airgap sign process easier right?

for legacy it's 2.1.1 conditional

yes

<kiersten5821:matrix.org> in the past it required like 3 back and forths or something it was terrible

<just_another_day:matrix.org> @jeffro256: Legacy wallets are called legacy for a reason. I believe Monero popularity will grow significantly in the following years. New users will obviously get carrot addresses. Then the legacy wallet owners risk to become the non-compliant marginalized minority, similar to Bitcoin mixer users

also FCMP++ changes this @kiersten5821:matrix.org as members can sign but the chain proof and other things can be built later

it eases this specially in offline conditions

<jeffro256> @just_another_day:matrix.org: This is already possible without OVKs. Its just a matter of amount of data sent and number of rounds of communication required.

hey guys. How can I get some stagenet monero?

Then the legacy wallet owners risk to become the non-quantum-safe marginalized minority > Then the legacy wallet owners risk to become the non-compliant marginalized minority

<jeffro256> Solution: don't be a surveillance cuck and give all your info

vamos881: cypherfaucet.com/xmr-stagenet

<jeffro256> @kiersten5821:matrix.org: Yep. You will only have to consult the cold device when you want to send XMR

or ask Cindy for some

<just_another_day:matrix.org> > <@jeffro256> I'm not assuming it is FUD, I know that it is FUD based on cryptographic reality, and not baseless speculation about niche scenarios

<just_another_day:matrix.org> This is not about cryptography at all. And I wouldn't dismiss regulatory pressure as a niche scenario. You might love the cryptography in Monero, and that's a good thing, but Monero really is a liberation tool that uses cryptography as an instrument. We shouldn't forget about the goal of the project

vamos881: stagenet-faucet.xmr-tw.org

but the generate image kei is there due to cryptography

oh looks like they put english translation now

so it IS about cryptography

i remember it being entirely chinese

but yeah, put your address there, click send, it'll give you 1 XMR

<kiersten5821:matrix.org> vamos881: if you are developing, it is easier to run a purely local chain, then you can send yourself infinite coins

you could just mine on stagenet

it is pretty doable to solomine

because it doesn't have that much global hashrate

<ravfx:xmr.mx> A few years ago I ran my 3950x for like an hours and got so many coins

<ravfx:xmr.mx> Can give then back eventually, just have to restore old seed

on stagenet?

DataHoarder, Cindy: thank you man

<ravfx:xmr.mx> Yes.

<torir:matrix.org> @yokoama:matrix.org: Which is stupid considering how traceable many MWEB transactions are. mwebexplorer.com will tell you want block an MWEB output was created in, and the volume is low enough that sometimes both peg-in and peg-out are the only MWEB transactions in a block and you can perfectly deanonymize it.

br-m: I'm not developing yet. Is what you're describing similar to bitcoin's regtest?

vamos881: it's hosting a private blockchain

ok, then it's the same apparently

basically one you create yourself, so you can mess around with it

<kiersten5821:matrix.org> ./monerod --regtest --offline --fixed-difficulty 1

<kiersten5821:matrix.org> use that

<kiersten5821:matrix.org> and rpc generateblocks command

<jeffro256> @just_another_day:matrix.org: It is about cryptography because people don't understand that this is already possible. They hear the new "outgoing view key" term and assume that this enables a novel form of tracing. It doesn't.

is there a good reference to learn how monero actually works? I have read Mastering Monero, it's very superficial (mastering bitcoin goes a lot deeper, for example). I know there's Zero to monero, but that's very specific to the cryptography

<jeffro256> I'm not dismissing the concern itself, but it has bad presumptions built into it.

<jeffro256> Zero to Monero is excellent. Cryptography is a lot of how Monero works, what else are you looking for specifically?

<ravfx:xmr.mx> People think exchanges will just ask everyone viewkeys or something and that will lower other privacy (it wont, even if people where dumb enough to all comply)

br-m: transaction structure, for example. What goes in a transaction? I know there isn't a script language, for instance. Blocks too

Zero to Monero btw (will need an update after FCMP++/Carrot) getmonero.org/library/Zero-to-Monero-2-0-0.pdf

<jeffro256> vamos881: Are you opposed to reading code?

<jeffro256> vamos881: The Cuprate Monero book is a great resource for specific implementation details: monero-book.cuprate.org

vamos881: monero-oxide / Cuprate in Rust reimplemented decoding transactions, I also did so in my own go code

br-m: to learn how things work? Yea

thanks, this looks like a good one :)

github.com/monero-oxide/monero-oxid…ain/monero-oxide/src/transaction.rs / git.gammaspectra.live/P2Pool/consen…rc/branch/master/monero/transaction

<just_another_day:matrix.org> > <@jeffro256> It is about cryptography because people don't understand that this is already possible. They hear the new "outgoing view key" term and assume that this enables a novel form of tracing. It doesn't.

<just_another_day:matrix.org> We don't currently have keys that allow tracking both incoming and outgoing transactions indefinitely. If you're referring to statistical heuristics that allow to leak more info than intended, given an incoming view key - then it's obviously a vulnerability that should be patched (and the new upgrade indeed patches it). A vulnerability can't justify making its impact a feature.

<just_another_day:matrix.org> And a big part of this discussion is about not the technical possibility of disclosing your existing history, but availability of such an instrument to most of users. Cryptography doesn't make this distinction, but the distinction matters for real world consequences

excuse the n00b question: what is jeffro256?

or alternatively: you stay on an addressing scheme that can be backwards dug through via quantum computers

vamos881: br-m is a bridge, jeffro256 is on Matrix

oh ok, I thought br-m was the person. Duh!

you see it prefixes the user on matrix

<jeffro256> vamos881: Oh my gosh what am I

yes, I thought br-m was talking to jeffro256, but then I saw it was meant to me lol. Sorry jeffro256

mrelay.p2pool.observer/m/monero.social/tlimTmkdsBmZhGbPpcQSALeg.png (image.png)

That how it looks on the other side

DataHoarder: what is your go code? Go is easier than rust for me

I sent it as well

it's what I use for go-p2pool, p2pool.observer and my block explorer on blocks.p2pool.observer

the git.gammaspectra is giving me http 403 for some reason.

nice, will check

<jeffro256> @just_another_day:matrix.org: Right now your tx history is extremely available if I assume that you're going to give it to me willingly. I can even write you a nice, neat wallet software which sends it to me automatically, cryptographically verifiable, and 0 user friction is required. I could even have it send me spend key [... too long, see mrelay.p2pool.observer/e/jrrp4t8KZzZ2bEtv ]

403? might be blocked due to coming from a range abused by AI scrapers

you can just $ git clone git.gammaspectra.live/P2Pool/consensus.git

<jeffro256> lol no worries > <vamos881> yes, I thought br-m was talking to jeffro256, but then I saw it was meant to me lol. Sorry jeffro256

and that will work

not really, it's the same host. I'll try vpn later

"fatal: unable to access 'git.gammaspectra.live/P2Pool/consensus.git/': The requested URL returned error: 403"

<jeffro256> If we assume that the evil tyrannical government is all powerful, then Monero is pointless. To get the best decentralization+privacy results, we have to make some real-word assumptions like "we can't maintain privacy with cryptography if the user chooses to leak every single detail to someone they're trying to keep the informa [... too long, see mrelay.p2pool.observer/e/v_T14t8KQmNRLXhR ]

yeah vamos881 it is Zenlayer

that's where I get a couple TiB of abuse so that was explicitly dropped

<just_another_day:matrix.org> @jeffro256: I'm not the one assuming an all powerful government. Quite the opposite, I know that direct government oppression scales poorly, and governments heavily rely on people willingly comply with their demands. For example, many people choose to do KYC on centralized exchanges for the solely reason of convenience of [... too long, see mrelay.p2pool.observer/e/t8TZ498KZ01uSVQ3 ]

<just_another_day:matrix.org> As for Monero, there is a very plausible scenario when you have to leak your OVK to get access to most merchants, because otherwise the merchants would have to deal with annoying agencies forcing AML policies on them. If we assume most casual users would leak it, then merchants have little incentive not to comply with the AML [... too long, see mrelay.p2pool.observer/e/t8TZ498KZ01uSVQ3 ]

<jeffro256> @just_another_day:matrix.org: By "niche scenario" I wasn't referring to increased regulatory pressure and/or increased KYC requirements; I understand that this is the current norm. I was referring to the niche scenario where governments / financial institutions require you prove XMR transaction history for KYC but only a [... too long, see mrelay.p2pool.observer/e/4oTa498KbXQ5Q0x1 ]

<jeffro256> @just_another_day:matrix.org: I agree about making DEXs easier, which is one reason why I like OVKs: they make multisig UX way way better. I can, and will, blame users who willingly provide tracing information, and then complain about the consequences of their actions.

<jeffro256> > As for Monero, there is a very plausible scenario when you have to leak your OVK to get access to most merchants, because otherwise the merchants would have to deal with annoying agencies forcing AML policies on them.

<jeffro256> I don't think it's getting through that THIS IS CURRENTLY POSSIBLE WITHOUT OVKs. YOU CAN DO THIS WITHOUT OVKs. YOU CAN LEAK YOUR TRANSACTION HISTORY AT YOUR OWN DISCRETION. THIS CAN BE AUTOMATED. THIS CAN BE CRYPTOGRAPHICALLY VERIFIABLE. MERCHANTS COULD REQUIRE IT TODAY. YOUR PRIVACY IS OPTIONAL. FULL STOP.

<just_another_day:matrix.org> There is no such tool in most wallets

<jeffro256> What's stopping this from happening ? A) no one has coded it yet, B) people choose not to do silly things

<jeffro256> @just_another_day:matrix.org: There is in the CLI and GUI wallet

<just_another_day:matrix.org> Yes, but I didn't find it in Cake

how big is the stagenet blockchain? I already had a pruned mainnet node, started syncing stagenet: Synced 254841/2041748 (12%, 1786907 left, 6% of total synced, estimated 11.7 hours left)]]

<jeffro256> Okay I'm big bag government: I say that you can't use Cake b/c no tx proofs. You roll over and comply. That's it

<jeffro256> Wrap it up, the permisionless blockchain is dead

<jeffro256> "Mandatory privacy" doesn't exist, it never has, and cannot exist while humans still retain free will.

<just_another_day:matrix.org> > <@just_another_day:matrix.org> It's a valid point. Still, I believe the "political cost" of moving users to a complaint wallet is higher than requiring a single key that almost every wallet provides, only once per address. I'm glad that we at least have common ground in actually understanding what this FUD/concern is about

<just_another_day:matrix.org> > Still, I believe the "political cost" of moving users to a complaint wallet is higher than requiring a single key that almost every wallet provides, only once per address

<just_another_day:matrix.org> Also, consider the scenario when only 10% of merchants require OVK vs 10% of merchants require key images

<kiersten5821:matrix.org> vamos881: use the command i told you earlier and it will not need to sync

<kiersten5821:matrix.org> it will start from block 0

<kiersten5821:matrix.org> and be entirely local

<just_another_day:matrix.org> It's sufficient for surveillance that user provides OVK only once, while they need a continuous stream of key images

<just_another_day:matrix.org> When a user needs to install another wallet to get access to a merchant from that 10%, he/she will just choose another merchant. So the 10% of merchants quickly loose all of their clients. As a consequence, this thing doesn't get normalized

<tuw:matrix.org> Sorry for constantly getting FUDed.. if the scenario described by thankful (whereby merchants mostly require OVK) comes to pass, and say 50% of moneros OVKs are exposed, could that potentially compromise the privacy of the non exposed wallets? The worry is just that this will be used as a potential attack vector in the future.

<jeffro256> @just_another_day:matrix.org: What is the practical difference if you are someone who complies with such requests? If you have a change of heart, it is visible to the key holder that you stopped complying

<jeffro256> So you will still be on the hook for providing that information

<just_another_day:matrix.org> @just_another_day:matrix.org: When every wallet has this option, then the complying 10% lose much less users because of that. So their portion will grow

<jeffro256> @tuw:matrix.org: If you don't comply, then your transactions are just as private as if the Monero usage was restricted to that 50% of people that didn't comply. With FCMP++, this still means perfect spend privacy within that 50% pool

^ and even further if you self-send in carrot, even against quantum opponents

<tuw:matrix.org> understood thanks.

<just_another_day:matrix.org> @jeffro256: The merchants are on hook because there are less of them than users. Users don't face consequences in my scenario, they just choose merchants and comply/not comply with their AML policy

kiersten5821:matrix.org: but that is regtest. I want to send coins from monero-wallet-gui to cake etc

exactly just_another_day:matrix.org so it's super easy to have merchants comply using a custom solution as jeffro256 also says

I missed your early message too, I was still confused about br-m being a person

<just_another_day:matrix.org> DataHoarder: maybe... but we're considering clients leaking their OVK in this scenario. A merchant can't get a client to leak OVK by a special custom solution

<just_another_day:matrix.org> > <@jeffro256> By "niche scenario" I wasn't referring to increased regulatory pressure and/or increased KYC requirements; I understand that this is the current norm. I was referring to the niche scenario where governments / financial institutions require you prove XMR transaction history for KYC but only after we implement OVKs, and they magically don't care about it before that point.

<just_another_day:matrix.org> Maybe they will require it even without OVKs. The pressure is yet to come. My point was that we shouldn't accommodate them by implementing the exact thing they would ideally want.

is it what they ideally want? are you sure that it isn't something else?

like ... destroying the ability to properly hide this on the face of a quantum opponent, or any migration whatsoever

(besides the usability a generate image key brings for safe usage of monero)

and FYI jeffro256 is who is driving Carrot specification and implementation (to put context to these words > <jeffro256> I'm not assuming it is FUD, I know that it is FUD based on cryptographic reality, and not baseless speculation about niche scenarios )

<kayabanerve:matrix.org> I think we should get rid of not just OVKs, yet IVKs and even spend keys.

<kayabanerve:matrix.org> No one should be able to see how much you have: not even you.

spending is harmful too

<kayabanerve:matrix.org> All currency exchange should occur solely offline, with no ability for any computer to view any records.

<kayabanerve:matrix.org> /s if it wasn't obvious

<kayabanerve:matrix.org> We have OVKs today though. They're just interactive via disclosing key images or the private spend key.

this was brought up already yep, but, goal shifting to -> that is harder than doing one off

it doesn't matter what you do in the view of regulators they will go as far as they need to obtain X

even spend keys

then goal shifting to -> what if I claim wallet was lost so can't do that

then again, regulators will assume you are non-complying

<kayabanerve:matrix.org> In order to interact with me, I require your OVK. I promise to you that even though it also allows spending your coins, I will treat it securely with military-grade security.

<kayabanerve:matrix.org> Please send it in a DM with your name, address, social security number, government ID, and also mail in $10,000 and the deeds to any property you own.

<kayabanerve:matrix.org> Thank you.

<kayabanerve:matrix.org> Mhm

a note kayabanerve these will probably be used by the impostor ^ to copy paste elsewhere

<kayabanerve:matrix.org> If you have the ability to choose not to interact, and you don't want to interact, don't. It's that simple.

and context is lost

they did that during the qubic ordeal

off topic update: Cat is currently laying across 2 mining rigs

and tell people to "search for the message" so they see you posted it, without the /s context

<kayabanerve:matrix.org> If you don't want to hand your private spend key, don't. If you don't want to hand over your outgoing view key, don't.

<kayabanerve:matrix.org> Yes, I tried to make them each obviously absurd but I understand anyone can misrepresent me online, including by faking messages outright.

<kayabanerve:matrix.org> The issue currently is people do want to disclose their outgoing view key to select parties but cannot without making the private spend key hot.

<kayabanerve:matrix.org> Not that they can't disclose their outgoing view key at all.

<just_another_day:matrix.org> @kayabanerve:matrix.org: This logic can be applied to optional privacy chains. Don't want your ETH be traced? Use Tornado Cash!

<just_another_day:matrix.org> In real world, you can use Tornado Cash, but it'll quickly make your ETH unspendable at legitimate places

remember a single self-spend using new carrot wallet breaks this link

(under FCMP++)

<just_another_day:matrix.org> And creating a new wallet is literally optional privacy

you have extended this too further, I think

<just_another_day:matrix.org> I mean, under widespread OVK sharing, wallets will be split into transparent and non-transparent. The latter will essentially form a big "shielded pool". Moving coins into a shielded pool, unfortunately, doesn't help with AML

<just_another_day:matrix.org> Of course, widespread OVK sharing is not guaranteed, but I believe there is a high risk of it happening

<ravfx:xmr.mx> Just don't share the keys

<ravfx:xmr.mx> mkay?

you already share full credit card details when shopping :) so spend keys it is

<just_another_day:matrix.org> @ravfx:xmr.mx: I responded to this idea just a few messages above

<just_another_day:matrix.org> I'm just explaining the concern btw; a solution is the next step

<kayabanerve:matrix.org> @just_another_day:matrix.org: Services don't have to accept Ether from sanctioned services and don't have to accept Monero. Monero was already delisted from Binance. That's more a fact of life than anything relevant to this discussion IMO.

<just_another_day:matrix.org> I like this as a middle ground > <DataHoarder> If it's about making it easier, make it a cli-only feature :')

what solution? sending monero back to quantum unsafe/non migration protocol?

<just_another_day:matrix.org> Keeping OVKs as a cli-only feature for power users

<just_another_day:matrix.org> @kayabanerve:matrix.org: In fact, I'd better have Monero still delisted from Binance. I just don't want merchants who'll start accept Monero to implement AML policies. They should either ignore Monero and lose all the Monero clients or get the clients but pay the price of not implementing AML

<preland> I personally believe that the best solution is to add in the default wallet (and strongly enforce other implementations to do so) a very easy way to create and manage "intermediary" wallets, and that whenever a user attempts to access the view key of their main wallet, it should give a rather poignant warning that the main wa [... too long, see mrelay.p2pool.observer/e/vc3q5d8KUjZRcXQ4 ]

<preland> I believe that the mere ability for users to easily do this should discourage widespread view key requirements, and in the case that it does become commonplace, the amount of information leaked can be plausibly minimized.

<preland> (Sry for the delay on writing that; my internet currently sucks lol)

<just_another_day:matrix.org> The fud is really because people don't want optional transparency in Monero. The fact they some of them didn't realize we already have some optional transparency is just a sign that it better be kept hidden if we can't get rid of it completely. Cash doesn't have view keys :)

<just_another_day:matrix.org> But I believe many realize it; there are good comments under the posts that express similar ideas to mine

<preland> @just_another_day:matrix.org: My belief is that transparency should be granular and minimized to the exact information desired to be given. If a CEX just wants to determine your wallet’s behavior during the past, that shouldn’t require you to leak your behavior et infinitum.

<preland> I think that the era when Monero had better functioning view keys was also from a time when many things were still in flux with the currency. As with other appeals to history, I will never agree with anyone that says that view keys must be added back just because it was previously done.

<preland> If you have other arguments, present those. Monero’s entire development history has been correcting errors made previously, and we shouldn’t start “Satoshi-ing” the past now.

<continuechoose:matrix.org> I see no issue with view keys. If an oppressive government is your threat model, internet access might be cut off entirely (as seen in Iran), or they could simply block Monero nodes and Tor. Because infrastructure is almost always state-controlled, decentralization has inherent limits

<preland> @continuechoose:matrix.org: > because infrastructure is almost always state-controlled

<preland> I believe that in the next 50 years, save there be some sort of black swan event that results in widespread authoritarianism, internet infrastructure and access will be significantly less centralized than it is currently.

<preland> I may not personally agree with removing view keys outright,  but I can definitely see the rational issues with them.

<continuechoose:matrix.org> Apologies, but that is not feasible. It is impossible to decentralize the submarine cables that connect countries

<kiersten5821:matrix.org> vamos881: just connect them all to your daemon

<kiersten5821:matrix.org> it will work

<kiersten5821:matrix.org> connect cake to your offline daemon

<sgp_> Forced hodl > <DataHoarder> spending is harmful too

<sgp_> @lza_menace: I'm personally connected to my onion LWS directly. Can you please join #skylight-wallet:monero.social so we can diagnose the issue?

<sgp_> "remove view keys to increase privacy" only makes sense if you think about it for one second but don't think any harder. A third party can't conjure your view key from thin air without your consent. You can use additional wallets. They could ask for your spend key (or your SSN, photo ID, blood sample, whatever). The downsides [... too long, see mrelay.p2pool.observer/e/s8jd5t8KNTVubDJK ]

<sgp_> If you're envisioning a world where no one can use Monero without handing over a view key (and somehow that's actually enforc d with every potential counterparty refusing to transact with you), it's essentially the same assumption as all Monero activity being banned to strong effect. In that case, Monero already "lost"

<sgp_> Conversely, the downsides to removing view keys are severe and immediately obvious. MAGIC Grants uses BTC Pay Server to accept Monero donations and give donation receipts. That uses a view only key right now. Would you rather tell companies they need to put a private spend key on the server just to check incoming transactions, and increase the risk of funds being stolen? Terrible idea

<kiersten5821:matrix.org> has anyone managed to crack one of those bitmain miners to get it to run linux instead of just mining

<kiersten5821:matrix.org> i want a risc v computer with a gazillion threads

<321bob321> For Minecraft ?

<kayabanerve:matrix.org> @sgp_:monero.social: You're only being asked for a blood sample? Who's your provider, I have to switch

<sgp_> Sorry for being blunt, but the idea of removing view keys for "safety" is just..... ugh

<kayabanerve:matrix.org> (O)VKs improve safety by allowing functionality without hot spend keys, yep.

<jeffro256> > <@just_another_day:matrix.org> This logic can be applied to optional privacy chains. Don't want your ETH be traced? Use Tornado Cash!

<jeffro256> These "legitimate" places can "require" you to do anything, including, but not limited to, requiring video scans of your face, proof of address, fingerprints, address them as "my liege", etc. Since most cryptocurrency transactions are irreversible, It's your job to not interact with people who will shotgun KYC you if you don't [... too long, see mrelay.p2pool.observer/e/kZrb598KclRzZ2l3 ]

<kiersten5821:matrix.org> Ok but you know all xmr is the same "taint" as tornado cash eth right > <@just_another_day:matrix.org> This logic can be applied to optional privacy chains. Don't want your ETH be traced? Use Tornado Cash!

<kiersten5821:matrix.org> I dont understand why people are like "coinjoin will taint your bitcoins" "Tornado Cash bad its marked" "monero has no taint" no all moneros are tainted lol

<jeffro256> @just_another_day:matrix.org: I don't want to hide any information from the public, because I'm willing to bet that the bad guys are aware of the technical ability for Monero's optional transparency. It will literally only hurt us if we try to stick our heads in the sand and/or die on the wrong hills.

<preland> Iirc they can’t be because they were built in such a way that they can’t > <@kiersten5821:matrix.org> has anyone managed to crack one of those bitmain miners to get it to run linux instead of just mining

<preland> Which I personally doubt, but considering that these things were likely prototypes sold at a loss…….wouldn’t be all that surprising (if they weren’t modified, why wouldn’t they just sell the chips raw for more money?)

<jeffro256> > <@preland> I personally believe that the best solution is to add in the default wallet (and strongly enforce other implementations to do so) a very easy way to create and manage "intermediary" wallets, and that whenever a user attempts to access the view key of their main wallet, it should give a rather poignant warning [... too long, see mrelay.p2pool.observer/e/mLzx598KZ1lPeDZX ]

<jeffro256> I think that AML risk scorers would see through this immediately. "Oh yeah, you just started using Monero 30 minutes ago and acquired the exact amount you want to use for this action? Get screwed, bud". It would be stupidly easy to flag this intermediate wallet. The next logical step would be for them to ask you to prove who sent you this XMR.

<preland> @jeffro256: I’m just throwing ideas at the wall; tbh I’m afraid that if something doesn’t change that we will see a stronger hard fork than with previous changes for no reason other than the view keys.

<preland> I don’t want that to happen.

<preland> Or alternatively, that if we are hell bent on view keys, that the opposition will discover an actual valid issue, which will be swept under the rug, and then be abused by threat actors.

<preland> I also don’t want that to happen.

<kiersten5821:matrix.org> @preland: how so? isn't it just ddr4 + risc v chips? did someone actually try analyzing this? or was no one willing to spend time on it (understandable)

<jeffro256> @preland: I want to point out for the upteenth time that FCMP++ doesn't require that wallets have OVKs, it only enables it for new key material at a consensus level. You can have a legacy wallet that uses FCMP++, but it mathematically cannot have an OVK in the sense that there is static key material that allows outgoing tx [... too long, see mrelay.p2pool.observer/e/m5WE6N8KNzdJTGNs ]

<kiersten5821:matrix.org> mrelay.p2pool.observer/m/matrix.org/oLnpQsvMZlTgDZBIjqGbCVFY.png (image.png)

<kiersten5821:matrix.org> imagine running a server on this

<jeffro256> @preland: This is true for every crypto update. We try to mitigate with audits, and so far it has worked, but yes that is a risk

<kiersten5821:matrix.org> only 2.5 kw

<preland> @jeffro256: Can an external party tell if an address is legacy or not; if they can, the same concern with view key requirements stands

<jeffro256> no

<jeffro256> At least, not without further interaction from the address holder. The address holder CAN prove that the address spend pubkey is univariate or bivariate, which proves whether a OVK is possible, but with just the address, no.

<kayabanerve:matrix.org> @kiersten5821:matrix.org: XMR isn't sanctioned by the US government, so from a legal standpoint, it isn't the same as Tornado Cash (I am not a lawyer and this isn't legal advice).

<kayabanerve:matrix.org> @jeffro256:monero.social: It can have an OVK: the private spend key ;p

<kayabanerve:matrix.org> Something something all are bivariate, idiots just kept setting the second variable to zero... until now 😎

<kayabanerve:matrix.org> (we also only currently allowing spending keys where the second variable is zero currently, my point was to highlight the definition as this is actually the premise of the amazing backwards compatibility offered by FCMP++)

<jeffro256> @kayabanerve:matrix.org: Truuuu

<kiersten5821:matrix.org> tornado was unsanctioned after lawsuits, however it is still considered "tainted" by these pseudoscience orgs despite no legal issues with using it (RIP to the founders though) > <@kayabanerve:matrix.org> @kiersten5821:matrix.org: XMR isn't sanctioned by the US government, so from a legal standpoint, it isn't the same as Tornado Cash (I am not a lawyer and this isn't legal advice).

<jeffro256> I hereby sanction kayabanerve specifically > <@kayabanerve:matrix.org> @kiersten5821:matrix.org: XMR isn't sanctioned by the US government, so from a legal standpoint, it isn't the same as Tornado Cash (I am not a lawyer and this isn't legal advice).

<jeffro256> @kiersten5821:matrix.org: So fucked up. Storm doesn't deserve prison time for writing code. But to your point: you can still use Tornado Cash if you spend your ETH at regular merchants or send it to DEXes which don't KYC

<kiersten5821:matrix.org> yep, unfortunately most regular merchants will use some simple and very easy centralized solution like coinbase commerce instead of self host, and i'm sure they wouldn't let you send tornado eth straight to them lol

<kayabanerve:matrix.org> I believe lawsuits gained ground on the sanctioning not being proper. I'm unsure OFAC actually unsanctioned it, even if some obligation for them to was created.

also - generate image keys only allow you to check which outputs have been spent

You can find if a wallet was involved in a transaction with just its view incoming key

Which is available already and later on

<kiersten5821:matrix.org> @kayabanerve:matrix.org: coindesk.com/policy/2025/04/29/torn…-sanctioned-again-texas-judge-rules

<kiersten5821:matrix.org> > The Treasury Department’s Office of Foreign Asset Control (OFAC) removed Tornado Cash from its sanctions list in March, several months after an appeals court ruled that the agency had “overstepped its Congressionally-defined authority” by sanctioning the crypto mixing service’s smart contracts back in 2022.

Change outputs, after all, are incoming transfers

0 XMR change outputs also exist (you can see these in my block explorer when sweeps get sent out)

You may not be able to tell exactly which output was spent but guesses can be had, but you are certain they were part of the transaction (incoming or outgoing)

For example, one input, two outputs blocks.p2pool.observer/tx/2ddfc5aa9…e42429f241a00a8ef64d6a8dfa722a15e7f

One of which is known and is 0 XMR. An observer with receive only view keys (the only type available in legacy wallets) can as such deduct this must be a sweep, and the new output is being sent externally (with fee deducted from it)

<jeffro256> @kiersten5821:matrix.org: Is the ETH ecosystem really that bad ? Most people I see for multi-crypto payments use something like BTCPay or NOWPayments

The "uncertain" part is due to a random account/subaddress offset being selected here as the 0 XMR change target

<kiersten5821:matrix.org> @jeffro256: mrelay.p2pool.observer/m/matrix.org/MSDmnogBVudkdxPjVmonkYrV.png (image.png)

<kiersten5821:matrix.org> btcpay is only used by cool crypto guys, most merchants selling stuff not closely related to crypto will use a centralized provider which will do this

<pyratevevo:matrix.org> @just_another_day:matrix.org: Hello, this is big government. Please provide your Monero seed phrase for compliance..

<pyratevevo:matrix.org> @just_another_day:matrix.org : remove seed phrases !!

<munching:unredacted.org> hello i woman. someone send me 0,4 xmr thanks. i woman

<munching:unredacted.org> shopping shopping shopping

<munching:unredacted.org> (i actually wouldn’t mind if someone sent me that since i don’t have anything in my balance😔)

moberator?

<basses:matrix.org> doesnt even accept xmr as a payment > <@kiersten5821:matrix.org> mrelay.p2pool.observer/m/matrix.org/oLnpQsvMZlTgDZBIjqGbCVFY.png (image.png)

<munching:unredacted.org> BlueyHealer: it’s a joke

<jeffro256> @kiersten5821:matrix.org: ewww. TIL

<lza_menace> if anyone wants to tinker with a personal LWS i made a lil docker compose deployment. put it on your computer and get an onion address that you can connect to remotely: github.com/lalanza808/lwsadmin

🇨🇿 Czech President signed a law removing capital gains tax on Bitcoin after 3+ years of HODLing

what about Monero XMR?

xmr_guyy: EU 2027

hodling where... in a centralized exchange, in a cold wallet or hardwallet?

in a hot wallet such as cake wallet...

<elongated:matrix.org> xmr_guyy: Doesnt exist

yes

centralized exchanges for monero don't exist anymore in EU

they rolled out new regulation, and they're about to enforce it in 2027

The Czech Republic's President Petr Pavel signed a law in February 2025 exempting capital gains tax on Bitcoin and other crypto assets held for over three years. Small transactions (up to ~$4,100/year) are also unreportable. It aims to boost long-term investment and complies with EU rules.

bitcoin and other crypto assets only

thanks a bunch, cindy

they did it to cover their asses

because they received a massive donation (in bitcoin) from some former darknet market owner

disgusting corrupt politicians

"Justice Minister Pavel Blažek, a member of the Civic Democratic Party, resigned on 31 May 2025. Blažek stated that he had approved the donation without verifying its origin but denied that his actions were illegal.[8] The donation was not returned"

hey, at least he got away with it

A law made to benefit these corrupt politicians and mag

mafia politicians

a big coincidence that all this happened in may, and that law exempting capital gains tax on Bitcoin happened in february

if you ask me, he definitely knew the donation was coming, and pushed this as fast as he could so he wouldn't pay any taxes on his little gift

<yokoama:matrix.org> we love paying tax so much

<cranial_luminance:matrix.org> is there any added benefit from sending XMR to multiple different addresses in the same wallet before sending it to its final destination? what about different accounts within the same wallet or sending to multiple entirely different wallets? how would these scenarios look on the blockchain to an adversary? and how do view key [... too long, see mrelay.p2pool.observer/e/zrrY-N8KQ0YyYUlO ]

<yokoama:matrix.org> @cranial_luminance:matrix.org: who are you trying to hide from ? have you received xmr from a threat actor or cex ?

<cranial_luminance:matrix.org> @yokoama:matrix.org: lets assume the government and assume i got it from a CEX

multiple different addresses as in subaddresses?

or just different addresses in accounts

<ofrnxmr:xmr.mx> > is there any added benefit from sending XMR to multiple different addresses in the same wallet before sending it to its final destination?

<ofrnxmr:xmr.mx> No

<ofrnxmr:xmr.mx> > what about different accounts within the same wallet or sending to multiple entirely different wallets?[... more lines follow, see mrelay.p2pool.observer/e/-Y3s-N8KYkNoVTF5 ]

<cranial_luminance:matrix.org> Cindy: Cindy: both

<yokoama:matrix.org> shuffle each output, churn them, never merge them in a single tx

<cranial_luminance:matrix.org> @yokoama:matrix.org: pardon my lack of knowledge, what do you mean by shuffle and churn outputs exactly? is that the same as "i have 3 XMR i want to spend. i will send 1 XMR to address A, 1 XMR to address B and 1 XMR to address C and then finally send all 3 to the same final destination in 3 different transactions?

<cranial_luminance:matrix.org> @ofrnxmr:xmr.mx: thanks. so what do you mean by 'avoids mixing funds'? is that good for privacy? also, can you be more specific about "doesnt. Can see all accounts and addresses"?

<elongated:matrix.org> @cranial_luminance:matrix.org: Coin control

<ofrnxmr:xmr.mx> @elongated:matrix.org: No, i mean usong subaccounts avpid mixing funds since spending from account (1) wont select outputs from account (2)

<ofrnxmr:xmr.mx> its "like" having multiple wallets

hey folks. I keep getting this message on monerod stagenet: "No incoming connections - check firewalls/routers allow port 38080". But my ~/.bitmonero/bitmonero.conf has proxy=127.0.0.1:9050. Maybe only monerod mainnet is reading that conf file?

do I need to specify on .conf which network I want those settings applied to?

<ofrnxmr:xmr.mx> vamos881: You cant have incoming connections while routing to tor

<ofrnxmr:xmr.mx> vamos881: No, but that file might need to be read from the .bitmonero/stagenet folder (not sure)

ofrnxmr:xmr.mx: oh, really? I'm more experienced with bitcoin core, there tor allows incoming peers tooo

<ofrnxmr:xmr.mx> .. when in doubt, just use --config-file=~/.bitmonero/bitmonero.conf

<ofrnxmr:xmr.mx> vamos881: Cuz it uses onipn services for p2p

ofrnxmr:xmr.mx: ok, it seems it has to be a different file by default per monerod --help. I also don't see any ban list info from the stagenet log (and I have a ban list)

<ofrnxmr:xmr.mx> what does "i have a ban list" mean

ban-list arg

<ofrnxmr:xmr.mx> And its not loading it?

ofrnxmr:xmr.mx: nothing was loaded, I needed a separate conf under stagenet dir. Now it's ok

<ofrnxmr:xmr.mx> I'll still forever use --config-file

<just_another_day:matrix.org> The idea that this upgrade doesn't change anything is misleading. The key difference is that with current optional transparency, continuous user input and/or specialized software is required in order to keep a wallet transparent, while with OVKs a single action at a single point in time is sufficient

<just_another_day:matrix.org> The key difference between Monero and, say, ZCash is that Monero doesn't allow making a wallet transparent without weird hacks, while ZCash does. OVKs will change this

<just_another_day:matrix.org> Sorry, I had to go to sleep yesterday. I'd like to add this to our discussion

current view outgoing keys already disclose spends

they just don't list the amount

<just_another_day:matrix.org> how?

<ofrnxmr:xmr.mx> You get change when you spend

because they know when change goes back to wallet, even when it's 0

example blocks.p2pool.observer/tx/3341b52d3…9478927a61d0921de7156dad81230e9269f

<just_another_day:matrix.org> it's a vulnerability

<just_another_day:matrix.org> that will be fixed

?

<ofrnxmr:xmr.mx> @just_another_day:matrix.org: ?

<ofrnxmr:xmr.mx> Jinx

no FCMP++/Carrot do not change this

<just_another_day:matrix.org> a vulnerability can't justify making it impact a feature

it's not about rings.

remember it's also not a new *view key* mode, the view key doesn't change meaning. it's still view incoming key. A different extra key is made for generating key images, which allows, between others, securing the wallet against quantum capable adversaries in the long term

<just_another_day:matrix.org> > But unlike old Monero view-only wallets, a Carrot payment validator wallet cannot see "internal" change enotes.

without this, they can go back and make it transparent in the future

<ofrnxmr:xmr.mx> @just_another_day:matrix.org: Thats for a churn

<ofrnxmr:xmr.mx> Iiuc

yeah, internal sends are churns or change

nioc: and that diagram doesn't include the need for the split to cover quantum adversaries

as said, it could be something made CLI-only, that is not up to me, just a wild suggestion

but any entity could make a compliant wallet

or as sech1 said, > 16:57:13 <sech1> If they make a "wallet", it will be at best a custodial wallet which is transparent to them anyway. At worst it will be a number on the screen, representing paper XMR

they did it for bitcoin already, wrapped bitcoin etc.

wrapped monero on hyperliquid too

nioc: they won't read even when linked

also it's tbh deep cryptography even when explained well

So a great excuse to believe what you want to

just_another_day:matrix.org: it's already on reddit being posted as old wallets becoming automatically transparent too :P

see how it amplifies to nonsense levels?

<ofrnxmr:xmr.mx> DataHoarder: I dont see the problem

<just_another_day:matrix.org> well there is an obvious gap in communication

<ofrnxmr:xmr.mx> The more ridiculous the fud, the easier to dispell it

there was also a gap of years for these changes to be seen and they were even being lauded as excellent

tonal shift, after the previous fud was dispelled, using the next step. the concerns are valid, but blown out of proportion, and represent an idealistic view of exchanges or alike

<ofrnxmr:xmr.mx> i say: damage control is for politicians

where, again, they will not stop at "oh I can't do this" they will just go further, or make it possible

my fud is: whoever is driving this is actively trying to damage forward secrecy in monero against future quantum adversaries, and uncover the recent past (instead of distant past)

<ofrnxmr:xmr.mx> And i mean, politicians who are looking to hide stuff. A single post about OVKs pros, cons, FAQ, is all that is needed

<ofrnxmr:xmr.mx> The rest is just arguing with a fool and trying to win

also remember: bitmain is trying to release X9 which also next hardfork will alter its efficiency (RandomX V2)

they are already sending meetings with certain people to discuss "changes to monero randomx" on linkedin/reddit paste.debian.net/hidden/40150a6c

it wouldn't surprise me this is again yet another campaign helped with that

<ofrnxmr:xmr.mx> My fud is: whoever is doing this is worse at spreading fud than the spam alt imposter that frequents these parts

like Cryptonote -> RandomX back then

or Cryptonight* even

<ofrnxmr:xmr.mx> And that if this fud gets us another justin bons 1000 word twitter rambling, i say lfg

yeah ofrnxmr:xmr.mx the imposter is usually embedded well, I'd expect to see them here soon to make noise as some fake account

<just_another_day:matrix.org> How do you distinguish a change output with a normal output someone else send you?

they find the best timing

<ofrnxmr:xmr.mx> DataHoarder: They reappeared a few days ago. All peaceful-like

just_another_day:matrix.org: timing, and address index

if it goes back to subaddress index 0 of the account, it's likely change

if you get sent to non-zero subaddress index in the account, someone sent them to you

oh, who was it ofrnxmr?

<just_another_day:matrix.org> so we only have to randomize address indexes to mitigate this?

that is not how it works, it'd also give you the same information

like self-send change to 0 uses random

and again makes it identifiable

the way is to not use subaddresses, only use main address :')

everything is 0,0 :P

<just_another_day:matrix.org> can you send 0 change to a random address instead?

some wallets do that, you can still identify normal change though

<just_another_day:matrix.org> this all just seem a subtle leak that isn't an intended property of incoming view keys

<ofrnxmr:xmr.mx> @just_another_day:matrix.org: monero-project/monero #10266

it's sadly how the wallet works

not view keys

<just_another_day:matrix.org> so we again better fix this instead of using it as justification for OVKs

<ofrnxmr:xmr.mx> Its not justification for ovk

it is not justification wtf

thanks to the generate image key, these self-sends won't be identifiable anymore on FCMP++/Carrot btw

legacy wallets will continue having these

<ofrnxmr:xmr.mx> And ovk is optional. You dont have to migrate your wallet unless you want to take advantage of carrot stuff, like ovk and quantum turnstile

<just_another_day:matrix.org> @ofrnxmr:xmr.mx: this is used a part of the argument that ovks don't change anything

^ legacy wallets will continue having old behavior

<ofrnxmr:xmr.mx> @just_another_day:matrix.org: who's argument? reddits? Ofrn not on reddit. Ofrn letting reddit spam grow until AI thinks it can fix it and AI journalists start reporting on it

<just_another_day:matrix.org> no not on reddit. here > <DataHoarder> current view outgoing keys already disclose spends

<johnjenkinss:unredacted.org> i think a lot of people are spreading the part of "Tainted and non tainted coins", which i keep reading is still impossible

just_another_day:matrix.org: the change MUST go back to your wallet, so yeah, the spend disclosing is there

<ofrnxmr:xmr.mx> monero doesnt have a paper trail, with or without ovk

<ofrnxmr:xmr.mx> You cant see where coins came from, or where they went to

under FCMP++ you cannot have tainted coins or outputs correct

<just_another_day:matrix.org> unless the sender also has shared ovk

they can't tell where it comes from or do output tagging

<ofrnxmr:xmr.mx> If the sender also has any view key, both of your wallets will share a txid

<ofrnxmr:xmr.mx> sender's change will have same txid as receivers incoming tx

^

not even ovk

you just need view incoming keys

or, a reporting wallet with proofs

<just_another_day:matrix.org> i see

DataHoarder: i wouldn't be surprised if someone's using OVK as lighter fluid for the massive fire to stop the hard fork

<just_another_day:matrix.org> so if the change leaks would be fixed, it wouldn't be an issue

it also gives you full info on balances

with just view incoming keys on both sides

what do you mean leaks

this is fixed under new carrot

<just_another_day:matrix.org> Cindy: Carrot doesn't even require protocol changes, does it?

<ofrnxmr:xmr.mx> Cindy: we honestly dont even need carrot for the hard fork. Stressnet runs fcmp w/o carrot ovk etc

<just_another_day:matrix.org> it's offchain thing

change is an internal self-send and it requires that key hierarchy

it requires them for a future quantum migration

<ofrnxmr:xmr.mx> Initially the idea was to only include carrot if it was ready at the same time (or before) fcmp

those outputs need to be sent to addresses generated that way to be eligible

yes, but carrot solves the post-quantum stuff

^ yeah carrot can come anytime

which i'd like to think is what they don't want :P

<just_another_day:matrix.org> yeah so i'm not some evil agent trying to delay the hardfork

including by someone else making a wallet

<ofrnxmr:xmr.mx> Cindy: Some* post-quantum stuff. Monero still needs another hf to become post-quantum

17:33:29 <br-m> <just_another_day:matrix.org> so if the change leaks would be fixed, it wouldn't be an issue

the change must be seen for the wallet to spend it

you don't need to detect what is change and what is not if you have view incoming keys on both sides

yeah ofrnxmr this sets up the hardness and specifically allows migration even if we have to turn off new transactions using old method

<just_another_day:matrix.org> fair enough

like you don't even care about decoding spends there, as decoding incoming gives you all balances and fee is public

that gives you an exact amount

for example, blocks.p2pool.observer/tx/8898ea6e1…d5bd6487000278900e0b516252b6a1d75b4

a tx that Monero GF donated to Monero CCS fund

we have auditing view incoming keys for both

so we could usually exactly find what combination of inputs was used even if we didn't have the rings (FCMP++ removes rings) or spend keys

that allows finding the sender, and the recipient, even if subaddresses were entirely randomized

you don't need the view keys, them just reporting the proofs (InProofV2) for each received output would allow the same

<just_another_day:matrix.org> reporting proofs is interactive

<johnjenkinss:unredacted.org> wait, to understand, this is showing who sent monero and to who, and how much?? i saw that link earlier but i was late to the conversation, want to have the context > <DataHoarder> for example, blocks.p2pool.observer/tx/8898ea6e1…d5bd6487000278900e0b516252b6a1d75b4

a cex could force you to use such wallet

<ofrnxmr:xmr.mx> @johnjenkinss:unredacted.org: Generalfund sent a donation to ccs

also getmonero.org/resources/moneropedia/viewkey.html > Thus, Monero is said to be "private, optionally transparent".

in comparison with transparent, optionally private

johnjenkinss:unredacted.org: both monero CCS and Monero General Fund have their view incoming keys public, so we can know when they receive funds

<ofrnxmr:xmr.mx> We have biew keys for both wallets, so you can determind which output whwn where, and the total size of the spend outputs and change

<just_another_day:matrix.org> so the UX barrier to have the user comply increases > <DataHoarder> a cex could force you to use such wallet

in this case GF sent 32.44 XMR to CCS, and the change from the two inputs went back to GF

<ofrnxmr:xmr.mx> Fud: OVK enables this

<ofrnxmr:xmr.mx> fact: this is already a thing for cirrent view keys

incoming keys are useful for verifying if funds have been received

but not for verifying the balance

without key images

just_another_day:matrix.org: the UX will go as far as needed, the regulators don't care. they will ask for your spend keys or seed words

so the next step is to get rid of seed words and users viewing their own wallets entirely

<just_another_day:matrix.org> that's not how it works.. non-KYC dexes aren't prohibited

<ofrnxmr:xmr.mx> IMO, OVKs are good for merchants (lets say, a restaurant) to monitor balances

^

17:43:43 <br-m> <ofrnxmr:xmr.mx> fact: this is already a thing for cirrent view keys

exactly

^ and will keep being a thing post FCMP++/Carrot

even on legacy wallets

migrating fixes this for change/self-send

<hooftly:matrix.org> why would a dex ask for anything?

i'd like to show you my mainnet wallet

<ofrnxmr:xmr.mx> @hooftly:matrix.org: Serai etc uses view keys as a part of its protocol

which has 2 million XMR

just_another_day:matrix.org: then use those lol

i'll give you the view key

:P

<just_another_day:matrix.org> i see > <DataHoarder> 17:43:43 <br-m> <ofrnxmr:xmr.mx> fact: this is already a thing for cirrent view keys

again it'll self regulate to users not providing KYC or not providing other information like their wallet spend keys

or forced to used some "centralized" wallet

like BSV chain with all the tokens

<hooftly:matrix.org> @ofrnxmr:xmr.mx: all users keys or the validators?

with "bridges"

or solana, or anything that has a bridge that is cheap

<just_another_day:matrix.org> i don't want 99% of users doing KYC so that it's very easy to prohibit non-KYC exchanges for the rest > <DataHoarder> just_another_day:matrix.org: then use those lol

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: Basicswap uses view wallets as intermediaries during the atomic swap - but i dont think bsx sees any benefit from ovks

DataHoarder: or some wrapped token where they don't hold the underlying XMR

<ofrnxmr:xmr.mx> @hooftly:matrix.org: No clue

just_another_day:matrix.org, remember this is not possible if other users exist

they can send between users and that breaks any chain

<hooftly:matrix.org> @ofrnxmr:xmr.mx: But these are never visible on chain right?

you are also assuming 99% of people go to use non-existent CEX that all comply with an ask similar to a scam

<ofrnxmr:xmr.mx> @hooftly:matrix.org: right, and they arent made public either. Only the 2 parties involved in the swap are aware of them

<hooftly:matrix.org> awesome!

it's super easy to make a wallet for CEX

do whatever bullshit they want you to do (even give your OVK)

and then sweep all to another wallet

<hooftly:matrix.org> In the end this is a non existent issue

yes

hahaha they are already mixing sgp's fud along with it

<just_another_day:matrix.org> Cindy: at some point they can start tracing coins beyond the current wallet, flagging your funds if the history goes into a non-transparent wallet

no

<just_another_day:matrix.org> the naxo fud?

even if they flag your funds, what are they gonna do

they're not gonna magically rip the monero from a view-only wallet

<just_another_day:matrix.org> make your monero unspendable

yep, naxo

make my monero unspendable how

<hooftly:matrix.org> Dont use a cex

stealth addresses make that impossible

<just_another_day:matrix.org> he's evil money launder, don't accept his monero!!

who

^

they will prohibit you from interacting with them again

<hooftly:matrix.org> Dont use a CEX

you can send to new wallet

<just_another_day:matrix.org> it's about merchants too

DataHoarder: yes

just_another_day: merchants don't know the difference

because of stealth addresses

they won't know where the XMR came from

how do you expect new users to onboard

<just_another_day:matrix.org> from a cex

how do you know that

<johnjenkinss:unredacted.org> i would assume this only matters if you're trying to spend on a CEX or something, im sure companies like Mullvad, or reflectacles, Xmrbaazar, or Trocador arent gonna flag your funds as they dont really care where it came from > <@just_another_day:matrix.org> make your monero unspendable

how do you expect merchants to onboard new users

say a random comes and buys x

shares their spend keys even, let's make it simple

we are sharing spend keys now

ok how does a cex identify a new user

are you sharing your keys with everyone?

they come with their full spend keys

and ... now what

<just_another_day:matrix.org> they look at the history of his coins. If a too big portion is untracable due to the lack of view keys, they flag it

they can tx?

so that means everyone is flagged automatically

remember you can't control who sends to you either

that's pretty much doable with incoming view keys alone

^ (referring to DataHoarder)

<just_another_day:matrix.org> that's true

also you can't look at the source of the XMR

yes Cindy

but let's assume

spend keys

so like

maximum view

or even paper wallets

let's make it simple to argue about

yeah, even with spend keys you can't

UNLESS it is mined as solomine or p2pool

if it's mined via centralized pool -> can't

<ofrnxmr:xmr.mx> If i delete my cache file, or turn off "save recipient addresses" in cake (or cli etc), i literally have no idea who i sent to

<just_another_day:matrix.org> i've said it yesterday. If you have a maximum view on wallets, they're split into transparent and non-transparent. You can think about the non-transparent wallets as a big "shielded pool". Too much money from the pool -> you get flagged

<ofrnxmr:xmr.mx> @just_another_day:matrix.org: Your pool payments are visible by punching your address into the pook

who are you gonna share your view keys with

<elongated:matrix.org> You are still here spreading non sense ?

<just_another_day:matrix.org> Better here than on Reddit, right?

<ofrnxmr:xmr.mx> The pool knows where it sent the money. Bitcoin pools are funny - they pretend not to know

just_another_day:matrix.org: there are no transparent wallets, it's outputs, and FCMP++ breaks this linkage

same as bitcoin

<just_another_day:matrix.org> transparent = those who've shared OVK/spend key/whatever

like, you can't know how the txs were received even if it's from elsewhere

so why is this not done now then?

when they have the same if not better tools

<just_another_day:matrix.org> you mean requiring everyone to share CryptoNote's view key?

why so much noise to stay on the old system that also opens you to quantum opponents making everything transparent in the future?

this is what you are asking, by removing the ability to split spend key + view key into a hierarchy of granular keys that can't be walked back by a quantum opponent

<just_another_day:matrix.org> i'm not sure if it's absolutely necessary for post-quantum security

just_another_day by being here and asking your questions and getting knowledgeable answers you can now go forth and fight the fud

it is, as defined on the derivations on github.com/jeffro256/carrot/blob/master/carrot.md

and for the PQ Turnstile gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

2.2.1 is the strong one > Internal forward secrecy

basically all stuff once sent to your wallet is non breakable in the future by quantum adversaries and stays secret

what this means is that change and self-sends stay hidden, meaning they can't tell you sent or transacted on your wallet

if they know the involved addresses (not keys) a quantum adversary can still break things like 2.1.1 says (conditional on them knowing the receiver target address)

but 2.2.1 is what allows your own history to stay secret

then, it also allows the PQ Turnstile for a migration even when you can't "transact" anymore due to an active quantum adversary

that is the linked gist

that requires first proving the derivation, then proving the signature on the key image in an alternate way that couldn't be broken ahead of time

you can read the details on the gist, it is inspired on Switch Commitments eprint.iacr.org/2017/237.pdf

@just_another_day:matrix.org: but you also said it's not a cryptography problem, when it is and last night the main developer also said how bullshit it is

mrelay.p2pool.observer/p/2raZ_d8KRFdDOVIz/1.txt (code snippet, 5 lines)

<gan:skhron.org> I think that I lost some braincells after reading that

<intr:unredacted.org> is the view key bullshit still going on...?

<ravfx:xmr.mx> Look like

<ravfx:xmr.mx> Can everyone just send me there FDE AES keys now?

<ofrnxmr:xmr.mx> @intr:unredacted.org: Ya, new reddit post -> deleted by mods -> reee -> repeat

<intr:unredacted.org> are you serious...

<intr:unredacted.org> they're AI generated

<intr:unredacted.org> I fucking called it

<ofrnxmr:xmr.mx> Which is the beauty. Id leave it up so ai can train on ai slop and produce more garbage

<intr:unredacted.org> I'm more of an iocaine enjoyer

<just_another_day:matrix.org> nioc: I'd like to fight the fud, but I'm still confused. What DataHoarder has explained to me is that:

<just_another_day:matrix.org> 1. If both sender and receiver has published their incoming view keys, then it's possible to see the whole transaction history between them

<just_another_day:matrix.org> 2. OVKs are necessary for quantum migration

<just_another_day:matrix.org> Is this right?

<pw:xmr.mx> It's nothing new.

<pw:xmr.mx> That is right.

it's not that the OVK are necessary for migration, but that for forward secrecy against a quantum opponent you need to split spend and generate image keys, which then allow to create OVK, and such split is also what allows the safe migration even with active quantum opponents

Basically not we want OVK -> let's bolt it to all quantum and forward secrecy stuff

It's the other way around

That is also why legacy wallets cannot obtain that internal forward secrecy

Jamtis details also has interesting tiers gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024

Including a "filter received" to generate view tags (but not decode info) that can be used for scanning

> It cannot see outgoing payments and received change.

<just_another_day:matrix.org> DataHoarder: This tier is cool af. Sad that carrot doesn't include it

Which is similar to new carrot tier of view incoming

It can't due to design on current monero

It'd require migration away or change address format

And*

<just_another_day:matrix.org> I see. It'd greatly mitigate the privacy risks of light-wallets

Carrot is a middle hop to allow inter operation instead of having every user make new wallets or generate new addresses immediately, or have environment change address format

<just_another_day:matrix.org> Would it be possible to do the split without creating OVK? > <DataHoarder> it's not that the OVK are necessary for migration, but that for forward secrecy against a quantum opponent you need to split spend and generate image keys, which then allow to create OVK, and such split is also what allows the safe migration even with active quantum opponents

<intr:unredacted.org> the jamtis addresses were comically long

What you call OVK is "Full view only wallet" in Jamtis

And they are getting longer of the new proposals

<hooftly:matrix.org> Lol

<intr:unredacted.org> which new proposals

The split necessarily creates that OVK or a similar one

It's about splitting the image generation/validation from spend keys

<just_another_day:matrix.org> I see

So you don't need to disclose spend keys (used in signing) when migrating or transacting

This new one monero-project/research-lab #151

intr^

<intr:unredacted.org> ty

<intr:unredacted.org> wait, so jamtis is not off the table entirely?

No

<intr:unredacted.org> interesting

Carrot cake in for FCMP++ as it'd ease the transition way quicker

Jamtis and other research continues

It's a bit complex

<intr:unredacted.org> yeah, I'm also confused as to what happened to seraphis itself

<just_another_day:matrix.org> > If both sender and receiver has published their incoming view keys, then it's possible to see the whole transaction history between them

<just_another_day:matrix.org> By the way, can you distinguish a transaction between them and a transaction that just sends coins to both of them from a third party?

As there was also Seraphis and FCMP++ dev moved to the same repo but seraphis part was left behind in favor of fcmp

<intr:unredacted.org> I see

<intr:unredacted.org> I remember seraphis bringing some sort of modularity to the wallet codebase, I wonder if fcmp took inspiration from that

The specifics there escape me a bit as there's a few more factors that can change that

<intr:unredacted.org> np

If they don't have the full view (only view incoming) they can't see the internal change output

I was answering just another day

<intr:unredacted.org> oh

In that case they just see a payment to the recipient if they know their address

But not the other way back

Ofc, this is assuming it's the new carrot and not legacy under carrot

Legacy under carrot: yeah it can be obtained in certain cases

<kowalabearhugs_> Monero gets a mention from a shadow library admin, bsky.app/profile/ednewtonrex.bsky.social/post/3mcyye3yl4s2d

<hooftly:matrix.org> Lol wild

<hooftly:matrix.org> Yaaaarrr

<kiersten5821:matrix.org> 🏴‍☠️

<gan:skhron.org> Information wants to be free

<preland> mrelay.p2pool.observer/m/monero.social/CaoLqmUHSSnEEzECEMsTvJEt.jpeg (ima_b17f12d.jpeg)

<preland> lol

Also remember, that is not part of the hard fork even now

The base scheme is there but only legacy wallets are in main Monero code (or been tested in stressnet)

It is an addressing scheme, which works for Carrot/Jamtis style outputs

<ravfx:xmr.mx> @kowalabearhugs_: I wonder what payment method Nvidia used

do I need to join that Discord accursed place for fud campaigns?

<321bob321> Discord is only to share state secrets

<pyratevevo:matrix.org> @kowalabearhugs_: Making the biggest companies in the world pay for the best shadow library website is an unusually positive ordeal.

<just_another_day:matrix.org> What are OVKs good for? Besides quantum migration

<pyratevevo:matrix.org> You still doing this bud ? Gotta respect the effort.

<redsh4de:matrix.org> @just_another_day:matrix.org: Christ

<redsh4de:matrix.org> 1. Makes DEXes easier to create, taking power away from CEXes

<redsh4de:matrix.org> 2. Proper view-only wallets

<redsh4de:matrix.org> 3. Better auditing for donations - transparency is needed there to see how and where donated funds are being spent[... more lines follow, see mrelay.p2pool.observer/e/zdyOg-AKN0VmTl85 ]

<just_another_day:matrix.org> Kyaba said Serai is good without OVKs

<pyratevevo:matrix.org> @redsh4de:matrix.org: From what I understand it also helps accpunting for businesses who accept XMR.

<redsh4de:matrix.org> @just_another_day:matrix.org: Serai isn’t the only DEX out there, it took a lot of engineering effort to make it work without OVKs

<redsh4de:matrix.org> Thorchain have a skill issue thats why they werent able to add Monero

<just_another_day:matrix.org> 3. * lol. So suddenly they're good for audits when the audits are "harmless", but don't change anything when the audits are done for compliance

<redsh4de:matrix.org> OVKs lower the technical skill barrier to make it happen

just_another_day: OVKs allows for easier management of fundraisers

like in kuno

without OVKs, it would be super easy for someone to inflate the amount of XMR they got

to make their fundraiser look big

stop exposing me

<kiersten5821:matrix.org> @kowalabearhugs_: RIP libgen

and attract more people to take a look at it

my kuno to raise awareness of Monero in the outer solar system has garnered 300 xmr repeated self donations of 0.1

lol

<redsh4de:matrix.org> @just_another_day:matrix.org: “Audit” in this case literally means just verifying donations or fundraisers and their usage

<redsh4de:matrix.org> Arguing against this is ridiculous

<redsh4de:matrix.org> Missing the forest for the trees

it's so easy to "boost" a fundraiser with self donations

because of this flaw

i hope kuno doesn't start asking for key images :P

<kiersten5821:matrix.org> 🔑

<kiersten5821:matrix.org> I still don't understand the view key controversy

me neither

<just_another_day:matrix.org> regulators would also want to audit many entities. making audits better is a double-edged sword

<kiersten5821:matrix.org> i thought the only difference is the new key has an outbound viewing feature which the old one only had an inbound viewing feature

<kiersten5821:matrix.org> did anyone answer my question list from 3 days ago?

<redsh4de:matrix.org> Regulators already audit centralized registered entities

<redsh4de:matrix.org> Changes nothing

<redsh4de:matrix.org> @kiersten5821:matrix.org: Thats all it is

<just_another_day:matrix.org> @redsh4de:matrix.org: they can't audit everyone, it's unscalable

<just_another_day:matrix.org> unless you provide an easy way to do so

also with OVK, it solves the issue of having to ask people to give key images to fix broken balances

<redsh4de:matrix.org> It is not a easy way to do so

<redsh4de:matrix.org> Because there are steps to it that add friction

balances that are too inflated because they took out some and the monitor registered the internal change output as a "donation"

<redsh4de:matrix.org> This doomsday scenario does not scale in the first place

<just_another_day:matrix.org> if OVKs facilitate audits for donors, then they also facilitate audits for regulators. I don' understand why this logic doesn't hold

<redsh4de:matrix.org> If view keys were auto-embedded in transaction data sure, you could argue that its like Zcash t-addrs or whatever

it's unscalable because of the amount of wallets you have to scan

for each transaction

<redsh4de:matrix.org> That too

the cost of scanning a single transaction increases the more wallets you have to account for

for those that haven't seen, DataHoarder shared that someone shared this "Carrot and Monero quick facts" mrelay.p2pool.observer/m/gohegan.uk/tIxkJWnZuzmIFmmRSFojQxsd.png

<just_another_day:matrix.org> they're not running their surveillance on a nokia 😅

i'm sure somebody will write a well-optimized version of the wallet scanner

would be much much better on a GPU tbh

but for now, that stuff is pretty hefty

especially if you're scanning from genesis to the tip

<kaigoh:gohegan.uk> plowsof: It was me - it's not great, but it gets the message across. I still think something with more detail would be beneficial!

<kayabanerve:matrix.org> Serai doesn't require OVKs. Auditing Serai validators' behavior would be immediate if we used OVKs. Currently, we are only able to observe faults as liveness faults where OVKs would provide explicit evidence to some fault criteria.

<kayabanerve:matrix.org> OVKs allow scanning spends by anyone you give your key to, like current spend keys. You don't want someone to scam your spends? Don't give them your OVK (or spend key currently).

<kayabanerve:matrix.org> It's really just a tired debate after days of going in circles. This clearly improves security for determining balances and makes selective disclosure easier.

<intr:unredacted.org> it strikes me as less of a debate and more of concern trolling

people want a choice of keeping a legacy wallet or upgrading, and they will have that choice right? however that gets implemented in wallets i dunno. the concern trolling is the hardfork evil devs will kyc all your spends and "full government name" included every alias/handle known is a core developer running 5 chainalysis companies who has control

over this hardfork

and censorship to hide the secret hardfork!

<intr:unredacted.org> and the top-secret hard spoon

<just_another_day:matrix.org> > makes selective disclosure easier

<just_another_day:matrix.org> > that's what people don't like

<kayabanerve:matrix.org> Oh no, you'll be limited to legacy wallets without such functionality which have identical addresses and will continue to operate as before for the indefinite future

<kayabanerve:matrix.org> the horror

<kayabanerve:matrix.org> "concern trolling" does seem the best summary to me

just_another_day: are you really sure you want to combat FUD?

or is it JUST ANOTHER DAY of going in circles with you

21:38:33 <br-m> <just_another_day:matrix.org> What are OVKs good for? Besides quantum migration

it's the other way around

as said. the ovk comes out from the way the keys are split for specifically keep your history forward secret

22:11:14 <@plowsof> over this hardfork

it's not even a wallet hardfork

the thing they are complaining about doesn't need a hardfork, it could come *today*

😭

<hooftly:matrix.org> mrelay.p2pool.observer/m/matrix.org/XRhIJNCdUXJqaoxPrCefAKwJ.jpg (1000008405.jpg)

just haven't bothered to do new carrot on current outputs

you guys are wasting your time over someone who will never actually change their mind

<kayabanerve:matrix.org> Akshually, OVKs are a result of how the backwards-compatible reinterpretation of output keys introduced a malleability in the statement such that it only proves the rerandomization is openable over G, T, not that the original output key was openable over solely G 🤓

<kayabanerve:matrix.org> This allows us to malleate output keys with T terms, and that property enables forward secrecy

kayabanerve: how do you become this smart

but it's not cryptography, cause I feel like it's not kayabanerve

:P

<kayabanerve:matrix.org> Then, the fact that output keys are derived from an address and an address is indistinguishable if containing solely a term over G or terms over G and T... well you know the rest 😏

is this apart of the monero generators lore?

<kayabanerve:matrix.org> That is actually the historic progression of this though lol. Forward secrecy was only realized when I realized one could mess with this. We just said that was a feature, not a bug™

the reddit threads are titled "Say no to the hardfork" 😆

<kayabanerve:matrix.org> The idea naturally extended from there to also messing with the addresses themselves

<kayabanerve:matrix.org> plowsof: That's their right, it's called a hard fork for a reason. They can...*checks notes*not update their node software to one implementing the FCMP++ hard fork

<kayabanerve:matrix.org> yayyyy personal choice and liberty

plowsof: but it's not even there yet lol, wallet code

we will split the chain!

we will mine our own chain with its own consenus

carrot could literally exist today

just need to move one thing to tx extra :P

<kayabanerve:matrix.org> Cindy: Do dumb things for over a decade and you start to realize what isn't dumb.

<kayabanerve:matrix.org> Or, properly educate yourself with the widely available literature available in this modern age

ah well that makes sense

i might not run a node, or know what im talking about, but ill have more karma on reddit by the time im finished here, mark my words

what is coming is a change in tx output format

<kayabanerve:matrix.org> Many options, I somewhat wasted my early years, it does not take a decade to get this to this level which isn't not that of a proper cryptographer

which by convention legacy wallets and new carrot and maybe jamtis can share

<kayabanerve:matrix.org> I'm an informal cryptographer/cryptographic engineer IMO

soooo.. term for person who just messes with math?

<kayabanerve:matrix.org> Yes but I get results :D

<kayabanerve:matrix.org> *sometimes. People hear more about my successes than my failures :p

<kayabanerve:matrix.org> My early years were messing around _without_ accomplishment.

the wallet could be something else, just won't be compatible on other software

i'm not much of a cryptographer either

i don't think i'm allowed to call myself that :P

all i do is mess with the code a little

so that is why I am calling all of this fud plowsof it's not a hardfork for the wallet code, just the tx output which is NOT tied to the wallet code, it's not something that was added -> then found a feature to "stick" to like quantum safety, and best of all, the wallet is not even there

it's making overreach in every single aspect to have something stick and be divisive, specially around "say no to hardfork" -> the new carrot derivation can be implemented regardless, with some **

👍

they also misunderstand what carrot is. it's both the tx output side, and new addressing modes

i for one, will run the newest version of monero

cuz i agree with the decisions

others can go split the chain or something

also fun. the hardfork can release anytime and not have to wait for Carrot addressing mode

but it will have carrot tx output format (which all wallets use, even custom ones later down the line)

example, I might end up using a custom derivation for special multisig purposes that is temporary. it can be used in then network, transacted with, but ofc can't use the PQ Turnstile cause it is not the Carrot addressing mode

but yeah, I guess I understand this cause I reimplemented these things

<kiersten5821:matrix.org> literally the only difference is it can see outbound transactions and this is now a problem? I'm so confused... this is like a nothingburger > <@redsh4de:matrix.org> Thats all it is

and ran stuff on stressnet

<kiersten5821:matrix.org> this will make airgap management so much easier right?

the hardfork does not even do that as well

it's new wallet addressing mode that doesn't necessarily need a hardfork per se

yes, it'll make it so much easier

except for some other features around quantum safety

because you don't have to have the spend key to look for outgoing TXs

<kiersten5821:matrix.org> i last tried to use an airgap wallet a very long time ago and i had to import key images a lot

<kiersten5821:matrix.org> wait, i think the problem was that even though the hot side of the wallet can see the outgoing tx, you have to tell the cold side that it's outgoing

<kiersten5821:matrix.org> and still have to send it some data

yes, but now it's even easier too ^

<kiersten5821:matrix.org> i don't know if the view key will help in this case as the offline side still won't be able to sync/see?

as FCMP++ signatures can be made without decoys

that can be filled later by an online view wallet

(the membership proof)

<intr:unredacted.org> insanely cool stuff

<kiersten5821:matrix.org> so you could actually initiate the tx from the cold side?

<kayabanerve:matrix.org> If it knows its UTXO set, yes

<just_another_day:matrix.org> well some of you are keen on not realizing the problem of adding "easier selective disclosure" into Monero

<just_another_day:matrix.org> i can't help with that

"easier selective disclosure" already exists :P

spend proofs, TX proofs

<hooftly:matrix.org> Nonsensical

<just_another_day:matrix.org> easier than what?

<hooftly:matrix.org> You can build a wallet that selectively discloses with a singlw button already thats what you are arguing against and its absolutely stupid

<intr:unredacted.org> please not again

<intr:unredacted.org> I am going positively insane

<just_another_day:matrix.org> my theory is that blockchain surveillance really wants this feature in Monero

<just_another_day:matrix.org> so devs pretend it's not a problem

<hooftly:matrix.org> Oh so its even dumber

<intr:unredacted.org> you'll have an easier time theorizing that small/limited block size is what blockchain surveillance really wants in monero

<just_another_day:matrix.org> yeah like.. even the same people pushed that

<hooftly:matrix.org> @intr:unredacted.org: Good job...

<hooftly:matrix.org> Haha

<intr:unredacted.org> lmao, sorry

i love when people complain about a nothingburger for the 1000th

fucking time

blockchain surveillance companies can already tell you sent someone a TX with just the incoming view keys

and when they see that, they'll ask you for keys related to that TX

<kayabanerve:matrix.org> I proposed a 100x current base block size limit pending a new P2P layer and was associated with those accused of being chain-analysis plants

<kayabanerve:matrix.org> wooooo McCarthyism, alive and well 😎

<intr:unredacted.org> forget I said anything

kayabanerve: this definitely sounds like mccarthyism

everyone's quick to point their pitch-forks and accuse those of working with LE or federal agencies

<kayabanerve:matrix.org> When will there be a fork/new wallet protocol without incoming view keys?

or chainlysis et al.

<kayabanerve:matrix.org> (to make consensual disclosure as annoying as possible)

<kayabanerve:matrix.org> (and to worsen the impact of coerced disclosure of view keys by promoting it to coerced disclosure of the spend key as well)

i like how nobody talked about why view keys existed in the first place

it's almost as if when it's already implemented, nobody actually cares

it's just doom and gloom up until it gets implemented.. then people just shut up after a while

<hooftly:matrix.org> Nope Feds

22:59:29 <br-m> <just_another_day:matrix.org> well some of you are keen on not realizing the problem of adding "easier selective disclosure" into Monero

it wasn't added, again

it's a side effect, and something you can still do

old wallet will STILL be able to do that

23:01:57 <br-m> <just_another_day:matrix.org> my theory is that blockchain surveillance really wants this feature in Monero

why is it not done today then?

yes, why is it not done now

we can already tell if a TX was made by just looking for change outputs

but yeah. remember a few weeks ago it was around forward secrecy and ability to stay safe against quantum opponents? carrot features and PQ was pointed out

surprise. now it's specifically targeting THAT ability for monero to stay safe in the future and relevant (and prevent internal history from being entirely in the open, even if you don't give view keys, as long as addresses are collected)

<intr:unredacted.org> that is a very good point

id rather want quantum adversaries to know all the TXes i made

rather than the hypothetical doom and gloom situation where i may be forced to give up my view keys (with my knowledge)

one can be done without you knowing, the one can't be done without you knowing

<rrjo1zj8p7lhtl15lylp:matrix.org> “Legitimate users” don’t want convenience at the expense of privacy.

<rrjo1zj8p7lhtl15lylp:matrix.org> The entire premise of Monero is default, uncompromising privacy. Not opt-in. Not selective. Not ‘easier disclosure’.

<rrjo1zj8p7lhtl15lylp:matrix.org> If you want auditability, compliance hooks, or features that make institutional oversight more convenient, there are already coins built for that. Go use ZEC, go use transparent chains, go use something designed to play nice with FINTRAC and regulators.[... more lines follow, see mrelay.p2pool.observer/e/0Pz2heAKMkFGTGhQ ]

> Thus, Monero is said to be "private, optionally transparent".

on monero front page since I remember

monero is not "uncompromising privacy" whatsoever

> If you want auditability, compliance hooks, or features that make institutional oversight more convenient

and using features

and also "not selective" is not true either

TX proofs and spend proofs exist

and are used

suddenly your coins cannot be used in cold storage

<ravfx:xmr.mx> Imajin puting your whole full wallet in your shop (that could get hacked)

<ravfx:xmr.mx> non, that where you use view keys...

yes

if view keys didn't exist, it would be super easy to compromise and steal moneros

<ravfx:xmr.mx> you can know the customer paid, but if someone break it, no funds can be stolen

<ravfx:xmr.mx> yeah, pretty sure most shit that accept monero use view keys in there server so they can keep there monero when they get hacked

<rrjo1zj8p7lhtl15lylp:matrix.org> “Optional transparency” has never meant “optimize disclosure.”

<rrjo1zj8p7lhtl15lylp:matrix.org> TX proofs require conscious, per-use action. That friction is intentional.

<rrjo1zj8p7lhtl15lylp:matrix.org> Protocol or wallet changes that reduce friction don’t just add convenience, they reshape expectations and coercion vectors.[... more lines follow, see mrelay.p2pool.observer/e/tcaEhuAKUXhhY1hQ ]

DataHoarder: also btw, you should fix the text encoding for the plain text stuff

it looks mojibake

text encoding?

it looks fine here

"“Optional transparency”"

also GhostMaple, that is obvious AI writing

that is so AI lol

and they are no protocol changes that allow that

the wallet stuff is already there ... if you check history here

discussed ad infinitum

giving the keys is also a choice

Cindy: on which message, IRC?

I see “ as " but curved

DataHoarder: on the mrelay.p2pool.observer link

you should probably do "Content-Type: text/plain; charset=utf-8"

irc.gammaspectra.live/4850060215e8c955/image.png

yeah I guess

<ravfx:xmr.mx> fud was successful btw

okay well tor browser assumes some other text encoding

thats why i get mojibake i guess

yeah, still good point

i can ignore the garbage characters :P

<rrjo1zj8p7lhtl15lylp:matrix.org> So what does adding this accomplish anyway? Trying to appease more CEX's to drive the price up and try and mimic what ZEC did last year?

i'm glad you're not using AI now

for one

<ravfx:xmr.mx> @rrjo1zj8p7lhtl15lylp:matrix.org: It allow proper operation of systems

<ravfx:xmr.mx> It already there, it's just more granular (so better)

<yokoama:matrix.org> will 13 word mymonero seed work post fcmp++ ?

<rrjo1zj8p7lhtl15lylp:matrix.org> what systems? why?

why do we need OVK? I only need a key to get in my house, not to leave it

<ravfx:xmr.mx> @rrjo1zj8p7lhtl15lylp:matrix.org: Think you have an online store that accept monero

<ravfx:xmr.mx> And instead of using view keys, you use your full wallet

23:29:07 <br-m> <rrjo1zj8p7lhtl15lylp:matrix.org> So what does adding this accomplish anyway? Trying to appease more CEX's to drive the price up and try and mimic what ZEC did last year?

it's not adding anything. it's not even part of a hardfork

<ravfx:xmr.mx> now a hacker find a way to break in and get the password of your monero-rpc

however, this makes the wallet internal history forward secret against quantum opponents

<ravfx:xmr.mx> then he can just send all the fund to itself

also allows migrating safely to a quantum system in the face of active quantum adversaries

<ravfx:xmr.mx> With view keys, your store can fully operate with a wallet than can't spend

it's not an EXTRA key

<ravfx:xmr.mx> so if a hacker come in, well, he can't spend your coins

DataHoarder is explaining OVKs, while ravfx is explaining view keys in general

it's a side effect of being able to achieve this security

and splitting spend key into spend key, generate image key

<yokoama:matrix.org> will 13 word mymonero seed work post fcmp++ ? <<>> mymonero is closing down, I suggest that you create a new wallet now and move your funds there

nioc: for most people, you don't need the OVK

that way quantum computers can't walk all they way up

but OVK make it super easy for things like fully cold storage coins

<rrjo1zj8p7lhtl15lylp:matrix.org> I'll try and do my homework before speaking anymore because I have no idea. Thanks

see also 2.2.1 point here github.com/jeffro256/carrot/blob/ma…rot.md#221-internal-forward-secrecy

yes yokoama:matrix.org

and fundraiser auditing

and it'll use legacy features

read on the carrot document, specially how quantum forward secrecy is achieved

<ravfx:xmr.mx> yeah, thing like ovk will probably allow cold wallet to fully sync without having the device plugged each time you get a transaction (or worst, having to scan a bunch of qr codes every time)

> I'll try and do my homework before speaking anymore because I have no idea. Thanks

^ this is what FUD achieves, all the conversations hear 1% of the things and are overreach over what happens

note this is also not a hardforkable thing, it's a wallet addressing scheme that can happen anytime, and doesn't even need to be monero

it could happen today, or way after any hardfork that adds FCMP++

or it could be some random dev that creates the wallet

Cindy: nobody has ever asked me for any keys, what am I doing wrong?

i want your keys

can you give me your keys

it doesn't need monero to support it

<ravfx:xmr.mx> nioc: Just send me your FDE AES keys please

<ravfx:xmr.mx> And you 42 words seed too

Cindy: I will check with Cat when she wakes up :)

now you can't say nobody ever asked you :D

thx

DataHoarder: i haven't seen FUD this massive since pubic

RandomX :P

isn't RandomFud already gone?

it's starting again

bitmain was making the rounds for v2 changes

I saw them reach out some days ago

and pushing anything that just makes v2 not happen in their fork is a win for them

that makes sense

the real fud is ram prices :(

<intr:unredacted.org> true, and ssd

they're probably the ones planting the seed for FUD

convincing people to not hard fork

<rrjo1zj8p7lhtl15lylp:matrix.org> okay I'm a noob, what is FUD

fear uncertainty doubt

<intr:unredacted.org> fear uncertainty doubt

<intr:unredacted.org> beat me to it

<rrjo1zj8p7lhtl15lylp:matrix.org> thanks lol'

<kaigoh:gohegan.uk> @rrjo1zj8p7lhtl15lylp:matrix.org: Fear, uncertainty and doubt. How we are manipulated on a daily basis by friends, enemies, colleagues and governments.

corporations also like to use it :P

<elongated:matrix.org> Cindy: No it’s fireice and gang

<intr:unredacted.org> I haven't heard that name in a long time

<rrjo1zj8p7lhtl15lylp:matrix.org> we sure are. That's why I'm here.

microsoft famously uses it a lot

or at least used it a lot back then

<elongated:matrix.org> @intr:unredacted.org: He works for ztrash now and still sour

<intr:unredacted.org> no way

<elongated:matrix.org> @intr:unredacted.org: Check ztrash Reddit

<intr:unredacted.org> > r/zcash has been banned from Reddit

<intr:unredacted.org> oh it's r/zec

<intr:unredacted.org> he's a mod lmao

<intr:unredacted.org> can't make this up

<intr:unredacted.org> even writes some sort of newspaper style blog

<intr:unredacted.org> I've seen enough lmao

<intr:unredacted.org> Where Are They Now ™

<johnjenkinss:unredacted.org> he's been real quiet since all the ztrash drama popped up and monero reached the all time highs lmao

<intr:unredacted.org> mrelay.p2pool.observer/m/unredacted.org/djBFABRtwIKzFRNJeHCpmyBq.png (clipboard.png)

<intr:unredacted.org> > supertestnet

<intr:unredacted.org> mrelay.p2pool.observer/m/unredacted.org/zBaLAhYeOleCpCoEEpqVkoNm.png (clipboard.png)

<ofrnxmr:xmr.mx> I thought fireice wasnt stupid

<ofrnxmr:xmr.mx> Maybe he got hacked and some retard is on his account making an ass of him

<intr:unredacted.org> @ofrnxmr:xmr.mx: I wonder what brought you to this conclusion

<ofrnxmr:xmr.mx> He ran spynodes and performed other notable network attacks

<ofrnxmr:xmr.mx> And iiuc, created his own blockchain (ryo)

<intr:unredacted.org> I didn't know about the spy node thing

<intr:unredacted.org> interesting

<intr:unredacted.org> vaguely remember Ryo

<ofrnxmr:xmr.mx> yeah, he modified monero code and ran hundreds or thousands of sybils for years

<ofrnxmr:xmr.mx> possible that he was even the one who added the high fee bug

<ofrnxmr:xmr.mx> Script kiddy lvl attacks, but still better than the garbage that supertesticle puts out

<intr:unredacted.org> supertestnet has got to be memeing

<intr:unredacted.org> "is this your card" type stuff

<ofrnxmr:xmr.mx> @intr:unredacted.org: He did a twitter space with bawdy iirc. I think hes genuinely just slow

<kiersten5821:matrix.org> @ofrnxmr:xmr.mx: added?

<kiersten5821:matrix.org> he made a pr that deliberately introduced that?

<ofrnxmr:xmr.mx> No, monero has a dumb feature that fwds your rpc requests to a random node

<ofrnxmr:xmr.mx> Nodes tell wallets what the fee lvl is

<ofrnxmr:xmr.mx> Malicious nodes were telling wallets that the fee was hundreds of times larger than normal

<plowsof:matrix.org> monero-project/monero #8134

<plowsof:matrix.org> this was the 3.x xmr tx fee 😬

<elongated:matrix.org> Recording? > <@ofrnxmr:xmr.mx> He did a twitter space with bawdy iirc. I think hes genuinely just slow

<ofrnxmr:xmr.mx> Not sure

ofrnxmr: seriously? regardless of how high it is?

<ofrnxmr:xmr.mx> @plowsof:matrix.org: Happemed more than once

i'd expect the wallet to have a sanity check where it refuses to make a TX once the fee is too high

like 0.1 XMR

or 0.2

<ofrnxmr:xmr.mx> I recall there was one when the pool was able to refund it

<ofrnxmr:xmr.mx> Can be infinitely high > <Cindy> ofrnxmr: seriously? regardless of how high it is?

number one philosophy is take whatever the server gives you with salt

<ofrnxmr:xmr.mx> Ofc, youre not going to succeed if the persons balance cant cover the fee

i would have definitely put a sanity check limit on the fee

<ofrnxmr:xmr.mx> And the asshole node doesnt get the $, since it goes to miners

like if it went above 0.1 XMR, just go to another node

or less than that

3.x xmr fee is insane

that's like thousands of dollars in fees

the client should crap out if it's even 5 dollars in fees

<ofrnxmr:xmr.mx> Its thusands now

<ofrnxmr:xmr.mx> It was like 600 at the time

"And the asshole node doesnt get the $, since it goes to miners"

so he just did it to troll monero users

he doesn't get any profit from it, he just lies about the fees to clients and watch them pay literal XMRs in fees

<ofrnxmr:xmr.mx> Exactly

<ofrnxmr:xmr.mx> Something FUK would do

does monero cap the fee amount?

or mitigate this in any way now?

<ofrnxmr:xmr.mx> No

(the official monero wallet)

no?

<ofrnxmr:xmr.mx> You can pay any amount you want

no i meant if it gets a very large fee from a RPC

<ofrnxmr:xmr.mx> Some wallets, like gui, warn you > <Cindy> or mitigate this in any way now?

not by user choice

there is a big warning

<ofrnxmr:xmr.mx> monero-project/monero-gui #3897

i wonder if alternative monero clients even bother with this

like cake wallet or feather

<ofrnxmr:xmr.mx> I think they did, but you only have to worry about it if using a node that is configured for bootstrap-daemon=auto

<ofrnxmr:xmr.mx> And no-sync=true