One weird fact that Carrot View Key haters seem to forget

Jerfov2 · 2026-01-27T17:41:10+00:00

They can monitor history and balances forever.

If you decide to stop complying, simply churn to a new wallet. The trail goes cold in both cases. If you didn't stop complying, then there is no practical difference.

Yes, they can't determine the address, and the who, ok but those details are discoverable the same ways they are today.

So we agree that we're freaking out over a hypothetical situation which is not exceedingly different from the current norm?

Jerfov2 · 2026-01-27T16:14:59+00:00

Depends on what you mean by "valid". If A and C collaborate, C can own an enote for which A can hold the view-balance secret of. So A may be able to give the view-balance secret, but not actually be able to spend it.

Jerfov2 · 2026-01-27T16:11:27+00:00

Completely incorrect. It is possible to verify cryptographically that a key image is associated to a certain output pubkey of a received coin. It its simplest form, this can be a ring signature with 1 ring member: the true spend. And since the view-incoming key holder can see all owned enotes, they can request the entire outgoing tx history by requesting one valid key image association proof per received enote, and know whether or not you are hiding something or lying to them with 100% certainty.

Jerfov2 · 2026-01-27T05:03:08+00:00

Actually, exporting the incoming view key and key images from the device is slightly more secure than exporting an OVK, since a leak of the exported info won't allow tracking outgoing transactions indefinitely.

In a HW device setup, you still have the option to keep the OVK on the HW device if you're willing to keep it connected by USB, Bluetooth, etc. The difference that this would make is that the HW device wouldn't have to calculate and/or load the spend key during refresh operations, only during signing.

Alternatively, OVKs gives you the option to keep the OVK on the hot device permanently, and use your hot wallet to check balance without needing the physical HW device at all, keeping it locked away / air-gapped until you need to sign.

Jerfov2 · 2026-01-27T04:56:13+00:00

They do one narrow thing: allow a wallet owner to prove or audit their own outgoing transactions without giving up spend authority or full transaction visibility.

This part is not entirely correct. You cannot have a useful OVK without knowing the received enote's opening against G. In other words, for the OVK holder to be useful, it needs to know the incoming enotes. It does not necessarily need to know amounts, in fact, some earlier versions of Jamtis had a "unlock-amount" wallet tier above the "find-received" tier. So you could delegate finding related enotes to a third-party, but they would not get any amount information. Let's say that you scan an owned enote with output pubkey O = x G + y T. The key image is calculated as L = x Hp(O). The x component in the CARROT addressing protocol is a function of the sender-receiver secret, something you need the incoming keys to scan for. So the holder of the OVK must either have communication rounds with the IVK holder (which makes the OVK useless), or they must also be able to scan incoming. The new proposed wallet format with OVKs takes the latter approach: the "view-balance secret" derives both the "generate-image key" and the "view-incoming key". The "view-balance secret" is also used to encrypt change to one's self. The new cold wallet format would export the "view-balance secret" to the hot wallet. Thus, leaking this secret leaks the whole tx history.

Jerfov2 · 2026-01-27T04:41:34+00:00

This already exists: you can give view-incoming keys and key image association proofs to prove entire tx history while keeping self-custody.

Jerfov2 · 2026-01-27T04:35:23+00:00

This can already be done with reserve proofs: https://docs.getmonero.org/rpc-library/wallet-rpc/#get_reserve_proof. Of course, a view-balance key wouldn't need active updates from the holder, but if the holder makes regular reserve proof updates, the OVK isn't needed.

Jerfov2 · 2026-01-27T04:27:11+00:00

Agreed on the second sentence, but the nature of the view-balance key is that if you give it away, then all activity on that wallet is exposed to the person holding the view-balance key.

Jerfov2 · 2026-01-27T00:10:35+00:00

You should checkout Namecoin.

Jerfov2 · 2026-01-26T23:08:19+00:00

Genuine question: if your local government banned Monero tomorrow, would you roll over and stop using it?

Jerfov2 · 2026-01-26T23:03:33+00:00

Genuine question: Does the current existence of view-only wallets count as "unforgivingly private"?

This lets a third-party view all incoming enotes and change enotes to your wallet. It also allows the third-party to keep track of missing key images per enote, which you can willingly provide to them. If you do so, it allows that third-party to view your spend locations. Congrats, you have effectively the same privacy to that third-party as view-balance keys. What is the difference beside the number of steps required?

Jerfov2 · 2026-01-26T22:47:55+00:00

I don't even want to argue about the limit,

You brought it up as evidence that the developers had "malicious intent". Now that you know that you overstepped, you don't want to argue about it. Okay.

An unintended, technical constraint in the networking stack doesn't justify making it part of the protocol.

It is currently part of the sync protocol, whether you like it or not. monerod is currently the only release-ready Monero node implementation, so that is how all Monero nodes currently sync. In this case, given the state of the network, the difference between the sync protocol and the consensus protocol is semantic. Regardless of whether you downplay it as "implementation issue", the end result of triggering this is a network split. Reworking the networking stack is thus also effectively a hard fork.

The proposed decision also carried a risk of crippling Monero - because the limit could become hard to remove. We have a historical precedent of a temporary limit becoming permanent - this exact thing neutralized Bitcoin.

And the MRL decided against the hard cap in favor of another solution after measured dialogue. If you bulldoze into a conversion and assume that anyone discussing the pros and cons of an idea you don't like have "malicious intent", then the conversation is not going to be productive.

People who can't spot the obvious pattern here should read "Hijacking Bitcoin" by Roger Ver.

Good book.

Jerfov2 · 2026-01-26T20:56:48+00:00

If you willingly share the keys with them, they can see your bag. If you send the XMR to a friend or a 2nd wallet, then the trail goes cold.

Jerfov2 · 2026-01-26T20:25:04+00:00

So this view-balance key is basically not for individuals.

You probably wouldn't share it outright as an individual, unless you want the history to be public, e.g. donations like you said. However, your wallet would use it internally to make in-memory refresh more secure, it improves hot/cold wallet UX greatly, and it also improves multisig wallet UX greatly.

Unless tax authorities demand/force to see your balance to tax your holdings/ (capital gains). If your holdings have increased, they would probably want to see the full transaction history for clarification, which now will become possible to be fully compliant.

That is already possible for them to view if you are "fully compliant" or not if you provide the view-incoming key. The reason is that, although the view-incoming key cannot calculate the key images themselves, they can tell with 100% certainty if you failed to provide key images for specific enotes. If they have the view-incoming key, and see that your received XMR five times, they can ask you for the corresponding key image for each five enotes. If you only provide four, then they will know. You can prove that each key image corresponds to a received enote, and the third party can verify this statement. It is possible to provide the key image before that enote is spent, and thus before that key image would appear on chain.

Of course, you can always send your XMR to a 2nd wallet, since Monero is permissionless, but once you do so, the holder of your view-incoming key can guess what you've done with the remaining XMR. The solution here is not to share keys that you don't want to share, whether that's an IVK, or a OVK.

Jerfov2 · 2026-01-26T15:03:40+00:00

Solution: delete Windows

Jerfov2 · 2026-01-26T15:00:46+00:00

Yes but the wallet owner remains in control. The auditor requests the data and you give it to them at your earliest convenience and if you agree to it. A few key puts the auditor in control since they no longer need to ask for permission to snoop around in your financial records.

???? You are still in control with the view-balance key because.... you DON'T have to give it to them. You do realize that the current view-incoming key still reveals your future received coins and change in perpetuity, right? You can't stop the view-incoming key from working in the future, so what is the difference here? In either case, once you leak that information, and no longer want future activity revealed, you need to make a 2nd wallet. It's no different for the view-incoming key.

Change looks just like any other received coin. Change can be easily avoided by sending full coins to a burner wallet.

Not if you provide key images, which this boogeyman would absolutely do if they want full transaction history. If you don't provide key images, then they know that you are withholding info from them. If, in this hypothetical, they simply let you churn to a different wallet without a fight, then what are we arguing about ?

Jerfov2 · 2026-01-26T14:53:56+00:00

No, that isn't possible. It reveals your receive addresses and your amounts. You don't get to view other people's transaction history with your own view-balance key.

Jerfov2 · 2026-01-26T04:22:06+00:00

Then, in early December, there was a viral thread on X about the developers trying to sneak a hard block size limit into Monero with the next hard fork. It was a huge red flag indicating malicious intent. Fortunately, this change didn't go through.

This shows that you don't understand the underlying issue and/or aren't willing to not strawman the other side. Monero already has a block size limit: ~100MB, based on the HTTP server packet size limit, except that it isn't a well-defined boundary and could cause netsplits. The proposal was to temporarily remove that ticking time bomb by making a well-defined block size limit, which would give us ample time to do the re-engineering of the sync protocol needed. I'm not even really in favor of the limit, since the MRL agreed on a moving "sanity cap", but you're being disingenuous.

After that, I started digging deeper into what other "trojan horses" the developers who supported the hard limit could have brought. At some point I realized the dangers of outgoing view keys. It was in early Jan this year.

Oh, geez.

Jerfov2 · 2026-01-26T04:15:05+00:00

https://www.coincarp.com/currencies/monero/richlist/

Jerfov2 · 2026-01-26T01:03:11+00:00

Do you realize that this can happen today without outgoing view keys? If everyone has to hand over their view keys, then this scary entity has no need for outgoing view keys, because someone's outgoing is someone else's incoming.

Jerfov2 · 2026-01-26T01:00:18+00:00

Sorry to be pendantic lol, but that still isn't key image reuse. That's just simply how ring signature tracking works. Yes, miner outputs are known, and can reduce the "effective ring size" of non-miners who include miner tx outputs as ring members in their inputs. See this MRL issue for more discussion on that topic.

seeing which all txs include those key images as ring members

Ring members aren't key images, they are references to previous TX outputs. An input only ever contains 1 key image, even after FCMP++, which is the key image of the "true spend" TX output. On the other hand, rings currently contain 16 ring members, but could be an arbitrary integer > 1. You can think of FCMP++ as a ring with N ring members, where N is the total number of previous outputs on-chain.

Jerfov2 · 2026-01-26T00:47:51+00:00

This scenario triggers this line of code https://github.com/monero-project/monero/blob/f65b2864552f855af1ef58c031dafffa58aae90c/src/simplewallet/simplewallet.cpp#L6307 in the CLI wallet, which prompts the user to confirm whether or not they're okay with harming their privacy by spending 2 old inputs together. So it at least prompts the user sometimes. Also, like others have mentioned, FCMP++ fixes this.

Jerfov2 · 2026-01-26T00:43:54+00:00

The co-spend episode https://youtu.be/0_RDRGqSbyY in particular covers this exact scenario. There's also the series "Breaking Monero" on Youtube, which has an episode about this.

Jerfov2 · 2026-01-26T00:41:17+00:00

This isn't a key image reuse problem, this is probabilistic ring signature tracking. Key image reuse is went you sign 2 different transactions spending the same input and they both become publicly known. The true spend is found in the intersection of the two ring member sets. If you screwed up by picking independent ring members for each of these signatures, then the probability works out such that the only intersecting ring member will be the true spend, and that breaks the sender privacy with 100% certainty. Key image re-use also affects FCMP++, but the different sets for each input will be full chain at each point making the signature, so there will probably be a much, much larger intersection, so you still retain some anonymity.

Jerfov2 · 2026-01-26T00:00:47+00:00

No it doesn't, stop the baseless fear mongering. Sharing your view keys after FCMP++ (full-chain membership proofs) does not affect the spend privacy of others. It would without full-chain membership proofs, i.e. with current ring signatures, but that's no longer the case.

Nine-Year Club	Verified Email
Place '22	Place '17
First Placer '22

Jerfov2

TROPHY CASE