-
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
-
crypto_grampy[m]
like this could be used against xmr merchants and users?
-
crypto_grampy[m]
For some people, the wallet history may be more valuable than the actual contents 🤷. food for thought :)
-
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
-
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.
-
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)
-
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)
-
crypto_grampy[m]
-
crypto_grampy[m]
Definitely worth thinking about on some of these things 🙃
-
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
-
surgeon_[m]
no researcher, but this seems problematic to me.
-
stilettophiccant
good afternoon. New here. Just trying yo understand how to move in monero worlds
-
sech1
this is the research channel, use #monero for general questions
-
sech1
ah, just saw your message in #monero-dev. Welcome!
-
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.
-
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...
-
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
-
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.
-
hyc
agreed. I think most people who hear "view key" assume they will see their true balance, both receives and sends
-
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.
-
jetsteel[m]
Then there is less reason for a user to hand view keys to a 3rd party.
-
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
-
UkoeHB
x3nu[m]: not sure that would happen, since you can just withdraw to a new wallet
-
tevador
is someone seriously suggesting removing view-only wallets?
-
x3nu[m]
view only with spends
-
tevador
there is no practical difference
-
x3nu[m]
how so? if somebody is being monitored, wouldn't their spend time (and amount) be crucial metadata?
-
tevador
view only without spends can heuristically identify all spends that have change outputs, plus some false positives in rare cases
-
tevador
the rare case being if someone is sending you money and picks one of your unspent outputs as a decoy
-
x3nu[m]
this is still an improvement though on providing the additional information of when and how much somebody is sending Monero
-
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.
-
x3nu[m]
* is listed universally, then
-
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)
-
x3nu[m]
the difference would be this heuristic regarding change outputs. if you remove that there would be a practical difference.
-
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?
-
tevador
x3nu[m]: you cannot remove this heuristic. What exactly are you proposing?
-
x3nu[m]
frankly i never considered this heuristic
-
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.
-
x3nu[m]
ok cool thank you for explaining this to me. I understand it better now
-
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.
-
jberman[m]
Users would also need to use a new address for each payment received
-
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
-
sgp_
but on a research side this is already disclosable today and has always been
-
nioc
too bad monero irc and monero matrix are not bridged
-
tevador
jberman[m]: no, that's not necessary, received payments don't leak information about decoys
-
tevador
information is only leaked if the same wallet is in the list of decoys and the list of outputs
-
sgp_
actually let me think about that change condition a bit
-
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.
-
sgp_
you may be right that it's a non-issue but I didn't really think it through
-
jberman[m]
tevador what is the point of view tags at tier 1 if users aren't creating new addresses for receiving payments?
-
tevador
They should be, but you can't force them.
-
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.
-
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
-
jberman[m]
For those who don't reuse addresses
-
jberman[m]
Sorry, who do* rather
-
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.
-
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
-
sgp_
it's better than the status quo because of the deniability, and you don't need to give them your addresses
-
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.
-
jberman[m]
<tevador> "The point of Tier 1 view tags is..." <- This is a solid point
-
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
-
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
-
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
-
jberman[m]
The wallet could in theory bias toward selecting view tag matched outputs to protect against this^
-
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.
-
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
-
UkoeHB
not.
-
selsta
-
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
-
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)
-
tevador
sorry, should be K_s + H(k_vb, spent output linking tag) G
-
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)
-
tevador
having a duplicated change output key means you can say 99% this is a real spend that belongs to the wallet
-
tevador
otherwise real spends will be hidden in a sea of false positives with matching view tags
-
tevador
The worst case scenario would be that all change outputs go to the same address, then Tier 1 can see all your spends.
-
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!
-
rottenstonks
Nevermind. Found both. Confidential Assets (original CT):
blockstream.com/bitcoin17-final41.pdf; RingCT:
eprint.iacr.org/2015/1098.pdf
-
UkoeHB