05:50:40 <crypto_grampy[m]> <SerHack> "If yes, I would vote against it...." <- Definitely agree here.  Just because something can be done doesn't always mean it should.  It's definitely worth considering these advanced view key abilities through a lens of deniability.  Being able to provide a perfect view only glimpse at wallet contents and outgoing tx's is much more than a performance upgrade.   What are some worst case scenarios for how something
05:50:40 <crypto_grampy[m]> like this could be used against xmr merchants and users?
05:53:35 <crypto_grampy[m]> For some people, the wallet history may be more valuable than the actual contents 🤷.  food for thought :) 
06:21:03 <jberman[m]> There's probably a solid likelihood some 3rd party wallet service will eventually offer a wallet that trades off privacy/security for maximum convenient UX, and the 3rd party will have the ability to see everything but not spend. It likely won't just be idiots affected or adversarial circumstances where this props up, average users could very well be attracted to that type of wallet too
06:31:44 <crypto_grampy[m]> Ah yes, the Meownero Wallet(tm) by PricacyCo- a fully owned subsidiary of ChainalysisCocaCola.  Use our free monero wallet and get paid every time you use it!  Just... Give us the view keys.   All of them.   
06:35:48 <jberman[m]> Right and in the worst case, if a wallet service like that gets big enough, as UkoeHB mentioned somewhere in the github issue, ring signatures could be compromised (which is still a risk today with the current scheme we have, but more so with that ability)
06:36:47 <jberman[m]> Even if we move on from ring sigs toward membership proofs that span the whole chain in the future, that wallet service could in theory be shrinking the anonymity set (if users choose to use that wallet service instead of another wallet which does not offer that capability)
07:16:44 <crypto_grampy[m]> https://en.m.wikipedia.org/wiki/Precautionary_principle
07:17:35 <crypto_grampy[m]> Definitely worth thinking about on some of these things 🙃 
08:40:06 <surgeon_[m]> I agree that those viewkeys would be a problem. Over time they could become centralized on exchanges and such wallet providers, and will most likely be sold to Chainanalysis companies. Possibly even due to regulatory requirements such as KYC requirements/risk management. Not to mention any heuristics one could gain from access to that data about transactions NOT included in said data. Sorry if I'm butting in a discussion I'm
08:40:06 <surgeon_[m]> no researcher, but this seems problematic to me.
10:32:47 <stilettophiccant> good afternoon. New here. Just trying yo understand how to move in monero worlds
10:37:28 <sech1> this is the research channel, use #monero for general questions
10:38:13 <sech1> ah, just saw your message in #monero-dev. Welcome!
13:20:38 <UkoeHB> SerHack: The expectation is Tier 2 will never be given to third parties. If you want to provide an audit of your account, then special audit proofs should be used (e.g. ZtM2 ch. 8). If you want third-party to have a key, then tiers 0/1/1.5 are geared to that.
14:16:11 <gingeropolous> well, thats an expectation. i think a better scenario would be "Tier 2 can never be given to third parties". Then again, our existing system with viewkeys allows for the same honeypot-style system-wide attack (e.g., if mymonero were compromised), except for amounts i guess...
14:20:55 <gingeropolous> i mean, i dunno how close to "lets install a screen door on the submarine, so when we surface we can smell the breeze" this is getting... but.... thar be dragons
15:34:00 <BusyBoredom[m]> I think the ability to view correct wallet ballance without a spend key is important. I would use that feature to keep an eye on cold wallets; it's a feature I've wanted for quite a while now. I think it is worth the risk of abuse. 
15:35:30 <hyc> agreed. I think most people who hear "view key" assume they will see their true balance, both receives and sends
17:32:32 <jetsteel[m]> In addition to a full balance "view key", I think it is important to implement a robust view tag system. lightwallets should be able to request a small enough set that it "just works" on mobile, but a large enough set for privacy.
17:33:26 <jetsteel[m]> Then there is less reason for a user to hand view keys to a 3rd party.
18:06:42 <x3nu[m]> <hyc> "agreed. I think most people..." <- isn't this type of feature being proposed though? The issue we have is that kyc exchanges will then be likely to make presenting a view key like this mandatory for withdrawing, thereby sacrificing overall network privacy
18:11:37 <UkoeHB> x3nu[m]: not sure that would happen, since you can just withdraw to a new wallet
18:15:32 <tevador> is someone seriously suggesting removing view-only wallets?
18:15:54 <x3nu[m]> view only with spends
18:16:16 <tevador> there is no practical difference
18:17:02 <x3nu[m]> how so? if somebody is being monitored, wouldn't their spend time (and amount) be crucial metadata? 
18:17:19 <tevador> view only without spends can heuristically identify all spends that have change outputs, plus some false positives in rare cases
18:18:15 <tevador> the rare case being if someone is sending you money and picks one of your unspent outputs as a decoy
18:19:12 <x3nu[m]> this is still an improvement though on providing the additional information of when and how much somebody is sending Monero
18:20:11 <x3nu[m]> i believe that Monero will eventually be listed on most exchanges with view wallets (if it is listed, then otherwise this point is moot), so my issue is providing more metadata as a possibility. 
18:20:27 <x3nu[m]> * is listed universally, then
18:21:19 <tevador> as I said, no practical privacy difference between the current view-only and future Tier 2, just a substantial UX improvement (no "export key images" stuff)
18:29:37 <x3nu[m]> the difference would be this heuristic regarding change outputs. if you remove that there would be a practical difference. 
18:31:44 <x3nu[m]> but i suppose if they know the output amount even if it is a single output, once the output gets spent they can see the difference in the view only balance. am I understanding this correctly?
18:32:24 <tevador> x3nu[m]: you cannot remove this heuristic. What exactly are you proposing?
18:33:52 <x3nu[m]> frankly i never considered this heuristic
18:34:17 <tevador> Current view-only can see a TX that has a wallet output worth 5 XMR in its ring and a wallet output of 1 XMR. So it can deduce this TX spends 4 XMR and the 1 XMR output is change. Or, very rarely, someone sent us 1 XMR and picked our 5 XMR output as a decoy.
18:34:33 <x3nu[m]> ok cool thank you for explaining this to me. I understand it better now
18:39:44 <tevador> UkoeHB: I've been thinking how to prevent Tier 1 privacy leaks. The fact that duplicate outputs can be detected is not a big issue as long as we don't reuse change addresses. Change outputs leak real spends, so they should be hidden from Tier 1. Since Tier 2 can detect spends, we could introduce some special key derivation for change outputs that produces a unique change key for each tx.
18:47:13 <jberman[m]> Users would also need to use a new address for each payment received
18:48:23 <sgp_> I think MRL isn't the best place to discuss whether it's a good idea to add a key that shows sending amounts as well or not, maybe take that to #monero:monero.social 
18:49:17 <sgp_> but on a research side this is already disclosable today and has always been
18:50:46 <nioc> too bad monero irc and monero matrix are not bridged 
18:54:36 <tevador> jberman[m]: no, that's not necessary, received payments don't leak information about decoys
18:56:04 <tevador> information is only leaked if the same wallet is in the list of decoys and the list of outputs
18:57:58 <sgp_> actually let me think about that change condition a bit
18:58:01 <tevador> Of course, receiving multiple payments to the same address leaks that address to Tier 1, but this leak is limited to that one wallet and doesn't harm others who choose those outputs as decoys.
18:58:15 <sgp_> you may be right that it's a non-issue but I didn't really think it through
18:59:38 <jberman[m]> tevador what is the point of view tags at tier 1 if users aren't creating new  addresses for receiving payments?
19:00:10 <tevador> They should be, but you can't force them.
19:03:20 <tevador> The point of Tier 1 view tags is to speed up wallet sync, the privacy issues are the price to pay for this convenience. But this price should be paid by the person using Tier 1 scanning and not by other users of Monero.
19:03:24 <jberman[m]> Right is why I'm curious about exploring the option to have another key for view tags. It would seem to me to be a tangible security improvement for tier 1 users
19:03:41 <jberman[m]> For those who don't reuse addresses
19:03:54 <jberman[m]> Sorry, who do* rather 
19:06:25 <tevador> IMO a separate key for view tags is not worth it. You would need +1 public key in each address (33% longer addresses) and +1 public key in each output (blockchain bloat). All this just to maginally improve the privacy of some users who use Tier 1.
19:09:56 <sgp_> I'm failing to see how privacy is able to be protected and more really for users who hand over the view tags viewing tier 1 key
19:09:57 <sgp_> it's better than the status quo because of the deniability, and you don't need to give them your addresses
19:11:32 <tevador> MyMonero has a couple hundred thousand users who easily handed out their view keys. Tier 1 would be a massive privacy improvement for them.
19:17:43 <jberman[m]> <tevador> "The point of Tier 1 view tags is..." <- This is a solid point
19:51:38 <jberman[m]> <tevador> "UkoeHB: I've been thinking how..." <- Removing this change output heuristic from Tier 1 sounds like a great idea to me too
21:13:07 <jberman[m]> tevador  received payments could leak information about decoys if you spend them in a multi-input tx. The more inputs the more significant, the larger the ring size the less significant
21:20:02 <jberman[m]> I guess that's not definitively solved by an additional key or not reusing addresses either though, since the 3rd party can still see outputs that pass the view tag check are included across rings in the future
21:35:09 <jberman[m]> The wallet could in theory bias toward selecting view tag matched outputs to protect against this^
21:42:13 <UkoeHB> > Change outputs leak real spends, so they should be hidden from Tier 1. Since Tier 2 can detect spends, we could introduce some special key derivation for change outputs that produces a unique change key for each tx.
21:42:14 <UkoeHB> I don't think this is feasible. How are you going to find change outputs without fingerprinting them or needing to scan every output (at the very least, download every output)? If your idea is just to send change outputs to different addresses, real spends are still leaked... the heuristic is 'receive output, inputs reference owned outputs', it doesn't require being able to identify that a received output is change or 
21:42:14 <UkoeHB> not.
22:03:59 <selsta> https://www.getmonero.org/2021/12/22/what-is-seraphis.html is up
22:07:52 <jberman[m]> A 1-input tx with a known output belonging to user as a ring member + a known change output belonging to the user is significant versus just identifying a 1-input tx with a known output belonging to the user
22:19:31 <tevador> UkoeHB: for example, change spend key = K_s + H(spent output linking tag) G, you can easily recover this when you see the spend (and the view tag will match)
22:20:13 <tevador> sorry, should be K_s + H(k_vb, spent output linking tag) G
22:23:06 <tevador> "the heuristic ... doesn't require being able to identify that a received output is change or not" - except there will be a lot of false positives (someone else's tx referencing an output with a matching view tag and some of the outputs also having a matching view tag)
22:23:44 <tevador> having a duplicated change output key means you can say 99% this is a real spend that belongs to the wallet
22:24:07 <tevador> otherwise real spends will be hidden in a sea of false positives with matching view tags
22:25:56 <tevador> The worst case scenario would be that all change outputs go to the same address, then Tier 1 can see all your spends.
23:21:54 <rottenstonks> Anyone has a link to Confidential Transactions, the very first preprint by Adam Back or Maxwell, or whoever it was, and the preprint for RingCT (Monero's implementation of CT)? Would appreciate both, or any pointers as to where to find them. Thanks!
23:30:29 <rottenstonks> Nevermind. Found both. Confidential Assets (original CT): https://blockstream.com/bitcoin17-final41.pdf; RingCT: https://eprint.iacr.org/2015/1098.pdf
23:42:40 <UkoeHB> tevador: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#gistcomment-4005812