Broadcasting notes in token contracts

[Mike]

Do we need to make opinionated decisions here, or can we just let app/wallet devs decide? Are you seeking to create an opinionated token standard?

@spalladino

When encrypting for self, the outgoing and incoming internal scenarios, there is no need to constrain correct encryption

I might disagree with this one. I think there might be a need, depending on how the app might wish to build in auditability functionality. Proving who you sent funds to feels like a useful primitive, in some cases. Or perhaps an app wants over-protect users from losing their funds, so it forces correct encryption.

@spalladino

And these [scenarios for when to constrain encryption to someone else] depend on the context of the transfer, not on the token implementation itself.

I can envisage a token contract implementation which wishes to enforce correct encryption?

@spalladino

Also, we don’t have the receiver’s wallet software around to aks it whether the receiver wants to have this specific note broadcasted or not (as we did in the “encrypt for self” scenario).

We can call their account contract though - could that be a useful way to get this preference?

@spalladino

Note that, if the incoming viewing key is used here, this will lead to records that describe value sent will be sometimes encrypted with an outgoing key (when the executor of the tx was the owner) and sometimes with an incoming key (when the executor was an authorized third party). We could avoid this issue by always using the outgoing key, regardless of who encrypts, but this means we cannot use the outgoing secret key for encryption as originally planned.

I haven’t quite followed this paragraph, sorry.
Are we saying that:

• If a user wants to spend their own funds, they use keys:
  • tx auth secret key to sign the tx request.
  • nullififer secret key to generate a nullifier for which no-one else knows the preimage
  • outgoing secret key to generate an outgoing ciphertext, potentially describing the note which was spent and/or new notes which have been created by the user.
• If a 3rd party is given permission to spend a user’s funds, the user cannot give the 3rd party their secret keys; they can only give the 3rd party a signature representing “tx auth”, but they can’t easily provide the ability to nullify nor the ability to encrypt outgoing messages (because secrets need to stay secret)?

@spalladino

1. Encrypting data for self should be conditional on an oracle call, so the wallet controls whether to generate an outgoing trail or backup change notes.
2. Token transfer method should accept a flag for whether to prove encryption of the recipient note or not.
3. Token transfer method should always broadcast the recipient note, for the sake of simplicity.
4. Outgoing encryption can only be done by the holder of the key, so even for notes that “semantically” mean outgoing data (eg transferFrom), if they are produced by a 3rd party, we use the incoming key.

1. The app might have a strong preference to generate an outgoing trail and to backup change notes. Imo, either: the app should have the ability to detect that an account contract has denied an encryption request and then the app might choose to revert; or the user’s account contract shouldn’t be able to refuse such a call from an app.
2. Doesn’t this depend on the requirements of the token contract?
3. Doesn’t this depend on the requirements of the token contract?
4. Perhaps we need to more-exactly define “outgoing” data in this context. I’d been understanding it to mean “data that I (a user) have created, which is primarily intended for someone else’s future consumption”. With that definition, I suppose I view the scenario of a 3rd party spending Alice’s notes as “incoming data”, from Alice’s perspective.

---

Separately, it would be nice if we could distill all our imagined token scenarios into a very minimal comparison, to help us to see how to design a single token contract standard which can enable all scenarios without too much ugly conditional logic:

• Me spending my notes
• A 3rd party (without my secrets) spending my notes
• An escrow smart contract spending its notes
  • And all the variants, relating to how many people can initiate spending of escrowed notes; whether all possible “spenders” need to be known in advance; etc etc.