Monero logs

00:15:10 ravfx:xmr.mx: OVK, "something" View Keys?

00:15:10 ravfx:xmr.mx: If so yes, so much fud about that

00:16:36 Cindy: yes

00:16:50 Cindy: everyone's going crazy over OVK

00:26:40 jeffro256: @ravfx:xmr.mx: Yup

00:27:44 jeffro256: It's crazy how a couple FUD posts spread so fast compared to months of steady educational information

00:31:08 DataHoarder: years

00:31:10 DataHoarder: Jamtis also had the same

00:32:26 ravfx:xmr.mx: Even long time moneroers on my rooms went all on on that fud

00:32:45 ravfx:xmr.mx: It propagate so easily lol

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

00:33:20 DataHoarder: they can TODAY force the issue of such an addressing scheme btw

00:33:37 DataHoarder: I don't even mean rings

00:33:48 DataHoarder: but they can ask to use compliant wallets that implement that, if they so much wanted it

00:34:25 DataHoarder: "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

00:34:50 DataHoarder: then goalposts shift

00:35:11 DataHoarder: you saw it yesterday, now it's "yeah we shouldn't have any viewkey"

00:35:20 DataHoarder: so ... that forces you to move to no subaddresses

00:35:42 DataHoarder: or wallets that get lost if you don't backup every move

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

00:36:42 DataHoarder: the concern is around regulators forcing it on people, and these don't care how it gets done

00:36:57 DataHoarder: "that is your problem buddy now move to this wallet that implemented it regardless"

00:38:09 DataHoarder: 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

00:38:41 ravfx:xmr.mx: So the view key are required for subaddress operation?

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

00:38:45 DataHoarder: yes

00:38:50 DataHoarder: that is exactly how it works

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

00:39:13 DataHoarder: and why creating a million subaddresses doesn't slow down sync

00:39:23 DataHoarder: 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

00:39:24 DataHoarder: ^ and such the generate image key is made

00:39:39 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?

00:39:50 lza_menace: i had an onion address entered and the wallet would not accept it

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

00:40:59 DataHoarder: 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

00:41:45 DataHoarder: 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

00:42:15 DataHoarder: 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

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

00:42:47 DataHoarder: 🕵️

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

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

00:45:02 just_another_day:matrix.org: I see. I didn't even know about the quantum fud

00:45:16 just_another_day:matrix.org: I haven't yet looked into the quantum migration plan

00:45:18 DataHoarder: 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

00:46:11 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

00:46:17 DataHoarder: specially when all people talk is about "CEX and Merchants"

00:47:11 DataHoarder: 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

00:50:25 DataHoarder: also Jamtis/Quantum addressing scheme https://github.com/monero-project/research-lab/issues/151

00:50:51 DataHoarder: Carrot (with descriptions for carrot-native and legacy) https://github.com/jeffro256/carrot/blob/master/carrot.md

00:51:09 DataHoarder: current Post-Quantum Turnstile design for Carrot https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

00:57:04 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

00:57:04 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

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

00:58:10 DataHoarder: 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

00:58:20 DataHoarder: (and compile monero)

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

01:00:29 kiersten5821:matrix.org: in life ux is everything 🚬

01:06:39 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

01:07:44 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

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

01:10:40 DataHoarder: (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

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

01:11:32 Cindy: OVKs will solve the issue with view-only wallets having inflated balances

01:11:40 Cindy: without having to constantly export key images

01:11:55 jeffro256: If you do nothing besides update your Monero software, you will not have scary OVKs forced upon you

01:12:41 DataHoarder: ^ 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

01:13:40 DataHoarder: 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

01:14:59 DataHoarder: (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!)

01:15:02 kiersten5821:matrix.org: Cindy: so this will make the airgap sign process easier right?

01:15:13 DataHoarder: for legacy it's 2.1.1 conditional

01:15:15 Cindy: yes

01:15:24 kiersten5821:matrix.org: in the past it required like 3 back and forths or something it was terrible

01:15:42 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

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

01:16:46 DataHoarder: it eases this specially in offline conditions

01:17:05 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.

01:17:05 vamos881: hey guys. How can I get some stagenet monero?

01:17:20 DataHoarder: 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

01:17:26 jeffro256: Solution: don't be a surveillance cuck and give all your info

01:17:42 DataHoarder: vamos881: https://cypherfaucet.com/xmr-stagenet

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

01:17:59 DataHoarder: or ask Cindy for some

01:18:07 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

01:18:07 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

01:18:25 Cindy: vamos881: https://stagenet-faucet.xmr-tw.org/

01:18:28 DataHoarder: but the generate image kei is there due to cryptography

01:18:39 Cindy: oh looks like they put english translation now

01:18:45 DataHoarder: so it IS about cryptography

01:18:46 Cindy: i remember it being entirely chinese

01:18:57 Cindy: but yeah, put your address there, click send, it'll give you 1 XMR

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

01:21:32 Cindy: you could just mine on stagenet

01:21:41 Cindy: it is pretty doable to solomine

01:21:54 Cindy: because it doesn't have that much global hashrate

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

01:22:45 ravfx:xmr.mx: Can give then back eventually, just have to restore old seed

01:22:52 Cindy: on stagenet?

01:23:10 vamos881: DataHoarder, Cindy: thank you man

01:23:13 ravfx:xmr.mx: Yes.

01:23:18 torir:matrix.org: @yokoama:matrix.org: Which is stupid considering how traceable many MWEB transactions are. https://www.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.

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

01:23:59 Cindy: vamos881: it's hosting a private blockchain

01:24:14 vamos881: ok, then it's the same apparently

01:24:15 Cindy: basically one you create yourself, so you can mess around with it

01:24:43 kiersten5821:matrix.org: ./monerod --regtest --offline --fixed-difficulty 1

01:24:45 kiersten5821:matrix.org: use that

01:24:49 kiersten5821:matrix.org: and rpc generateblocks command

01:25:02 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.

01:25:50 vamos881: 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

01:26:01 jeffro256: I'm not dismissing the concern itself, but it has bad presumptions built into it.

01:26:50 jeffro256: Zero to Monero is excellent. Cryptography is a lot of how Monero works, what else are you looking for specifically?

01:27:35 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)

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

01:28:24 DataHoarder: Zero to Monero btw (will need an update after FCMP++/Carrot) https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf

01:28:58 jeffro256: vamos881: Are you opposed to reading code?

01:29:53 jeffro256: vamos881: The Cuprate Monero book is a great resource for specific implementation details: https://monero-book.cuprate.org/

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

01:29:56 vamos881: br-m: to learn how things work? Yea

01:30:58 vamos881: thanks, this looks like a good one :)

01:31:12 DataHoarder: https://github.com/monero-oxide/monero-oxide/blob/main/monero-oxide/src/transaction.rs / https://git.gammaspectra.live/P2Pool/consensus/src/branch/master/monero/transaction

01:44:46 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.

01:44:46 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.

01:44:46 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

01:47:52 vamos881: excuse the n00b question: what is jeffro256?

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

01:48:14 DataHoarder: vamos881: br-m is a bridge, jeffro256 is on Matrix

01:48:29 vamos881: oh ok, I thought br-m was the person. Duh!

01:48:44 DataHoarder: you see it prefixes the user on matrix

01:48:57 jeffro256: vamos881: Oh my gosh what am I

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

01:50:35 DataHoarder[m]: https://mrelay.p2pool.observer/m/monero.social/tlimTmkdsBmZhGbPpcQSALeg.png (image.png)

01:50:41 DataHoarder[m]: That how it looks on the other side

01:50:44 vamos881: DataHoarder: what is your go code? Go is easier than rust for me

01:50:51 DataHoarder: I sent it as well

01:51:13 DataHoarder: it's what I use for go-p2pool, p2pool.observer and my block explorer on https://blocks.p2pool.observer/

01:51:49 vamos881: the git.gammaspectra is giving me http 403 for some reason.

01:51:51 vamos881: nice, will check

01:52:30 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 https://mrelay.p2pool.observer/e/jrrp4t8KZzZ2bEtv ]

01:52:44 DataHoarder: 403? might be blocked due to coming from a range abused by AI scrapers

01:52:59 DataHoarder: you can just $ git clone https://git.gammaspectra.live/P2Pool/consensus.git

01:53:02 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

01:53:04 DataHoarder: and that will work

01:53:40 vamos881: not really, it's the same host. I'll try vpn later

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

01:55:55 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 https://mrelay.p2pool.observer/e/v_T14t8KQmNRLXhR ]

02:06:56 DataHoarder: yeah vamos881 it is Zenlayer

02:07:33 DataHoarder: that's where I get a couple TiB of abuse so that was explicitly dropped

02:23:09 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 https://mrelay.p2pool.observer/e/t8TZ498KZ01uSVQ3 ]

02:23:09 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 https://mrelay.p2pool.observer/e/t8TZ498KZ01uSVQ3 ]

02:23:15 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 https://mrelay.p2pool.observer/e/4oTa498KbXQ5Q0x1 ]

02:29:01 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.

02:29:01 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.

02:29:01 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.

02:29:35 just_another_day:matrix.org: There is no such tool in most wallets

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

02:29:54 jeffro256: @just_another_day:matrix.org: There is in the CLI and GUI wallet

02:30:11 just_another_day:matrix.org: Yes, but I didn't find it in Cake

02:30:13 vamos881: 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)]]

02:30:41 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

02:31:00 jeffro256: Wrap it up, the permisionless blockchain is dead

02:32:00 jeffro256: "Mandatory privacy" doesn't exist, it never has, and cannot exist while humans still retain free will.

02:32:05 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

02:32:05 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

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

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

02:33:48 kiersten5821:matrix.org: it will start from block 0

02:33:49 kiersten5821:matrix.org: and be entirely local

02:34:34 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

02:36:27 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

02:36:38 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.

02:36:44 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

02:37:17 jeffro256: So you will still be on the hook for providing that information

02:37:47 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

02:38:50 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

02:39:17 DataHoarder: ^ and even further if you self-send in carrot, even against quantum opponents

02:39:34 tuw:matrix.org: understood thanks.

02:40:02 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

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

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

02:48:31 vamos881: I missed your early message too, I was still confused about br-m being a person

02:49:50 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

02:54:31 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.

02:54:31 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.

02:56:09 nioc: is it what they ideally want? are you sure that it isn't something else?

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

02:58:03 DataHoarder: (besides the usability a generate image key brings for safe usage of monero)

02:59:50 DataHoarder: 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 )

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

03:00:04 kayabanerve:matrix.org: No one should be able to see how much you have: not even you.

03:00:19 DataHoarder: spending is harmful too

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

03:01:14 kayabanerve:matrix.org: /s if it wasn't obvious

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

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

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

03:03:28 DataHoarder: even spend keys

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

03:04:05 DataHoarder: then again, regulators will assume you are non-complying

03:04:06 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.

03:04:06 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.

03:04:07 kayabanerve:matrix.org: Thank you.

03:04:31 kayabanerve:matrix.org: Mhm

03:04:39 DataHoarder: a note kayabanerve these will probably be used by the impostor ^ to copy paste elsewhere

03:04:47 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.

03:04:54 DataHoarder: and context is lost

03:04:56 DataHoarder: they did that during the qubic ordeal

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

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

03:05:38 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.

03:06:11 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.

03:07:25 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.

03:07:25 kayabanerve:matrix.org: Not that they can't disclose their outgoing view key at all.

03:11:46 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!

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

03:12:57 DataHoarder: remember a single self-spend using new carrot wallet breaks this link

03:13:32 DataHoarder: (under FCMP++)

03:13:39 just_another_day:matrix.org: And creating a new wallet is literally optional privacy

03:14:01 DataHoarder: you have extended this too further, I think

03:15:54 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

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

03:25:10 ravfx:xmr.mx: Just don't share the keys

03:25:10 ravfx:xmr.mx: mkay?

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

03:27:35 just_another_day:matrix.org: @ravfx:xmr.mx: I responded to this idea just a few messages above

03:29:44 just_another_day:matrix.org: I'm just explaining the concern btw; a solution is the next step

03:30:11 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.

03:30:19 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 :')

03:30:57 DataHoarder: what solution? sending monero back to quantum unsafe/non migration protocol?

03:31:19 just_another_day:matrix.org: Keeping OVKs as a cli-only feature for power users

03:33:46 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

03:37:41 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 https://mrelay.p2pool.observer/e/vc3q5d8KUjZRcXQ4 ]

03:37:41 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.

03:37:56 preland: (Sry for the delay on writing that; my internet currently sucks lol)

03:38:29 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 :)

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

03:40:15 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.

03:42:57 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.

03:42:57 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.

03:43:00 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

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

03:44:32 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.

03:45:18 preland: I may not personally agree with removing view keys outright, but I can definitely see the rational issues with them.

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

03:48:16 kiersten5821:matrix.org: vamos881: just connect them all to your daemon

03:48:18 kiersten5821:matrix.org: it will work

03:48:29 kiersten5821:matrix.org: connect cake to your offline daemon

03:57:01 sgp_: Forced hodl > <DataHoarder> spending is harmful too

03:58:15 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?

04:09:04 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 https://mrelay.p2pool.observer/e/s8jd5t8KNTVubDJK ]

04:10:24 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"

04:15:17 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

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

04:17:45 kiersten5821:matrix.org: i want a risc v computer with a gazillion threads

04:23:51 321bob321: For Minecraft ?

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

04:29:49 sgp_: Sorry for being blunt, but the idea of removing view keys for "safety" is just..... ugh

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

04:43:23 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!

04:43:23 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 https://mrelay.p2pool.observer/e/kZrb598KclRzZ2l3 ]

04:44:04 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!

04:44:41 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

04:45:39 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.

04:49:12 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

04:49:12 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?)

04:49:29 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 https://mrelay.p2pool.observer/e/mLzx598KZ1lPeDZX ]

04:49:29 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.

04:50:52 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.

04:50:52 preland: I don’t want that to happen.

04:51:43 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.

04:51:44 preland: I also don’t want that to happen.

04:54:07 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)

04:54:34 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 https://mrelay.p2pool.observer/e/m5WE6N8KNzdJTGNs ]

04:55:56 kiersten5821:matrix.org: https://mrelay.p2pool.observer/m/matrix.org/oLnpQsvMZlTgDZBIjqGbCVFY.png (image.png)

04:55:58 kiersten5821:matrix.org: imagine running a server on this

04:56:08 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

04:56:11 kiersten5821:matrix.org: only 2.5 kw

05:06:07 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

05:06:25 jeffro256: no

05:08:41 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.

05:24:24 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).

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

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

05:27:11 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++)

05:28:50 jeffro256: @kayabanerve:matrix.org: Truuuu

05:30:48 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).

05:31:07 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).

05:42:34 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

05:46:55 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

05:53:15 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.

06:03:37 DataHoarder: also - generate image keys only allow you to check which outputs have been spent

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

06:04:11 DataHoarder: Which is available already and later on

06:04:14 kiersten5821:matrix.org: @kayabanerve:matrix.org: https://www.coindesk.com/policy/2025/04/29/tornado-cash-can-t-be-sanctioned-again-texas-judge-rules

06:04:14 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.

06:04:36 DataHoarder: Change outputs, after all, are incoming transfers

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

06:05:53 DataHoarder: 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)

06:06:41 DataHoarder: For example, one input, two outputs https://blocks.p2pool.observer/tx/2ddfc5aa9b5de01dd5808d9408793e42429f241a00a8ef64d6a8dfa722a15e7f

06:08:03 DataHoarder: 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)

06:08:38 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

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

06:16:57 kiersten5821:matrix.org: @jeffro256: https://mrelay.p2pool.observer/m/matrix.org/MSDmnogBVudkdxPjVmonkYrV.png (image.png)

06:17:35 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

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

07:13:52 pyratevevo:matrix.org: @just_another_day:matrix.org : remove seed phrases !!

07:48:20 munching:unredacted.org: hello i woman. someone send me 0,4 xmr thanks. i woman

07:48:29 munching:unredacted.org: shopping shopping shopping

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

07:50:00 BlueyHealer: moberator?

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

08:02:29 munching:unredacted.org: BlueyHealer: it’s a joke

08:16:46 jeffro256: @kiersten5821:matrix.org: ewww. TIL

10:08:35 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: https://github.com/lalanza808/lwsadmin

14:07:08 xmr_guyy: 🇨🇿 Czech President signed a law removing capital gains tax on Bitcoin after 3+ years of HODLing

14:07:22 xmr_guyy: what about Monero XMR?

14:13:52 Cindy: xmr_guyy: EU 2027

14:15:24 xmr_guyy: hodling where... in a centralized exchange, in a cold wallet or hardwallet?

14:16:23 xmr_guyy: in a hot wallet such as cake wallet...

14:17:16 elongated:matrix.org: xmr_guyy: Doesnt exist

14:18:28 Cindy: yes

14:18:38 Cindy: centralized exchanges for monero don't exist anymore in EU

14:18:58 Cindy: they rolled out new regulation, and they're about to enforce it in 2027

14:20:07 xmr_guyy: 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.

14:20:42 xmr_guyy: bitcoin and other crypto assets only

14:21:12 Cindy: https://en.wikipedia.org/wiki/2025_Czech_government_Bitcoin_scandal

14:21:32 xmr_guyy: thanks a bunch, cindy

14:22:50 Cindy: they did it to cover their asses

14:23:11 Cindy: because they received a massive donation (in bitcoin) from some former darknet market owner

14:24:13 xmr_guyy: disgusting corrupt politicians

14:24:16 Cindy: "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"

14:25:02 Cindy: hey, at least he got away with it

14:25:36 xmr_guyy: A law made to benefit these corrupt politicians and mag

14:26:47 xmr_guyy: mafia politicians

14:32:45 Cindy: a big coincidence that all this happened in may, and that law exempting capital gains tax on Bitcoin happened in february

14:33:18 Cindy: 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

14:35:10 yokoama:matrix.org: we love paying tax so much

14:36:51 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 https://mrelay.p2pool.observer/e/zrrY-N8KQ0YyYUlO ]

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

14:40:59 cranial_luminance:matrix.org: @yokoama:matrix.org: lets assume the government and assume i got it from a CEX

14:41:50 Cindy: multiple different addresses as in subaddresses?

14:42:08 Cindy: or just different addresses in accounts

14:42:11 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?

14:42:11 ofrnxmr:xmr.mx: No

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

14:43:24 cranial_luminance:matrix.org: Cindy: Cindy: both

14:44:56 yokoama:matrix.org: shuffle each output, churn them, never merge them in a single tx

14:51:34 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?

14:55:20 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"?

14:56:23 elongated:matrix.org: @cranial_luminance:matrix.org: Coin control

15:07:11 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)

15:07:40 ofrnxmr:xmr.mx: its "like" having multiple wallets

15:07:57 vamos881: 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?

15:09:12 vamos881: do I need to specify on .conf which network I want those settings applied to?

15:10:11 ofrnxmr:xmr.mx: vamos881: You cant have incoming connections while routing to tor

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

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

15:11:45 ofrnxmr:xmr.mx: .. when in doubt, just use --config-file=~/.bitmonero/bitmonero.conf

15:12:02 ofrnxmr:xmr.mx: vamos881: Cuz it uses onipn services for p2p

15:16:19 vamos881: 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)

15:17:09 ofrnxmr:xmr.mx: what does "i have a ban list" mean

15:18:17 vamos881: ban-list arg

15:21:08 ofrnxmr:xmr.mx: And its not loading it?

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

15:33:28 ofrnxmr:xmr.mx: I'll still forever use --config-file

16:05:27 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

16:05:32 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

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

16:06:51 DataHoarder: current view outgoing keys already disclose spends

16:06:57 DataHoarder: they just don't list the amount

16:08:05 just_another_day:matrix.org: how?

16:08:21 ofrnxmr:xmr.mx: You get change when you spend

16:08:21 DataHoarder: because they know when change goes back to wallet, even when it's 0

16:08:30 DataHoarder: example https://blocks.p2pool.observer/tx/3341b52d308f26a02191b391476d99478927a61d0921de7156dad81230e9269f

16:08:48 just_another_day:matrix.org: it's a vulnerability

16:08:54 just_another_day:matrix.org: that will be fixed

16:09:02 DataHoarder: ?

16:09:02 ofrnxmr:xmr.mx: @just_another_day:matrix.org: ?

16:09:09 ofrnxmr:xmr.mx: Jinx

16:09:09 DataHoarder: no FCMP++/Carrot do not change this

16:09:15 just_another_day:matrix.org: a vulnerability can't justify making it impact a feature

16:09:24 DataHoarder: it's not about rings.

16:09:54 DataHoarder: 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

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

16:10:03 DataHoarder: without this, they can go back and make it transparent in the future

16:10:36 ofrnxmr:xmr.mx: @just_another_day:matrix.org: Thats for a churn

16:10:52 ofrnxmr:xmr.mx: Iiuc

16:11:21 nioc: https://mrelay.p2pool.observer/m/gohegan.uk/tIxkJWnZuzmIFmmRSFojQxsd.png

16:11:25 DataHoarder: yeah, internal sends are churns or change

16:11:37 nioc: https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

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

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

16:12:26 DataHoarder: but any entity could make a compliant wallet

16:12:56 DataHoarder: 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

16:13:27 DataHoarder: they did it for bitcoin already, wrapped bitcoin etc.

16:13:29 DataHoarder: wrapped monero on hyperliquid too

16:14:27 DataHoarder: nioc: they won't read even when linked

16:14:33 DataHoarder: also it's tbh deep cryptography even when explained well

16:15:31 nioc: So a great excuse to believe what you want to

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

16:17:10 DataHoarder: see how it amplifies to nonsense levels?

16:17:37 ofrnxmr:xmr.mx: DataHoarder: I dont see the problem

16:17:40 just_another_day:matrix.org: well there is an obvious gap in communication

16:17:55 ofrnxmr:xmr.mx: The more ridiculous the fud, the easier to dispell it

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

16:18:53 DataHoarder: 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

16:19:21 ofrnxmr:xmr.mx: i say: damage control is for politicians

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

16:20:08 DataHoarder: 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)

16:20:12 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

16:20:31 ofrnxmr:xmr.mx: The rest is just arguing with a fool and trying to win

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

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

16:21:58 DataHoarder: it wouldn't surprise me this is again yet another campaign helped with that

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

16:22:08 DataHoarder: like Cryptonote -> RandomX back then

16:22:22 DataHoarder: or Cryptonight* even

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

16:22:53 DataHoarder: 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

16:22:53 just_another_day:matrix.org: How do you distinguish a change output with a normal output someone else send you?

16:22:59 DataHoarder: they find the best timing

16:23:14 ofrnxmr:xmr.mx: DataHoarder: They reappeared a few days ago. All peaceful-like

16:23:25 DataHoarder: just_another_day:matrix.org: timing, and address index

16:23:55 DataHoarder: if it goes back to subaddress index 0 of the account, it's likely change

16:24:00 DataHoarder: if you get sent to non-zero subaddress index in the account, someone sent them to you

16:24:09 DataHoarder: oh, who was it ofrnxmr?

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

16:24:37 DataHoarder: that is not how it works, it'd also give you the same information

16:25:00 DataHoarder: like self-send change to 0 uses random

16:25:02 DataHoarder: and again makes it identifiable

16:25:05 DataHoarder: the way is to not use subaddresses, only use main address :')

16:25:10 DataHoarder: everything is 0,0 :P

16:25:42 just_another_day:matrix.org: can you send 0 change to a random address instead?

16:26:09 DataHoarder: some wallets do that, you can still identify normal change though

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

16:27:09 ofrnxmr:xmr.mx: @just_another_day:matrix.org: https://github.com/monero-project/monero/pull/10266

16:27:09 DataHoarder: it's sadly how the wallet works

16:27:12 DataHoarder: not view keys

16:27:14 just_another_day:matrix.org: so we again better fix this instead of using it as justification for OVKs

16:27:30 ofrnxmr:xmr.mx: Its not justification for ovk

16:27:38 DataHoarder: it is not justification wtf

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

16:27:42 DataHoarder: legacy wallets will continue having these

16:28:10 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

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

16:28:38 DataHoarder: ^ legacy wallets will continue having old behavior

16:28:57 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

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

16:29:42 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

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

16:30:14 ofrnxmr:xmr.mx: monero doesnt have a paper trail, with or without ovk

16:30:32 ofrnxmr:xmr.mx: You cant see where coins came from, or where they went to

16:30:36 DataHoarder: under FCMP++ you cannot have tainted coins or outputs correct

16:30:44 just_another_day:matrix.org: unless the sender also has shared ovk

16:31:06 DataHoarder: they can't tell where it comes from or do output tagging

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

16:31:58 ofrnxmr:xmr.mx: sender's change will have same txid as receivers incoming tx

16:32:04 DataHoarder: ^

16:32:06 DataHoarder: not even ovk

16:32:08 DataHoarder: you just need view incoming keys

16:32:11 DataHoarder: or, a reporting wallet with proofs

16:32:14 just_another_day:matrix.org: i see

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

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

16:32:41 DataHoarder: it also gives you full info on balances

16:32:43 DataHoarder: with just view incoming keys on both sides

16:33:11 DataHoarder: what do you mean leaks

16:33:13 DataHoarder: this is fixed under new carrot

16:33:14 just_another_day:matrix.org: Cindy: Carrot doesn't even require protocol changes, does it?

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

16:33:19 just_another_day:matrix.org: it's offchain thing

16:33:44 DataHoarder: change is an internal self-send and it requires that key hierarchy

16:33:46 DataHoarder: it requires them for a future quantum migration

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

16:34:16 DataHoarder: those outputs need to be sent to addresses generated that way to be eligible

16:34:16 Cindy: yes, but carrot solves the post-quantum stuff

16:34:20 DataHoarder: ^ yeah carrot can come anytime

16:34:30 Cindy: which i'd like to think is what they don't want :P

16:34:31 just_another_day:matrix.org: yeah so i'm not some evil agent trying to delay the hardfork

16:34:48 DataHoarder: including by someone else making a wallet

16:35:03 ofrnxmr:xmr.mx: Cindy: Some* post-quantum stuff. Monero still needs another hf to become post-quantum

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

16:35:21 DataHoarder: the change must be seen for the wallet to spend it

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

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

16:35:55 just_another_day:matrix.org: fair enough

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

16:37:18 DataHoarder: that gives you an exact amount

16:37:48 DataHoarder: for example, https://blocks.p2pool.observer/tx/8898ea6e1f5bbee5b13887c2df317d5bd6487000278900e0b516252b6a1d75b4

16:37:50 DataHoarder: a tx that Monero GF donated to Monero CCS fund

16:37:52 DataHoarder: we have auditing view incoming keys for both

16:38:51 DataHoarder: 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

16:39:21 DataHoarder: that allows finding the sender, and the recipient, even if subaddresses were entirely randomized

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

16:40:50 just_another_day:matrix.org: reporting proofs is interactive

16:41:04 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, https://blocks.p2pool.observer/tx/8898ea6e1f5bbee5b13887c2df317d5bd6487000278900e0b516252b6a1d75b4

16:41:16 DataHoarder: a cex could force you to use such wallet

16:41:42 ofrnxmr:xmr.mx: @johnjenkinss:unredacted.org: Generalfund sent a donation to ccs

16:41:44 DataHoarder: also https://www.getmonero.org/resources/moneropedia/viewkey.html > Thus, Monero is said to be "private, optionally transparent".

16:41:47 DataHoarder: in comparison with transparent, optionally private

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

16:42:22 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

16:42:47 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

16:42:47 DataHoarder: in this case GF sent 32.44 XMR to CCS, and the change from the two inputs went back to GF

16:42:52 ofrnxmr:xmr.mx: Fud: OVK enables this

16:42:52 ofrnxmr:xmr.mx: fact: this is already a thing for cirrent view keys

16:42:56 Cindy: incoming keys are useful for verifying if funds have been received

16:43:03 Cindy: but not for verifying the balance

16:43:05 Cindy: without key images

16:43:19 DataHoarder: 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

16:43:48 DataHoarder: so the next step is to get rid of seed words and users viewing their own wallets entirely

16:44:01 just_another_day:matrix.org: that's not how it works.. non-KYC dexes aren't prohibited

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

16:44:14 Cindy: ^

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

16:44:16 Cindy: exactly

16:44:18 DataHoarder: ^ and will keep being a thing post FCMP++/Carrot

16:44:20 DataHoarder: even on legacy wallets

16:44:22 DataHoarder: migrating fixes this for change/self-send

16:44:25 hooftly:matrix.org: why would a dex ask for anything?

16:44:45 Cindy: i'd like to show you my mainnet wallet

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

16:44:49 Cindy: which has 2 million XMR

16:44:52 DataHoarder: just_another_day:matrix.org: then use those lol

16:44:55 Cindy: i'll give you the view key

16:44:58 Cindy: :P

16:45:07 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

16:45:23 DataHoarder: again it'll self regulate to users not providing KYC or not providing other information like their wallet spend keys

16:45:25 DataHoarder: or forced to used some "centralized" wallet

16:45:27 DataHoarder: like BSV chain with all the tokens

16:45:39 hooftly:matrix.org: @ofrnxmr:xmr.mx: all users keys or the validators?

16:45:57 DataHoarder: with "bridges"

16:45:59 DataHoarder: or solana, or anything that has a bridge that is cheap

16:46:02 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

16:46:04 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

16:46:14 Cindy: DataHoarder: or some wrapped token where they don't hold the underlying XMR

16:46:17 ofrnxmr:xmr.mx: @hooftly:matrix.org: No clue

16:46:58 DataHoarder: just_another_day:matrix.org, remember this is not possible if other users exist

16:47:00 DataHoarder: they can send between users and that breaks any chain

16:47:04 hooftly:matrix.org: @ofrnxmr:xmr.mx: But these are never visible on chain right?

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

16:47:51 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

16:48:22 hooftly:matrix.org: awesome!

16:48:36 Cindy: it's super easy to make a wallet for CEX

16:48:46 Cindy: do whatever bullshit they want you to do (even give your OVK)

16:48:51 Cindy: and then sweep all to another wallet

16:49:19 hooftly:matrix.org: In the end this is a non existent issue

16:49:31 Cindy: yes

16:49:52 DataHoarder: hahaha they are already mixing sgp's fud along with it

16:49:56 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

16:50:08 Cindy: no

16:50:17 just_another_day:matrix.org: the naxo fud?

16:50:24 Cindy: even if they flag your funds, what are they gonna do

16:50:33 Cindy: they're not gonna magically rip the monero from a view-only wallet

16:50:52 just_another_day:matrix.org: make your monero unspendable

16:50:53 DataHoarder: yep, naxo

16:51:02 Cindy: make my monero unspendable how

16:51:05 hooftly:matrix.org: Dont use a cex

16:51:07 Cindy: stealth addresses make that impossible

16:51:10 just_another_day:matrix.org: he's evil money launder, don't accept his monero!!

16:51:23 Cindy: who

16:51:23 DataHoarder: ^

16:51:25 DataHoarder: they will prohibit you from interacting with them again

16:51:27 hooftly:matrix.org: Dont use a CEX

16:51:27 DataHoarder: you can send to new wallet

16:51:38 just_another_day:matrix.org: it's about merchants too

16:51:41 Cindy: DataHoarder: yes

16:51:48 Cindy: just_another_day: merchants don't know the difference

16:51:52 Cindy: because of stealth addresses

16:51:57 Cindy: they won't know where the XMR came from

16:51:58 DataHoarder: how do you expect new users to onboard

16:52:12 just_another_day:matrix.org: from a cex

16:52:22 Cindy: how do you know that

16:52:23 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

16:52:28 DataHoarder: how do you expect merchants to onboard new users

16:52:30 DataHoarder: say a random comes and buys x

16:52:32 DataHoarder: shares their spend keys even, let's make it simple

16:53:00 DataHoarder: we are sharing spend keys now

16:53:02 DataHoarder: ok how does a cex identify a new user

16:53:23 Cindy: are you sharing your keys with everyone?

16:53:31 DataHoarder: they come with their full spend keys

16:53:33 DataHoarder: and ... now what

16:53:33 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

16:53:35 DataHoarder: they can tx?

16:54:31 DataHoarder: so that means everyone is flagged automatically

16:54:33 DataHoarder: remember you can't control who sends to you either

16:54:34 Cindy: that's pretty much doable with incoming view keys alone

16:54:48 Cindy: ^ (referring to DataHoarder)

16:55:05 just_another_day:matrix.org: that's true

16:55:31 Cindy: also you can't look at the source of the XMR

16:55:32 DataHoarder: yes Cindy

16:55:34 DataHoarder: but let's assume

16:55:36 DataHoarder: spend keys

16:55:36 Cindy: so like

16:55:40 DataHoarder: maximum view

16:56:08 DataHoarder: or even paper wallets

16:56:10 DataHoarder: let's make it simple to argue about

16:56:12 DataHoarder: yeah, even with spend keys you can't

16:56:42 DataHoarder: UNLESS it is mined as solomine or p2pool

16:56:44 DataHoarder: if it's mined via centralized pool -> can't

16:57:09 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

16:57:15 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

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

16:57:50 Cindy: who are you gonna share your view keys with

16:57:59 elongated:matrix.org: You are still here spreading non sense ?

16:58:26 just_another_day:matrix.org: Better here than on Reddit, right?

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

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

16:59:37 DataHoarder: same as bitcoin

16:59:41 just_another_day:matrix.org: transparent = those who've shared OVK/spend key/whatever

17:00:25 DataHoarder: like, you can't know how the txs were received even if it's from elsewhere

17:00:27 DataHoarder: so why is this not done now then?

17:00:56 DataHoarder: when they have the same if not better tools

17:01:14 just_another_day:matrix.org: you mean requiring everyone to share CryptoNote's view key?

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

17:01:56 DataHoarder: 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

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

17:05:27 nioc: just_another_day by being here and asking your questions and getting knowledgeable answers you can now go forth and fight the fud

17:05:42 DataHoarder: it is, as defined on the derivations on https://github.com/jeffro256/carrot/blob/master/carrot.md

17:05:44 DataHoarder: and for the PQ Turnstile https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

17:07:11 DataHoarder: 2.2.1 is the strong one > Internal forward secrecy

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

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

17:08:42 DataHoarder: 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)

17:08:46 DataHoarder: but 2.2.1 is what allows your own history to stay secret

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

17:09:45 DataHoarder: that is the linked gist

17:10:43 DataHoarder: 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

17:11:14 DataHoarder: you can read the details on the gist, it is inspired on Switch Commitments https://eprint.iacr.org/2017/237.pdf

17:14:23 DataHoarder[m]: @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

17:14:23 DataHoarder[m]: https://mrelay.p2pool.observer/p/2raZ_d8KRFdDOVIz/1.txt (code snippet, 5 lines)

17:21:18 gan:skhron.org: I think that I lost some braincells after reading that

17:42:24 intr:unredacted.org: is the view key bullshit still going on...?

17:42:51 ravfx:xmr.mx: Look like

17:43:33 ravfx:xmr.mx: Can everyone just send me there FDE AES keys now?

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

17:45:52 intr:unredacted.org: are you serious...

17:46:00 intr:unredacted.org: they're AI generated

17:46:11 intr:unredacted.org: I fucking called it

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

17:47:20 intr:unredacted.org: I'm more of an iocaine enjoyer

18:07:06 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:

18:07:06 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

18:07:06 just_another_day:matrix.org: 2. OVKs are necessary for quantum migration

18:07:06 just_another_day:matrix.org: Is this right?

18:08:12 pw:xmr.mx: It's nothing new.

18:08:12 pw:xmr.mx: That is right.

18:23:31 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

18:24:01 DataHoarder: Basically not we want OVK -> let's bolt it to all quantum and forward secrecy stuff

18:24:03 DataHoarder: It's the other way around

18:24:33 DataHoarder: That is also why legacy wallets cannot obtain that internal forward secrecy

18:28:41 DataHoarder: Jamtis details also has interesting tiers https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024

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

18:29:51 DataHoarder: > It cannot see outgoing payments and received change.

18:29:59 just_another_day:matrix.org: DataHoarder: This tier is cool af. Sad that carrot doesn't include it

18:30:04 DataHoarder: Which is similar to new carrot tier of view incoming

18:30:13 DataHoarder: It can't due to design on current monero

18:30:37 DataHoarder: It'd require migration away or change address format

18:30:39 DataHoarder: And*

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

18:31:35 DataHoarder: 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

18:32:26 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

18:32:30 intr:unredacted.org: the jamtis addresses were comically long

18:32:32 DataHoarder: What you call OVK is "Full view only wallet" in Jamtis

18:32:44 DataHoarder: And they are getting longer of the new proposals

18:32:48 hooftly:matrix.org: Lol

18:33:00 intr:unredacted.org: which new proposals

18:33:04 DataHoarder: The split necessarily creates that OVK or a similar one

18:33:14 DataHoarder: It's about splitting the image generation/validation from spend keys

18:33:35 just_another_day:matrix.org: I see

18:33:37 DataHoarder: So you don't need to disclose spend keys (used in signing) when migrating or transacting

18:34:13 DataHoarder: This new one https://github.com/monero-project/research-lab/issues/151

18:34:21 DataHoarder: intr^

18:34:38 intr:unredacted.org: ty

18:35:15 intr:unredacted.org: wait, so jamtis is not off the table entirely?

18:35:42 DataHoarder: No

18:35:49 intr:unredacted.org: interesting

18:36:06 DataHoarder: Carrot cake in for FCMP++ as it'd ease the transition way quicker

18:36:10 DataHoarder: Jamtis and other research continues

18:36:20 DataHoarder: It's a bit complex

18:36:46 intr:unredacted.org: yeah, I'm also confused as to what happened to seraphis itself

18:36:48 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

18:36:49 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?

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

18:37:43 intr:unredacted.org: I see

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

18:39:03 DataHoarder: The specifics there escape me a bit as there's a few more factors that can change that

18:39:17 intr:unredacted.org: np

18:39:23 DataHoarder: If they don't have the full view (only view incoming) they can't see the internal change output

18:39:37 DataHoarder: I was answering just another day

18:40:03 intr:unredacted.org: oh

18:40:07 DataHoarder: In that case they just see a payment to the recipient if they know their address

18:40:21 DataHoarder: But not the other way back

18:40:50 DataHoarder: Ofc, this is assuming it's the new carrot and not legacy under carrot

18:41:17 DataHoarder: Legacy under carrot: yeah it can be obtained in certain cases

19:03:26 kowalabearhugs_: Monero gets a mention from a shadow library admin, https://bsky.app/profile/ednewtonrex.bsky.social/post/3mcyye3yl4s2d

19:09:35 hooftly:matrix.org: Lol wild

19:09:53 hooftly:matrix.org: Yaaaarrr

19:16:55 kiersten5821:matrix.org: 🏴‍☠️

19:22:43 gan:skhron.org: Information wants to be free

19:29:40 preland: https://mrelay.p2pool.observer/m/monero.social/CaoLqmUHSSnEEzECEMsTvJEt.jpeg (ima_b17f12d.jpeg)

19:29:46 preland: lol

19:37:38 DataHoarder: Also remember, that is not part of the hard fork even now

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

19:38:39 DataHoarder: It is an addressing scheme, which works for Carrot/Jamtis style outputs

19:39:30 ravfx:xmr.mx: @kowalabearhugs_: I wonder what payment method Nvidia used

20:28:41 DataHoarder: do I need to join that Discord accursed place for fud campaigns?

20:33:14 321bob321: Discord is only to share state secrets

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

20:37:42 just_another_day:matrix.org: What are OVKs good for? Besides quantum migration

20:38:22 pyratevevo:matrix.org: You still doing this bud ? Gotta respect the effort.

20:41:11 redsh4de:matrix.org: @just_another_day:matrix.org: Christ

20:41:11 redsh4de:matrix.org: 1. Makes DEXes easier to create, taking power away from CEXes

20:41:11 redsh4de:matrix.org: 2. Proper view-only wallets

20:41:11 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 https://mrelay.p2pool.observer/e/zdyOg-AKN0VmTl85 ]

20:41:45 just_another_day:matrix.org: Kyaba said Serai is good without OVKs

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

20:42:21 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

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

20:43:03 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

20:43:05 redsh4de:matrix.org: OVKs lower the technical skill barrier to make it happen

20:43:39 Cindy: just_another_day: OVKs allows for easier management of fundraisers

20:44:08 Cindy: like in kuno

20:45:35 Cindy: without OVKs, it would be super easy for someone to inflate the amount of XMR they got

20:45:41 Cindy: to make their fundraiser look big

20:45:54 plowsof: stop exposing me

20:46:01 kiersten5821:matrix.org: @kowalabearhugs_: RIP libgen

20:46:01 Cindy: and attract more people to take a look at it

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

20:46:45 Cindy: lol

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

20:47:06 redsh4de:matrix.org: Arguing against this is ridiculous

20:47:37 redsh4de:matrix.org: Missing the forest for the trees

20:47:55 Cindy: it's so easy to "boost" a fundraiser with self donations

20:48:04 Cindy: because of this flaw

20:48:22 Cindy: i hope kuno doesn't start asking for key images :P

20:48:33 kiersten5821:matrix.org: 🔑

20:48:51 kiersten5821:matrix.org: I still don't understand the view key controversy

20:49:08 Cindy: me neither

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

20:49:56 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

20:50:08 kiersten5821:matrix.org: did anyone answer my question list from 3 days ago?

20:50:11 redsh4de:matrix.org: Regulators already audit centralized registered entities

20:50:11 redsh4de:matrix.org: Changes nothing

20:50:57 redsh4de:matrix.org: @kiersten5821:matrix.org: Thats all it is

20:51:30 just_another_day:matrix.org: @redsh4de:matrix.org: they can't audit everyone, it's unscalable

20:51:40 just_another_day:matrix.org: unless you provide an easy way to do so

20:51:46 Cindy: also with OVK, it solves the issue of having to ask people to give key images to fix broken balances

20:51:55 redsh4de:matrix.org: It is not a easy way to do so

20:52:07 redsh4de:matrix.org: Because there are steps to it that add friction

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

20:52:35 redsh4de:matrix.org: This doomsday scenario does not scale in the first place

20:53:37 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

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

20:55:03 Cindy: it's unscalable because of the amount of wallets you have to scan

20:55:12 Cindy: for each transaction

20:55:20 redsh4de:matrix.org: That too

20:55:39 Cindy: the cost of scanning a single transaction increases the more wallets you have to account for

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

20:55:54 just_another_day:matrix.org: they're not running their surveillance on a nokia 😅

20:56:27 Cindy: i'm sure somebody will write a well-optimized version of the wallet scanner

20:56:36 Cindy: would be much much better on a GPU tbh

20:56:56 Cindy: but for now, that stuff is pretty hefty

20:57:15 Cindy: especially if you're scanning from genesis to the tip

21:01:38 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!

21:05:42 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.

21:06:27 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).

21:07:00 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.

21:08:39 intr:unredacted.org: it strikes me as less of a debate and more of concern trolling

21:10:24 plowsof: 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

21:10:24 plowsof: over this hardfork

21:11:24 plowsof: and censorship to hide the secret hardfork!

21:12:35 intr:unredacted.org: and the top-secret hard spoon

21:24:36 just_another_day:matrix.org: > makes selective disclosure easier

21:24:36 just_another_day:matrix.org: > that's what people don't like

21:26:45 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

21:26:47 kayabanerve:matrix.org: the horror

21:28:06 kayabanerve:matrix.org: "concern trolling" does seem the best summary to me

21:28:16 Cindy: just_another_day: are you really sure you want to combat FUD?

21:28:25 Cindy: or is it JUST ANOTHER DAY of going in circles with you

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

21:28:52 DataHoarder: it's the other way around

21:29:23 DataHoarder: as said. the ovk comes out from the way the keys are split for specifically keep your history forward secret

21:30:06 DataHoarder: 22:11:14 <@plowsof> over this hardfork

21:30:06 DataHoarder: it's not even a wallet hardfork

21:30:25 DataHoarder: the thing they are complaining about doesn't need a hardfork, it could come *today*

21:30:31 plowsof: 😭

21:30:35 hooftly:matrix.org: https://mrelay.p2pool.observer/m/matrix.org/XRhIJNCdUXJqaoxPrCefAKwJ.jpg (1000008405.jpg)

21:30:52 DataHoarder: just haven't bothered to do new carrot on current outputs

21:31:31 Cindy: you guys are wasting your time over someone who will never actually change their mind

21:31:46 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 🤓

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

21:32:22 Cindy: kayabanerve: how do you become this smart

21:32:47 DataHoarder: but it's not cryptography, cause I feel like it's not kayabanerve

21:32:49 DataHoarder: :P

21:33:01 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 😏

21:33:30 Cindy: is this apart of the monero generators lore?

21:33:39 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™

21:34:04 plowsof: the reddit threads are titled "Say no to the hardfork" 😆

21:34:10 kayabanerve:matrix.org: The idea naturally extended from there to also messing with the addresses themselves

21:34:44 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

21:34:51 kayabanerve:matrix.org: yayyyy personal choice and liberty

21:34:59 DataHoarder: plowsof: but it's not even there yet lol, wallet code

21:35:10 Cindy: we will split the chain!

21:35:16 Cindy: we will mine our own chain with its own consenus

21:35:17 DataHoarder: carrot could literally exist today

21:35:28 DataHoarder: just need to move one thing to tx extra :P

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

21:35:55 kayabanerve:matrix.org: Or, properly educate yourself with the widely available literature available in this modern age

21:35:56 Cindy: ah well that makes sense

21:36:03 plowsof: 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

21:36:26 DataHoarder: what is coming is a change in tx output format

21:36:41 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

21:36:54 DataHoarder: which by convention legacy wallets and new carrot and maybe jamtis can share

21:36:59 kayabanerve:matrix.org: I'm an informal cryptographer/cryptographic engineer IMO

21:37:18 Cindy: soooo.. term for person who just messes with math?

21:37:34 kayabanerve:matrix.org: Yes but I get results :D

21:37:49 kayabanerve:matrix.org: *sometimes. People hear more about my successes than my failures :p

21:38:16 kayabanerve:matrix.org: My early years were messing around _without_ accomplishment.

21:38:21 DataHoarder: the wallet could be something else, just won't be compatible on other software

21:39:09 Cindy: i'm not much of a cryptographer either

21:39:23 Cindy: i don't think i'm allowed to call myself that :P

21:40:38 Cindy: all i do is mess with the code a little

21:41:27 DataHoarder: 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

21:42:31 DataHoarder: 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 **

21:43:20 plowsof: 👍

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

21:43:30 Cindy: i for one, will run the newest version of monero

21:43:35 Cindy: cuz i agree with the decisions

21:43:46 Cindy: others can go split the chain or something

21:44:00 DataHoarder: also fun. the hardfork can release anytime and not have to wait for Carrot addressing mode

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

21:45:17 DataHoarder: 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

21:45:48 DataHoarder: but yeah, I guess I understand this cause I reimplemented these things

21:46:40 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

21:46:48 DataHoarder: and ran stuff on stressnet

21:46:55 kiersten5821:matrix.org: this will make airgap management so much easier right?

21:46:56 DataHoarder: the hardfork does not even do that as well

21:47:20 DataHoarder: it's new wallet addressing mode that doesn't necessarily need a hardfork per se

21:47:30 Cindy: yes, it'll make it so much easier

21:47:32 DataHoarder: except for some other features around quantum safety

21:47:37 Cindy: because you don't have to have the spend key to look for outgoing TXs

21:48:33 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

21:48:59 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

21:49:03 kiersten5821:matrix.org: and still have to send it some data

21:49:30 DataHoarder: yes, but now it's even easier too ^

21:49:37 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?

21:49:39 DataHoarder: as FCMP++ signatures can be made without decoys

21:49:58 DataHoarder: that can be filled later by an online view wallet

21:50:05 DataHoarder: (the membership proof)

21:50:17 intr:unredacted.org: insanely cool stuff

21:50:25 kiersten5821:matrix.org: so you could actually initiate the tx from the cold side?

21:53:52 kayabanerve:matrix.org: If it knows its UTXO set, yes

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

21:58:44 just_another_day:matrix.org: i can't help with that

21:59:17 Cindy: "easier selective disclosure" already exists :P

21:59:24 Cindy: spend proofs, TX proofs

21:59:37 hooftly:matrix.org: Nonsensical

21:59:43 just_another_day:matrix.org: easier than what?

22:00:41 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

22:00:58 intr:unredacted.org: please not again

22:01:04 intr:unredacted.org: I am going positively insane

22:01:06 just_another_day:matrix.org: my theory is that blockchain surveillance really wants this feature in Monero

22:01:19 just_another_day:matrix.org: so devs pretend it's not a problem

22:01:36 hooftly:matrix.org: Oh so its even dumber

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

22:02:43 just_another_day:matrix.org: yeah like.. even the same people pushed that

22:02:57 hooftly:matrix.org: @intr:unredacted.org: Good job...

22:03:03 hooftly:matrix.org: Haha

22:03:05 intr:unredacted.org: lmao, sorry

22:05:40 Cindy: i love when people complain about a nothingburger for the 1000th

22:05:43 Cindy: fucking time

22:06:04 Cindy: blockchain surveillance companies can already tell you sent someone a TX with just the incoming view keys

22:06:26 Cindy: and when they see that, they'll ask you for keys related to that TX

22:06:50 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

22:07:05 kayabanerve:matrix.org: wooooo McCarthyism, alive and well 😎

22:07:17 intr:unredacted.org: forget I said anything

22:07:42 Cindy: kayabanerve: this definitely sounds like mccarthyism

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

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

22:08:33 Cindy: or chainlysis et al.

22:08:41 kayabanerve:matrix.org: (to make consensual disclosure as annoying as possible)

22:09:42 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)

22:09:44 Cindy: i like how nobody talked about why view keys existed in the first place

22:10:03 Cindy: it's almost as if when it's already implemented, nobody actually cares

22:10:20 Cindy: it's just doom and gloom up until it gets implemented.. then people just shut up after a while

22:11:15 hooftly:matrix.org: Nope Feds

22:11:58 DataHoarder: 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

22:11:58 DataHoarder: it wasn't added, again

22:12:06 DataHoarder: it's a side effect, and something you can still do

22:12:24 DataHoarder: old wallet will STILL be able to do that

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

22:12:35 DataHoarder: why is it not done today then?

22:13:04 Cindy: yes, why is it not done now

22:13:32 Cindy: we can already tell if a TX was made by just looking for change outputs

22:14:05 DataHoarder: 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

22:14:51 DataHoarder: 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)

22:17:37 intr:unredacted.org: that is a very good point

22:18:28 Cindy: id rather want quantum adversaries to know all the TXes i made

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

22:19:07 Cindy: one can be done without you knowing, the one can't be done without you knowing

22:19:35 rrjo1zj8p7lhtl15lylp:matrix.org: “Legitimate users” don’t want convenience at the expense of privacy.

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

22:19:35 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 https://mrelay.p2pool.observer/e/0Pz2heAKMkFGTGhQ ]

22:20:40 DataHoarder: > Thus, Monero is said to be "private, optionally transparent".

22:20:52 DataHoarder: on monero front page since I remember

22:21:04 Cindy: monero is not "uncompromising privacy" whatsoever

22:21:05 DataHoarder: > If you want auditability, compliance hooks, or features that make institutional oversight more convenient

22:21:05 DataHoarder: and using features

22:21:11 Cindy: and also "not selective" is not true either

22:21:17 Cindy: TX proofs and spend proofs exist

22:21:19 Cindy: and are used

22:21:27 DataHoarder: suddenly your coins cannot be used in cold storage

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

22:22:16 ravfx:xmr.mx: non, that where you use view keys...

22:22:21 Cindy: yes

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

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

22:23:03 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

22:23:15 rrjo1zj8p7lhtl15lylp:matrix.org: “Optional transparency” has never meant “optimize disclosure.”

22:23:15 rrjo1zj8p7lhtl15lylp:matrix.org: TX proofs require conscious, per-use action. That friction is intentional.

22:23:16 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 https://mrelay.p2pool.observer/e/tcaEhuAKUXhhY1hQ ]

22:23:16 Cindy: DataHoarder: also btw, you should fix the text encoding for the plain text stuff

22:23:22 Cindy: it looks mojibake

22:23:26 DataHoarder: text encoding?

22:23:28 DataHoarder: it looks fine here

22:23:37 Cindy: "â€œOptional transparencyâ€"

22:23:55 Cindy: also GhostMaple, that is obvious AI writing

22:24:23 DataHoarder: that is so AI lol

22:24:27 DataHoarder: and they are no protocol changes that allow that

22:24:35 DataHoarder: the wallet stuff is already there ... if you check history here

22:24:57 DataHoarder: discussed ad infinitum

22:24:59 DataHoarder: giving the keys is also a choice

22:25:01 DataHoarder: Cindy: on which message, IRC?

22:25:07 DataHoarder: I see “ as " but curved

22:25:11 Cindy: DataHoarder: on the mrelay.p2pool.observer link

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

22:25:34 DataHoarder: https://irc.gammaspectra.live/4850060215e8c955/image.png

22:25:36 DataHoarder: yeah I guess

22:25:43 ravfx:xmr.mx: fud was successful btw

22:25:51 Cindy: okay well tor browser assumes some other text encoding

22:25:57 Cindy: thats why i get mojibake i guess

22:26:11 DataHoarder: yeah, still good point

22:26:51 Cindy: i can ignore the garbage characters :P

22:28:16 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?

22:28:26 Cindy: i'm glad you're not using AI now

22:28:30 Cindy: for one

22:28:37 ravfx:xmr.mx: @rrjo1zj8p7lhtl15lylp:matrix.org: It allow proper operation of systems

22:28:48 ravfx:xmr.mx: It already there, it's just more granular (so better)

22:28:52 yokoama:matrix.org: will 13 word mymonero seed work post fcmp++ ?

22:29:08 rrjo1zj8p7lhtl15lylp:matrix.org: what systems? why?

22:29:19 nioc: why do we need OVK? I only need a key to get in my house, not to leave it

22:29:25 ravfx:xmr.mx: @rrjo1zj8p7lhtl15lylp:matrix.org: Think you have an online store that accept monero

22:29:25 ravfx:xmr.mx: And instead of using view keys, you use your full wallet

22:29:26 DataHoarder: 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?

22:29:28 DataHoarder: it's not adding anything. it's not even part of a hardfork

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

22:29:41 DataHoarder: however, this makes the wallet internal history forward secret against quantum opponents

22:29:44 ravfx:xmr.mx: then he can just send all the fund to itself

22:30:00 DataHoarder: also allows migrating safely to a quantum system in the face of active quantum adversaries

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

22:30:06 DataHoarder: https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

22:30:09 DataHoarder: it's not an EXTRA key

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

22:30:24 Cindy: DataHoarder is explaining OVKs, while ravfx is explaining view keys in general

22:30:35 DataHoarder: it's a side effect of being able to achieve this security

22:30:41 DataHoarder: and splitting spend key into spend key, generate image key

22:31:01 nioc: <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

22:31:04 Cindy: nioc: for most people, you don't need the OVK

22:31:07 DataHoarder: that way quantum computers can't walk all they way up

22:31:22 Cindy: but OVK make it super easy for things like fully cold storage coins

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

22:31:35 DataHoarder: see also 2.2.1 point here https://github.com/jeffro256/carrot/blob/master/carrot.md#221-internal-forward-secrecy

22:31:38 DataHoarder: yes yokoama:matrix.org

22:31:39 Cindy: and fundraiser auditing

22:31:40 DataHoarder: and it'll use legacy features

22:32:10 DataHoarder: read on the carrot document, specially how quantum forward secrecy is achieved

22:32:22 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)

22:32:40 DataHoarder: > I'll try and do my homework before speaking anymore because I have no idea. Thanks

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

22:33:12 DataHoarder: 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

22:33:14 DataHoarder: it could happen today, or way after any hardfork that adds FCMP++

22:33:16 DataHoarder: or it could be some random dev that creates the wallet

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

22:33:30 Cindy: i want your keys

22:33:39 Cindy: can you give me your keys

22:33:45 DataHoarder: it doesn't need monero to support it

22:33:45 ravfx:xmr.mx: nioc: Just send me your FDE AES keys please

22:33:45 ravfx:xmr.mx: And you 42 words seed too

22:33:53 nioc: Cindy: I will check with Cat when she wakes up :)

22:34:03 Cindy: now you can't say nobody ever asked you :D

22:34:10 nioc: thx

22:36:07 Cindy: DataHoarder: i haven't seen FUD this massive since pubic

22:36:34 DataHoarder: RandomX :P

22:37:12 nioc: isn't RandomFud already gone?

22:37:33 DataHoarder: it's starting again

22:37:35 DataHoarder: bitmain was making the rounds for v2 changes

22:37:56 nioc: I saw them reach out some days ago

22:38:05 DataHoarder: and pushing anything that just makes v2 not happen in their fork is a win for them

22:39:07 nioc: the real fud is ram prices :(

22:39:07 Cindy: that makes sense

22:39:26 intr:unredacted.org: true, and ssd

22:39:35 Cindy: they're probably the ones planting the seed for FUD

22:39:58 Cindy: convincing people to not hard fork

22:40:00 rrjo1zj8p7lhtl15lylp:matrix.org: okay I'm a noob, what is FUD

22:40:10 Cindy: fear uncertainty doubt

22:40:20 intr:unredacted.org: fear uncertainty doubt

22:40:25 intr:unredacted.org: beat me to it

22:40:37 rrjo1zj8p7lhtl15lylp:matrix.org: thanks lol'

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

22:41:34 Cindy: corporations also like to use it :P

22:41:34 elongated:matrix.org: Cindy: No it’s fireice and gang

22:41:48 intr:unredacted.org: I haven't heard that name in a long time

22:41:53 rrjo1zj8p7lhtl15lylp:matrix.org: we sure are. That's why I'm here.

22:41:57 Cindy: microsoft famously uses it a lot

22:42:03 Cindy: or at least used it a lot back then

22:42:32 elongated:matrix.org: @intr:unredacted.org: He works for ztrash now and still sour

22:42:37 intr:unredacted.org: no way

22:42:50 elongated:matrix.org: @intr:unredacted.org: Check ztrash Reddit

22:43:17 intr:unredacted.org: > r/zcash has been banned from Reddit

22:43:46 intr:unredacted.org: oh it's r/zec

22:44:10 intr:unredacted.org: he's a mod lmao

22:44:14 intr:unredacted.org: can't make this up

22:44:41 intr:unredacted.org: even writes some sort of newspaper style blog

22:44:51 intr:unredacted.org: I've seen enough lmao

22:44:57 intr:unredacted.org: Where Are They Now ™

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

22:53:19 intr:unredacted.org: https://mrelay.p2pool.observer/m/unredacted.org/djBFABRtwIKzFRNJeHCpmyBq.png (clipboard.png)

22:53:26 intr:unredacted.org: > supertestnet

22:53:28 intr:unredacted.org: https://mrelay.p2pool.observer/m/unredacted.org/zBaLAhYeOleCpCoEEpqVkoNm.png (clipboard.png)

23:23:34 ofrnxmr:xmr.mx: I thought fireice wasnt stupid

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

23:24:34 intr:unredacted.org: @ofrnxmr:xmr.mx: I wonder what brought you to this conclusion

23:24:57 ofrnxmr:xmr.mx: He ran spynodes and performed other notable network attacks

23:25:19 ofrnxmr:xmr.mx: And iiuc, created his own blockchain (ryo)

23:26:30 intr:unredacted.org: I didn't know about the spy node thing

23:26:33 intr:unredacted.org: interesting

23:27:05 intr:unredacted.org: vaguely remember Ryo

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

23:28:55 ofrnxmr:xmr.mx: possible that he was even the one who added the high fee bug

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

23:30:30 intr:unredacted.org: supertestnet has got to be memeing

23:30:37 intr:unredacted.org: "is this your card" type stuff

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

23:40:58 kiersten5821:matrix.org: @ofrnxmr:xmr.mx: added?

23:41:08 kiersten5821:matrix.org: he made a pr that deliberately introduced that?

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

23:43:36 ofrnxmr:xmr.mx: Nodes tell wallets what the fee lvl is

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

23:45:04 plowsof:matrix.org: https://github.com/monero-project/monero/issues/8134

23:45:31 plowsof:matrix.org: this was the 3.x xmr tx fee 😬

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

23:47:18 ofrnxmr:xmr.mx: Not sure

23:47:27 Cindy: ofrnxmr: seriously? regardless of how high it is?

23:47:50 ofrnxmr:xmr.mx: @plowsof:matrix.org: Happemed more than once

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

23:48:00 Cindy: like 0.1 XMR

23:48:03 Cindy: or 0.2

23:48:07 ofrnxmr:xmr.mx: I recall there was one when the pool was able to refund it

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

23:49:15 Cindy: number one philosophy is take whatever the server gives you with salt

23:49:24 ofrnxmr:xmr.mx: Ofc, youre not going to succeed if the persons balance cant cover the fee

23:49:34 Cindy: i would have definitely put a sanity check limit on the fee

23:49:38 ofrnxmr:xmr.mx: And the asshole node doesnt get the $, since it goes to miners

23:49:53 Cindy: like if it went above 0.1 XMR, just go to another node

23:49:58 Cindy: or less than that

23:50:32 Cindy: 3.x xmr fee is insane

23:50:40 Cindy: that's like thousands of dollars in fees

23:51:03 Cindy: the client should crap out if it's even 5 dollars in fees

23:51:20 ofrnxmr:xmr.mx: Its thusands now

23:51:28 ofrnxmr:xmr.mx: It was like 600 at the time

23:52:49 Cindy: "And the asshole node doesnt get the $, since it goes to miners"

23:52:56 Cindy: so he just did it to troll monero users

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

23:53:18 ofrnxmr:xmr.mx: Exactly

23:53:35 ofrnxmr:xmr.mx: Something FUK would do

23:53:50 Cindy: does monero cap the fee amount?

23:53:54 Cindy: or mitigate this in any way now?

23:53:58 ofrnxmr:xmr.mx: No

23:53:59 Cindy: (the official monero wallet)

23:54:06 Cindy: no?

23:54:06 ofrnxmr:xmr.mx: You can pay any amount you want

23:54:20 Cindy: no i meant if it gets a very large fee from a RPC

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

23:54:26 Cindy: not by user choice

23:54:36 DataHoarder: there is a big warning

23:55:22 ofrnxmr:xmr.mx: https://github.com/monero-project/monero-gui/pull/3897

23:56:40 Cindy: i wonder if alternative monero clients even bother with this

23:56:53 Cindy: like cake wallet or feather

23:58:12 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

23:58:27 ofrnxmr:xmr.mx: And no-sync=true

23:59:25 ofrnxmr:xmr.mx: if you connected manually to a malicious node, thats probably a "you problem"

23:59:50 rrjo1zj8p7lhtl15lylp:matrix.org: I agree

23:59:51 ofrnxmr:xmr.mx: GUI connects to malocious nodes automatically :D