11:15:06 naive question, but how is a view-only wallet currently able to tell that KIs are missing, ie that a change note has been created rather than a receiving enote? 11:49:29 maybe not naive/obvious.. 11:57:49 Not fully sure, but I would say the suspicious fact would be that among the inputs of the change transaction are enotes that the wallet holds, which would be quite some event if somebody unrelated just sent XMR into the wallet. 12:05:33 hm that would make it probabilistic. I rather think it's due to some index derivation for change notes. but that's just a guess 12:07:43 there's an explicit message in cli/gui that the balance might not be accurate because of KIs missing if I remember correctly 12:11:16 @rbrunner7: but if this is true, the "99% of outgoing transactions are detected already with IVKs" argument wouldn't hold anymore after FCP++ 12:13:55 *FCMP++ 12:29:09 Yes, sounds probable. But the CryptoNote style IVKs will likewise stop to exist with Carrot. 12:30:54 If you call that fact of possible detection of outgoing transactions with CryptoNote style IVKs an "argument", what would it be an argument for or against? 12:45:57 @rbrunner7: well, that's currently discussed isn't it? 12:46:11 I feel the entire "just don't KYC / share your viewkeys" argument will likely become out of reach, for any merchant above board accepting monero. 12:46:11 It's hypothetical, but more likely then not imho, virtually all above board merchants will be required to share viewkeys for auditing purposes. 12:46:11 Now, auditing capabilities doesn't seem to facilitate digital cash (UTXOs/enotes) but accounts 12:51:14 in short: with FCMP++, IVKs privacy can be improved 12:57:10 Well, with this we already left anything that is interesting for me to discuss further here. Let's see somebody else will bite. 13:02:08 🍲 just to stir the pot - salvium added carrot and uses it to claim to be MICA compliant 13:06:14 > Salvium One launch in 2025 required full CARROT addressing support to enable MiCA-compliant, auditable wallet histories, so CLSAG wasn’t an option. 13:06:14 https://x.com/i/status/2015846820069384293 https://xcancel.com/i/status/2015846820069384293 13:06:21 Did that claim already lead to anything tangible? 13:07:19 Idk, i just saw them tweet about it on one of the twitter threads 13:08:09 "already lead to" ... you think it's highly theoretical / hypothetical / unlikely that it won't in the future? I have a good track record in taking bets with you ;) 13:09:08 I was just trying to expand my knowledge. 13:09:37 sure, but you also dismissed my points completely 13:10:21 Oh no, that's a missunderstanding. Just a statement that I don't want to discuss those points further with you. Not the same. 13:10:39 ah okay. that's good to know 15:37:43 > so, for your example, you have given them viewkeys elsewhere so it seems you were the black sheep all along DataHoarder 15:39:22 It's true that my example requires additional information from outside of Monero blockchain. However, in my example, the fact that Bob has shared his full view key is key for BS to infer it was a btc -> xmr swap between me and Bob 15:39:56 > <@venture> naive question, but how is a view-only wallet currently able to tell that KIs are missing, ie that a change note has been created rather than a receiving enote? 15:39:56 @venture:monero.social: I hope I understand your question correctly. I will answer the first part. The reason is obvious. AFAIK, a view-only wallet knows that it doesn't have all key images of all received outputs (whether from an external wallet or a change "self-send") because it knows which outputs it received. "If I don't [... too long, see https://mrelay.p2pool.observer/e/1Na7yOEKX3pWOUZk ] 15:43:01 If a view-only wallet has the key image of the output that is spent on the blockchain, then it knows that the output has been spent, but not necessarily to whom, because it's on the blockchain now. Key images appear on the blockchain because it's Monero's anti-counterfeiting rule. 15:46:16 There is no plausible deniability that you have not spent the outputs if the view-only wallet has all they key images. The manager(s) of the Monero Core Team General Fund give a report on all spending, usually annually, and include the exported key images. The view key has been published, but to give full info about spends, they have to export the key images. 15:47:20 https://reddit.com/r/Monero/comments/1iixgk9/monero_general_fund_transparency_report_february/ 16:46:34 You could make the case that charitable donations is a top use case for cryptocurrency. Therefore, view keys are needed for transparency and accountability of charitable donations. 16:52:27 According to data from the EU, an online charitable donation had 9 times higher odds of being paid with cryptocurrency, compared to fiat. Page 65 of my https://github.com/Rucknium/presentations/blob/main/Rucknium-Monerotopia-2024-Banking-the-Unbanked.pdf https://vimeo.com/1029005523 16:55:50 (Some owned outputs have missing key images - export_outputs, import_outputs, export_key_images, and import_key_images needed) 16:55:50 ^ just tested it, you are right. The message appears for both, change incoming and normal incoming. and goes away when a key image with a higher height is imported 16:56:10 Thanks for testing :) 17:01:34 Even the original cryptnote whitepaper mentions the "tracking key" which allows for "an audit compatible address where all incoming transaction [sic] are 17:01:34 linkable" 17:04:31 I have to say, I do like the key image import, since it's only up to a certain point. Auditability remains possible without any plausible deniability with them. 17:04:32 The current IVKs (incoming view, not balance view key, like an employee shouldn't be able to see my spends) in combinations with ring signatures suffer from the fact that spends are easily identified 17:05:08 how do IVKs look like under CARROT? is that not a thing at all anymore then? 17:05:10 @venture: False sense of privacy? No one should assume any privacy for a wallet with a disclosed view key 17:05:23 @rucknium: I'm pointing out this mostly to brag about my own research instead of to deliberately argue for view keys by the way 😁 17:07:54 @sgp_: Depends of what the view key was advertised for. If the software tells me it's only to make incoming inputs transparent, I expect it to be the case. 17:07:59 Cant carrot keys be tiered so you can disclose partial history or am I wrong there? 17:08:21 There are three tiers but they aren't time bound 17:09:11 As is now, partial history is best disclosed by a separate wallet for what you want to disclose. That'll always be the case 17:09:41 I believe even with carrot you can still selectively export key images, right 17:09:43 Hot and cold wallet is still the most valid pattern yes 17:10:10 You can also disclose on a per tx basis like today 17:10:19 yep got it 17:10:47 also just to clarify, the Carrot incoming view key will not disclose change enotes, right? 17:12:00 so in other words they don't disclose spending activity 17:12:23 2.2.3 Payment validator tier 17:12:23 Carrot supports view-incoming-only wallets that can verify that an external payment was received into the wallet, without the ability to see where those payment enotes were spent, or spend it themselves. But unlike old Monero view-only wallets, a Carrot payment validator wallet cannot see "internal" change enotes. 17:13:13 perfect 17:13:54 well, sounds good 😅 17:13:54 As I said, above board merchants will imo very likely have to disclose something 17:14:26 simply dedicate a specific wallet to above board merchant activities 17:16:29 or account or subaddress.... i forget, do we still have all the craziness with main address and subaddress and accounts or ... well i could just find this probably 17:20:59 well, the view keys are wallet wide, so isolate merchant transactions to a dedicated wallet 17:21:46 @sgp_: section 5.3 doesn't differentiate between view keys though. 17:45:23 @venture: ? Are you looking for 5.4? 17:45:56 Or 5.2? 17:55:31 no, they describe internal access tiers and derivation hierarchy. Specifically exportable (public) keys. Not sure why it's named public. would probably better be named "shareable key". unless I'm misunderstanding 18:00:46 I guess it is 5.4. nevermind then 18:03:56 venture: you can detect it via the outputs, and see if they match likely change addresses indices. Also, if you don't import a key image for a known output you will get that message. 18:06:47 understood. And this won't be a thing anymore with CARROT's View-Received keys in combination with FCMP++, right? 18:08:57 ah well, the message remains without key images. just the balance won't inflate from change notes 18:10:43 Well. I was looking at how special notes were scanned in code and although you might not get details you can detect that "something happened" with high likelihood 18:10:48 Special = change or self sends 18:13:28 thanks 18:16:47 just_another_day: for your purposes you don't even need KI or OVK, the bitcoin part and the first step in monero you can skip 18:19:42 you already have said your same setup unchanged since first day, and besides the benefits it brings to general usage you also have the current PQ design. But that will be looked into: 18:19:42 https://mrelay.p2pool.observer/p/l-GEzeEKLTE0VHBy/1.txt (code snippet, 5 lines) 19:07:34 how on Earth one can argue that transacting with a transparent address doesn't leak any data, when it clearly does leak both the fact of the transaction and the XMR amount, is beyond me 19:07:52 but never mind. No one won't listen to me. I see other people asking appropriate questions, so I'll count on them 19:09:31 it's not a transparent address, again. 19:10:30 even when you share your spend key you can't tell the recipient or target, compared to usual transparent schemes 19:10:41 transparent = "BS sees incoming and outgoing transfers and their amount". I'm not assuming they see the source of the target 19:11:18 So not transparent address?? 19:11:59 non-transparent = you don't see anything, like usual Monero addresses 19:12:19 transparent addresses (besides seeing incoming/outgoing recipients or senders) also usually allow anyone. It's fun seeing the same terms as used in ZCash 19:13:24 This is why I'm going all the way and assuming what is being shared are spend keys, to make it obvious what it allows, and then see the BS opportunities there 19:13:43 you can make such an assumption 19:13:51 it doesn't change my reasoning 19:13:58 otherwise we get lost in semantics around what changes 19:14:59 even with spend keys, it's not transparent, but history of your own movements are auditable 19:15:32 > It's fun seeing the same terms as used in ZCash 19:15:32 > It's also fun that I use the similarities with ZCash as something negative 19:16:08 yes, but the similarities are wrong as it's doing something different there 19:16:21 that's why I am calling it out. it's not equivalent 19:17:16 > transparent = "BS sees incoming and outgoing transfers and their amounts". I'm not assuming they see the source or the target 19:17:16 > non-transparent = you don't see anything, like usual Monero addresses 19:17:16 What is your term for when people share their IVKs or OVKs then? Translucent? 19:17:44 > usually allow anyone 19:17:44 > ^ True. But from the perspective of BS, there is no difference between an address that is transparent for everyone and an address they have a view key for in their database for 19:18:50 @jeffro256: semi-transparent I guess? 19:21:13 @just_another_day:matrix.org: There absolutely is is if there is privacy by default in the protocol. Because with e.g. BTC, you can make the observation that money leaves this account, transferred to person X. Whereas, in Monero with OVKs, you can only tell that the money left the account. It could've gone to any user of the network, including themselves to a second wallet. 19:21:20 translucent, frosted glass :P 19:21:32 LIquid glass 19:22:22 > besides seeing incoming/outgoing recipients or senders 19:22:22 you see that either the recipient or the sender is also transparent (have shared their full view key) or is a non-transparent (anyone who hasn't shared their full view key), right? 19:23:20 Yes 19:23:27 see even this doesn't make the full tx transparent, you get to see selective outputs only within a direct hop. If there's any single hop in between, all connection is lost 19:25:20 @just_another_day:matrix.org: Same is true for view-incoming keys because of change outputs. 19:26:13 From my perspective, the addresses from the database are equivalent to transparent Ethereum addresses, while the default addresses are roughly equivalent to Tornado Cash deposits (with the additional capability of changing the ownership of the deposits and granular control over the amount) 19:26:48 then your perspective hasn't listened or looked into the specifics these past few days 19:27:15 okay 19:27:52 you are again making an equivalence that reaches too far 19:28:21 see it from this perspective: the spend keys (allow decoding all in all wallet tiers) don't give the user more information on others either 19:28:24 @jeffro256: If the entity taking keys has the view-incoming key for A and B, and A makes a transfer to B, or vice versa, both A and B will have view-scanned enotes in the same TX. Thus, the observer can make the inference that some XMR was transferred b/t A & B. And based on timing analysis and amount analysis, can guess the direction of the trade. 19:29:05 ^ and again an intermediate hop would break this, for example on atomic swaps which use the intermediate step 19:29:06 @jeffro256: i see that. But it won't be true for CARROT's payment validator tier keys, right? 19:30:40 anyway, I appreciate that you guys are seriously considering all of this 19:31:29 try_scan_carrot_enote_internal_receiver uses view balance secret 19:31:50 oh funny, view incoming + generate key image key doesn't allow decoding of internal enotes too 19:35:24 @just_another_day:matrix.org: CARROT, the addressing protocol, doesn't have a payment validator tier by itself. The recommended wallet key hierarchy does. But you're right, by itself, the payment validator tier would not reveal the change output of the sender. So if our third-party asked for this key by itself, then they c [... too long, see https://mrelay.p2pool.observer/e/w4Gaz-EKUEF4TjRy ] 19:35:45 So that decrypting change would require interaction from the spend key. 19:36:39 so that's an interesting weird tier that allows seeing incoming and when those get swept but not internal moves heh 19:37:07 DataHoarder: Yes, the view-balance secret is used for internal change since the view-incoming key can be found by a PQ adversary 19:37:39 how would that spend key work with the PQ Turnstile > But you could construct a wallet key hierarchy where the prove-spend key was used for encrypting change enotes. 19:39:26 @jeffro256: so with this hypothetical wallet key hierarchy the boogeyman is mainly neutralized (unless they release their own wallet app with the current hierarchy) 19:39:46 *and make this wallet app popular 19:40:02 it also means that to see your balance... you need to have online full spend keys again 19:40:11 not just to see, even to sync 19:40:33 as you otherwise won't even detect any change or internal history 19:41:31 wouldn't be able to keep them stored offline and then transfer key images, either... as the "offline" wallet would need to scan all monero chain, unless you bring the monero chain to it 19:41:52 which with current scaling moves that could be a couple TiB :') 19:43:49 every time a new internal change enote is created, the private spend key is already involved. So you can theoretically remember such enotes to slip scanning for them. You'll have to synchronize this data between your wallet apps though 19:44:11 > how would that spend key work with the PQ Turnstile > But you could construct a wallet key hierarchy where the prove-spend key was used for encrypting change enotes. 19:44:11 There's two options: either the wallet has an OVK for incoming enotes or it doesn't. If it doesn't have an OVK for incoming enotes, then think that the PQ turnstile would have the same issue: authorization is broken because opening key images means revealing spend key. It if does have an OVK for incoming enotes, then that shou [... too long, see https://mrelay.p2pool.observer/e/lZa6z-EKZlZQdC1R ] 19:44:58 One could hide "real" spend locations by churning all incoming enotes to themselves once, just like how they would hide these spends from a PQ adversary. 19:45:02 sad to hear, so with current addressing schemes (aka, not changing address format to include different/more keys like JAMTIS) this is not doable? 19:48:10 @just_another_day:matrix.org: This has similar downsides as SSSSAAH-BROSKI: https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96?permalink_comment_id=5044400#gistcomment-5044400 19:50:52 As you mentioned, you must either coordinate this info b/t live wallet instances, or do a full resync with with all your key up to the current chain tip 19:51:46 DataHoarder: I think that JAMTIS would have the same problem 19:52:53 Either you have an OVK, and key separation b/t T & G, or you don't, and revealing the opening over G reveals the opening over T 19:54:27 At its heart, knowing the opening over G, but not T, is exactly what an OVK is 20:41:37 > SSSSAAH-BROSKI 20:41:37 lel