How to handle private escrows between two parties..?

[spalladino]

@spalladino

Reencrypt the same note under multiple pubkeys

An alternative that does not require overloading the pxe with additional keys is to simply re-encrypt the same note under the pubkey of each recipient. In other words, having a single commitment on the note hash tree, but emit it as an encrypted log multiple times. The tradeoff here is more calldata used in the tx.

An issue with this approach is nullifying the note. Since multiple users have “access” to the note, they all need to be able to nullify it. The shared secret, derived from the recipients pubkeys, could be used here. Or a random nullifier key could be just embedded as part of the encrypted note, which becomes visible to all those who can decrypt it.

This implies that we cannot use the same note implementation for multi-encryption that we use for individual transfers, since we cannot just rely on get_secret(note.owner) for nullifying. But it’s a fairly small change, and it also plays well with storing nullifier secrets or identifiers as part of the note itself if we allow for rotating nullifier keys.

To elaborate on this approach, we’ll need to modify the token contract and introduce a new note type. This new note, let’s call it SharedValueNote for lack of a better name (please, dear reader, think of a better name!), should be similar to the ValueNote except for:

• compute_nullifier should not use the owner’s nullifier but a random secret generated by the note creator and embedded into the note, so it’s accessible by all viewers.
• broadcast should not use the owner pubkey, but receive a list of the addresses for which to emit the encrypted log. Note that, given that this diverges from the default NoteInterface, we may need to make the note’s broadcast a noop and handle it manually.

Note that we still want to keep the owner field since that’s the address that’s authorised for actually spending this note in the contract logic.

The token contract then needs logic for creating and consuming these notes. An easy solution is to have a dedicated method create_shared_note that consumes existing regular ValueNotes of equivalent value, and then a consume_shared_note which does the opposite, similar to shield/unshield operations. An open question is how the balance_of method would work, since it’d have to add balance across both flavors of notes.

Alternatively, it’d be interesting to see if we can merge both the SharedValueNote and the ValueNote into a single note type somehow, since the only practical difference is whether the nullifier is set as a random value by the sender or generated from the recipient’s secret. This would probably require having a special flavor of the transfer function that accepts a list of “viewers” for the note.