<hbs:matrix.org> I have a question regarding internal enotes in CARROT. As it is currently defined, s_vb is used as s_sr for the purpose of encrypting internal enotes. Is there a particular constraint to use s_vb or could any other constant value be used? It seems to me that a slight change could bring peace to the Monero universe. Let me explain...

<hbs:matrix.org> In legacy wallets, the use of the incoming view key and key images allows to reconstruct the wallet balance. In CARROT this is no longer the case as internal enotes are now encrypted using s_vb as the key, therefore the only option for recovering the full balance is to detain s_vb. This works as intended for reconstructing the [... too long, see mrelay.p2pool.observer/e/h6626oULaGNNLXR4 ]

<hbs:matrix.org> Now, if instead of using s_vb for s_sr we use a key derived from k_v (incoming view key), it makes it possible to have a "revocable" view balance mechanism since you can reconstruct the balance as long as you have k_v and the key images, but that stops to be the case when you are no longer provided them, hence mimicking[... more lines follow, see mrelay.p2pool.observer/e/h6626oULaGNNLXR4 ]

hbs: You can't use a secret derived from k_v because k_v can be derived from an address by a quantum attacker. That would completely remove internal enote privacy and degrade to the same level as legacy addresses. Secondly, you should realize that the ability to detect incoming change is nearly as good as the ability to detect spends, so separating them makes little sense.

<hbs:matrix.org> tevador: Silly me, I didn't consider Kv, sorry for the noise :-(

<atomfried:matrix.org> Is there any effort in proving parts of monero in lean ?

<hbs:matrix.org> @hbs:matrix.org: Though using an encryption key separate from s_vb, and not derived from k_v, would work. I may seem stubborn, but the nuance in the "nearly" you used seems to me to be of importance and worth investigating changes.

"would work" in which sense? Don't give in to the FUD surrounding outgoing view keys.

hbs:matrix.org: any other key either becomes again outgoing view key if it can be generated from that, or is ephemeral and not recoverable from seed (your internal change would be lost), or ties these in a way that a quantum attacker can derive them

or necessitates spend keys always to send change back to yourself

<hbs:matrix.org> tevador: I am genuinely interested in having a mean of recovering the full balance with 100% certainty but that can be revoked by the user at will. The current IVK + KI fits that purpose, as it stands now, CARROT no longer provides this as the IVK + KI doesn't allow to see internal enotes and the view balance key once disclose [... too long, see mrelay.p2pool.observer/e/yIuk8YULaW9hWWlq ]

tevador is not connected currently but I think they read logs

<boog900> I mentioned last meeting about a protocol I had for proving a node is not making too many connections. I said it required proof of storage, but since then I realised we could do it without. Here is rough overview of the protocol: monero-project/research-lab #160 I'm just looking for feedback on the core idea at the moment.

I've formalized spirobel's addressing scheme proposal: gist.github.com/tevador/9169235b3c0c97e735f58a8c2ba92502

CC spirobel for a review

<hbs:matrix.org> DataHoarder: My concern is more casual users using the OVK past the time during which they are entitled to do so (for example during a commercial relationship with a regulated entity) rather than a QA which could extract keys.

You can "revoke" OVKs by sweeping to another wallet.

<hbs:matrix.org> tevador: That seems indeed the only way out

<spirobel:kernal.eu> thanks tevador this is great. only thing missing is the bidirectional part

<spirobel:kernal.eu> but we can add that later

Bidirectional payments can be done if Bob shares his address at the time when Alice gives him her address. I was thinking there could be a protocol for that which also encrypts s_psk using the DH secret from Alice's and Bob's D_r keys. That would at least protect the secret from passive eavesdroppers when addresses are shared with a counter party.

<spirobel:kernal.eu> yes that is a good idea. then alice would have to note this down in a way so it can be recovered from seed. it is somewhat orthogonal to bidirectional, sharing bobs address could be implicit in sending the tx. the question is how bob shares his address. in any case if we make the ergonomics better for people to have e2e encryp [... too long, see mrelay.p2pool.observer/e/z6HIgoYLLV9iUTBa ]

Alice decrypts Bob's PSK and Bob decrypts Alice's PSK. Both PSK's are derived from the seed of their owner (via the account master key). So only "channel opening" would be interactive. The rest is non-interactive.

<spirobel:kernal.eu> they first share their addresses without the secret, then do dh to encrypt the secret and share it. could also be used to then share other messages. it feels structurally very similar to exchanging pgp keys, this is good. i had some thoughts on how to make it non interactive, but it is probably better to focus on this use case.