<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)

<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.

<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

<jeffro256> Unless, of course, you coerce every single user of Monero to prove positive/negative s.t. every output is accounted for.

<jeffro256> Good luck

<0xfffc> chromium.googlesource.com/chromium/…main/styleguide/c++/c++-features.md

<syntheticbird> @0xfffc: If you are sharing it here, we can assume that applying this policy can have benefits for monerod codebase?

<syntheticbird> s/monerod/monero

<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.

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

<preland> DataHoarder: I was thinking abt something along the lines of this

<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

<jeffro256> Lol that'll get really big really fast but it works

yeah, given a block range you'd have to do it for each confirmed transaction

<jeffro256> There's probably some way to aggregate the signatures at least

<jeffro256> You'd have to do it for every single ephemeral pubkey in each tx in each block

each output yeah, that does get big :D

<jeffro256> For 2-out txs, that's only 1, but it's N+1 for N-out txs where N>2

<jeffro256> Except in CARROT where it's N, not N+1 for N>2

it can be generalized to be for every ephemeral pubkey available, no?

the ones in tx extra

the issue is that you could have been sent something with a custom derivation method that you can spend

or broken tx with missing tx extra, and tx extra is sent out of band

<jeffro256> Yeah that's what I mena > <DataHoarder> it can be generalized to be for every ephemeral pubkey available, no?

<jeffro256> mean

you could here show that you received nothing (tx is borked) but in reality you did and could spend it later

so it only shows that you received nothing *if output was produced using a known derivation method

<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

<jeffro256> And since Monero is permisionless, there's nothing technically stopping you

<jeffro256> It would only make sense for auditing long-lived, static addresses which are publicly known

<jeffro256> DataHoarder: Yes, exactly

in situations such as blocks.p2pool.observer/block/85c9e0…0dcda030126805654d9e91a68d720268764

where later the pubkey is bruteforced, you'd also not get a proof for it

even while the derivation was done properly, some data was missing in the tx

<preland> I guess a better question, especially considering how public reception towards view keys is:

<preland> what is the exact use case that is attempting to be achieved by view keys?

<elongated:matrix.org> @preland: Public ? It’s a bunch of ppl trying to fud

<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.

<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.

<preland> So, *again*, I will ask: what is the exact use case that view keys provide for Monero?

<elongated:matrix.org> @preland: Easier cold wallet usage

<elongated:matrix.org> Needed keys for migration PQ

<redsh4de:matrix.org> should also make integration in various DEX protocols much easier iirc

<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