06:55:29 <br-m> <jeffro256> > <@preland> Q: with Carrot, what methods of transaction transparency are possible? I'm trying to determine how minimal information sharing can be in different scenarios (mainly, if one could provide some sort of proof that they received and sent certain outputs in a given time frame, or that they didn't do so in a given time frame)
06:55:29 <br-m> <jeffro256> You can prove the positive statement (did receive funds), but not the negative version (did not receive funds) without revealing the private view-incoming key.
06:56:54 <br-m> <jeffro256> However, the negative version doesn't really make any IRL sense whatsoever even if it did work cryptographically because Monero is permissionless; I can prove that I didn't receive XMR to this address, but there's no way to prove that I don't have another wallet
06:57:49 <br-m> <jeffro256> Unless, of course, you coerce every single user of Monero to prove positive/negative s.t. every output is accounted for.
06:57:58 <br-m> <jeffro256> Good luck 
12:59:15 <br-m> <0xfffc> https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md
13:16:50 <br-m> <syntheticbird> @0xfffc: If you are sharing it here, we can assume that applying this policy can have benefits for monerod codebase?
13:17:00 <br-m> <syntheticbird> s/monerod/monero
13:18:00 <br-m> <0xfffc> Of course. C++ code base tend to get very complex and non maintainable basically. Applying these rules can make it very readable and easy to maintain. 
15:11:19 <DataHoarder> jeffro256: you can prove the derivation of each transaction output received in a certain range is yours or not, that way you could prove you received nothing at a specific wallet
16:19:15 <br-m> <preland> DataHoarder: I was thinking abt something along the lines of this
20:24:08 <br-m> <jeffro256> DataHoarder: Oh shoot yeah you're right. You can provide the ECDH value for every single output on the chain, then prove the discrete log relationship is the same as your Monero address. The verifier checks the discrete log proof for every ECDH value, then does sender-side scanning with those ECDHs
20:24:23 <br-m> <jeffro256> Lol that'll get really big really fast but it works 
20:24:51 <DataHoarder> yeah, given a block range you'd have to do it for each confirmed transaction
20:24:56 <br-m> <jeffro256> There's probably some way to aggregate the signatures at least 
20:25:27 <br-m> <jeffro256> You'd have to do it for every single ephemeral pubkey in each tx in each block 
20:25:39 <DataHoarder> each output yeah, that does get big :D
20:25:50 <br-m> <jeffro256> For 2-out txs, that's only 1, but it's N+1 for N-out txs where N>2
20:26:17 <br-m> <jeffro256> Except in CARROT where it's N, not N+1 for N>2
20:26:35 <DataHoarder> it can be generalized to be for every ephemeral pubkey available, no?
20:26:40 <DataHoarder> the ones in tx extra
20:27:07 <DataHoarder> the issue is that you could have been sent something with a custom derivation method that you can spend
20:27:21 <DataHoarder> or broken tx with missing tx extra, and tx extra is sent out of band
20:27:29 <br-m> <jeffro256> Yeah that's what I mena  > <DataHoarder> it can be generalized to be for every ephemeral pubkey available, no?
20:27:34 <br-m> <jeffro256> mean
20:28:06 <DataHoarder> you could here show that you received nothing (tx is borked) but in reality you did and could spend it later
20:28:18 <DataHoarder> so it only shows that you received nothing *if output was produced using a known derivation method
20:28:32 <br-m> <jeffro256> Yeah which is why I said it doesn't make a lot of sense IRL: you can simply make a 2nd wallet, or use non-standard addressing protocols  > <DataHoarder> the issue is that you could have been sent something with a custom derivation method that you can spend
20:28:49 <br-m> <jeffro256> And since Monero is permisionless, there's nothing technically stopping you 
20:29:19 <br-m> <jeffro256> It would only make sense for auditing long-lived, static addresses which are publicly known 
20:29:37 <br-m> <jeffro256> DataHoarder: Yes, exactly 
20:31:13 <DataHoarder> in situations such as https://blocks.p2pool.observer/block/85c9e0e2fa7d843b6698d6aa9c51e0dcda030126805654d9e91a68d720268764
20:31:37 <DataHoarder> where later the pubkey is bruteforced, you'd also not get a proof for it
20:31:45 <DataHoarder> even while the derivation was done properly, some data was missing in the tx
21:44:51 <br-m> <preland> I guess a better question, especially considering how public reception towards view keys is:
21:44:51 <br-m> <preland> what is the exact use case that is attempting to be achieved by view keys?
21:47:14 <br-m> <elongated:matrix.org> @preland: Public ? It’s a bunch of ppl trying to fud
21:56:12 <br-m> <preland> @elongated:matrix.org: They do raise a valid concern, even if I've been publicly pushing back against it; the existence of view keys could eventually result in publishing the view key becoming common practice due to external pressure.
21:56:12 <br-m> <preland> And while this *is* able to be subverted by simply using a different Monero address when interacting with antagonistic parties.....that isn't a foolproof solution.
21:56:12 <br-m> <preland> So, *again*, I will ask: what is the exact use case that view keys provide for Monero?
21:58:41 <br-m> <elongated:matrix.org> @preland: Easier cold wallet usage
21:58:41 <br-m> <elongated:matrix.org> Needed keys for migration PQ
21:59:14 <br-m> <redsh4de:matrix.org> should also make integration in various DEX protocols much easier iirc
22:05:59 <br-m> <preland> It might be wise to have an "intermediary" wallet creation function in the default implementation, as that will drastically reduce the effectiveness of forcing users to provide the view key