Broadcasting notes in token contracts

[spalladino]

Thanks as always for your replies, Mike!

@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?

I’m trying to identify what a vanilla token implementation would look like, to test if the decisions we’ve made on keys make sense. So yeah, an opinionated token standard would be the result of this exercise.

@Mike

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.

@Mike

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

Agree, I noted this as I was finishing the post, hence the section on “compliance”.

@Mike

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

Good point. If we’re not constraining, we can safely call an unconstrained function to get the result, and can just ignore it if it fails.

@Mike

I haven’t quite followed this paragraph, sorry.

Sorry, it ended up quite confusing. My point is that the outgoing key is meant to encrypt “outgoing” data, so we use the outgoing secret key for encryption. However, there are situations where a 3rd party sends outgoing data on behalf of the user, such as in a transferFrom. And since we cannot give the 3rd party the outgoing secret key (because secrets need to stay secret, as you say), the 3rd party would have to encrypt this data with the user incoming public key, or we’d have to design for an outgoing public key.

Nullifiers are a different story: we know from the escrow use case that, in order to allow a 3rd party to spend a user’s notes, those notes need to be nullified with a random secret rather than requiring the owner’s nullifier secret key. So that’s “solved”.

@Mike

• 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.
• Doesn’t this depend on the requirements of the token contract?
• Doesn’t this depend on the requirements of the token contract?

Agree, in all these scenarios the app (token in this case) may have a preference one way or another. Maybe the problem here is that we’re talking about a very general token contract, so requirements are too flexible. Let’s assume we’re working with a utility token, that has no auditability or compliance requirements, which I think would be the most “vanilla” scenario.

@Mike

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

Excellent, I agree, and that makes things easier. The downside of this is that “your tokens you’ve sent” and “your tokens someone else has sent on your behalf” are encrypted using different keys, but that’s not too bad.

@Mike

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:

Sounds good, will tackle this during the week!