How to handle private escrows between two parties..?

Great post as always!
Wanted to summarise some of the discussion we have been having offline.

1. Have a “public” key for the contract - simple but leaks privacy.

2. Unshield into the public domain - arguably easier than (1) since you have no overhead of keys. But depending on app, might leak more privacy. Works “well” for L1<>L2 interactions though and for transient escrowing - where the funds only stay in the contract for just the duration of the tx.

3. New contract per question/bet and give it a key - this wouldn’t be too expensive, especially if all the bytecode is in private! However it does mean you can’t have an open ended bet/escrow where you can challenge anyone (not a fixed address) to take part in your bet/escrow. Unfortunately, as you say, we need to implement the ability for contracts to deploy other contracts.

4. One contract. Different key per interaction - this avoids having to deploy a new contract. And if I understand you correctly, uses a Deffie-Hellman like key exchange. This is probably the neatest solution… As you say, notes have two kinds of owners, or as Lasse would call it:
a. Owner that provides nullifier secret (ie. owner in the protocol domain)
b. Owner that defines when to nullify (ie. owner in the application domain)

In this model, (a) will be the shared secret key. (b) will the contract address.

BAD NEWS - Unfortunately, this seems to break the note tagging scheme that is currently being designed. TL;DR from what I understand is you have to be like an account contract to wield your nullifier secret.

GOOD NEWS - there are workarounds:
i. For the special case of “transient escrowing” where the funds only live temporarily for the tx and get nullified in the same tx (as is used in most defi interactions), we don’t need to discover such notes, so it might work out. Lasse has explained in depth here but if I may butcher his words: token.transfer() would have a new parameter to_secret_provider which would be this secret key.

ii. If we mix this approach with design 3, then we might have something!

Okay, so what’s possible TODAY?
Design 1,2.

We are trying to finalise the spec for transient escrowing and that might unlock new designs! Will comment here once we come to an agreement on that!

Shoutout to Mike, Lasse, Jan and others for jamming with me on this!