06:21:32 <br-m> <kerenken:matrix.org> i0
06:41:11 <br-m> <torir:matrix.org> If you are in a positon where law enforcement would request view keys, you don't need an inability to share a view key. What you need is deniability. If your threat model requires deniability, I would recommend having multiple wallets, and keep one of them encrypted in a spot that won't be easily found.
06:42:29 <br-m> <torir:matrix.org> There is a case to be made for government surveilance, but why would governments request view keys when they could require you use a wallet app modified to send your transactions to the government (like Chat Control is trying to do with forcing chat apps to having automated scanning).
06:46:36 <br-m> <torir:matrix.org> In the deniability case, an outgoing view key could actually help. You could share the view key of a dummy wallet with the government and keep your actual wallet in the cloud, accessed only via Tails.
06:46:50 <br-m> <torir:matrix.org> They can't prove you have a second wallet.
06:49:35 <br-m> <moneroni:matrix.org> Gov: oh you dont have a view key!? Great! give me everything then > <@torir:matrix.org> If you are in a positon where law enforcement would request view keys, you don't need an inability to share a view key. What you need is deniability. If your threat model requires deniability, I would recommend having multiple wallets, and keep one of them encrypted in a spot that won't be easily found.
08:06:25 <br-m> <hbs:matrix.org> So because some countries do not have a working legal/judiciary system we should not give all chances to the users who are happy to live in one which does?
08:29:19 <br-m> <syntheticbird> @torir:matrix.org: First of all, I agree with @hbs:matrix.org. Second of all, deniability is opening another can of worms completely. When you are dealing with cryptowallets most of the time that's not your regular general purpose inspector. In most european countries there are specific cybercrime and fraud department with [... too long, see https://mrelay.p2pool.observer/e/28-kiL4KYTk2SnhQ ]
08:29:19 <br-m> <syntheticbird> Don't underestimate the cops argument of authority in courts over technologically ignorant judges, deniability alone is worthless and plausible deniability is very hard to achieve in a way that cops are convinced or that your innocence can be explained to the judge.
09:44:52 <br-m> <moneroni:matrix.org> @syntheticbird: Once you are found to have a monero wallet, deniability is THE protetion you need, not "another can of worm". Not gonna say that  this is easy. This will require users to prepare a dummy wallet in advance. Users will need to include tranctions detectable to law enforcement in the dummy wallet.
09:44:52 <br-m> <moneroni:matrix.org> Ability to disable view key is just a niche legal trick, far from what I would call "a layer of protection".
12:40:58 <nioc> View keys are great for view only wallets.  For personal wallets why do you need it?  
12:48:07 <br-m> <monero.arbo:matrix.org> to view activity on a device that doesn't have spend authority?
13:34:19 <nioc> I don't need it for my use case.  The proposal certainly shouldn't promise any guarantees of protection. 
13:34:58 <br-m> <minecraftvillager69:catgirl.cloud> nioc: Honestly if you're receiving funds but not really sending them much, it can be nice to check recent transactions and your total amount, without the risk of losing all your funds should your device be compromised. The spend wallet can be air gapped, or at least isolated from everyday activity, to help protect it.
13:35:00 <nioc> It = view capabilities 
13:36:56 <nioc> I am just asking for choice and having it set up so wallets will also be made with the choice
13:37:48 <nioc> As to having more than 1 wallet, people should already be doing this
14:32:22 <br-m> <jack_ma_blabla:matrix.org> nioc: a choice to disable view-balance key ? agree 
14:32:34 <br-m> <ofrnxmr:xmr.mx> Just like "exchange addresses", i can see services requiring users to provide ovks of the wallet used to deposit or withdraw funds
14:33:17 <br-m> <ofrnxmr:xmr.mx> Recently someone wa asked by fixedfloat to provide spend proofs. This will just change to "provide ovk"
14:33:56 <br-m> <jack_ma_blabla:matrix.org> @ofrnxmr:xmr.mx: just point them to getmonero guide, which says wallet can be created without view-balance key
14:37:05 <br-m> <jack_ma_blabla:matrix.org> view-balance key would be great for spv wallets
14:39:14 <br-m> <ofrnxmr:xmr.mx> @jack_ma_blabla:matrix.org: Yea, if you have a choice, and that choice is default
14:40:05 <br-m> <ofrnxmr:xmr.mx> privacy by.. default 🤯. Crazy idea, right?
14:40:53 <br-m> <jack_ma_blabla:matrix.org> @ofrnxmr:xmr.mx: it is private by default, is the exchange able to distinguish between a enabled/disabled wallet address ?
14:41:33 <br-m> <jack_ma_blabla:matrix.org> if you dont want to disclose view key, just say you dont have it
14:42:26 <br-m> <hbs:matrix.org> @jack_ma_blabla:matrix.org: But if it is common knowledge that all wallets generate an OVK, that will be hard to sustain
14:43:46 <br-m> <ofrnxmr:xmr.mx> If its common knowledge that only a small subset of users have ovks, its not going to be "normal" to expect one to exist
14:45:03 <br-m> <jack_ma_blabla:matrix.org> @ofrnxmr:xmr.mx: without ovk, there will be no spv ; or lws comes close ?
14:45:20 <br-m> <ofrnxmr:xmr.mx> Lws doesnt need an ovk
14:45:40 <br-m> <jack_ma_blabla:matrix.org> @ofrnxmr:xmr.mx: is spv wallet comparable to lws ?
14:47:23 <br-m> <ofrnxmr:xmr.mx> i imagine so
14:59:04 <br-m> <spirobel:kernal.eu> @jack_ma_blabla:matrix.org: spv should verify pow difficulty and presence of transaction in the block. i assume most people running lws will run in together with a node on the same machine. 
15:00:43 <br-m> <spirobel:kernal.eu> for an spv client / wallet this verification should be done in the wallet and not only in the node / server 
17:01:17 <br-m> <torir:matrix.org> I'm all for having all wallets have an option to not generate an OVK. But I don't think that is sufficient without user education on why they might want that option.
17:31:58 <br-m> <ofrnxmr:xmr.mx> @torir:matrix.org: Theyd only want that option for.. btcpayserver/employers who need to monitor in/out. Fundraisers... and other service providers
17:32:15 <br-m> <ofrnxmr:xmr.mx> I dont think the feature is really useful for consumers
18:07:23 <tevador> If you are talking about outgoing view keys, they are useful for anyone who wants to use a hardware wallet.
18:28:56 <br-m> <articmine> I believe this discussion around outgoing view keys is missing a critical parameter. The public keys of the recipients of the subject wallet. Without this information an auditor of the subject wallet in possession  of the view key or even the spend key would not be able to determine to whom the funds were sent. Even a Solver o [... too long, see https://mrelay.p2pool.observer/e/hbq4mb4KU25ZUWNH ]
18:35:53 <br-m> <articmine> In any case my take on this issue is that allowing for a full view key should be the default scenario. As for backing up and managing the recipient public key information this needs to be explained.
18:36:39 <br-m> <articmine> Also relevant documentation made easily available 
18:37:51 <br-m> <articmine> This can be useful to both those who wish to recover this information as well as those who wish to destroy it.
18:41:44 <br-m> <articmine> An interesting case would be when an empty intermediate wallet becomes the victim of a "boating accident".
18:49:06 <br-m> <articmine> By intermediate wallet(s) I mean one or more  wallets between a fully KYCed wallet where the view key was disclosed and a private spending wallet.
21:07:31 <tevador> FWIW, I don't think setting s_vb = k_ps in Carrot is safe at all. The only safe way to remove OVK within the scope of Carrot is to stick to the "legacy" key hierarchy that only has a spend key and a view key. I think this is the only choice users should have (new vs legacy wallet). Users who don't want OVK can generate a legacy wallet.
21:10:42 <br-m> <torir:matrix.org> Could you have both key hierarchies from a single wallet seed safely?
21:11:26 <br-m> <torir:matrix.org> It would be an easy way to present one option as the default while still letting users use the other method later without much effort.
21:32:17 <tevador> There is nothing technically preventing that, but it would be very unwise. You'd get two incompatible sets of addresses with different scanning procedures. You'd also lose forward secrecy.
21:47:22 <nioc> would new vs legacy wallets have different address formats? 
21:48:24 <br-m> <hbs:matrix.org> nioc: From my understanding of CARROT I'd say no, just different features