[ZIP 302] Standardized Memo Field Format

[arcalinea]

Fixes https://github.com/zcash/zcash/issues/1849
Fixes #366

[arcalinea]

Updated, needs ACK or review

[zookozcash]

Hold on, @arcalinea , you wrote that if the first byte is 0xF6 then it is an empty memo, but what if the other bytes are not 0x00? We don't want an undocumented channel of undefined information there.

[zookozcash]

Someone just asked me for this standard. My vague memory is that I had a few issues with the version in this pull request, and I intended to submit some revisions to the spec myself... Maybe something from my draft that I didn't think was correctly integrated into this draft ? I vaguely remember that one thing I didn't like was that this draft allowed multiple possible encodings of certain things, e.g. "there is no memo here" could be encoded by either an empty string or a special flag byte, or something, and I wanted to squeeze out as many such redundancies or ambiguities as possible and make it so that there was only one legal encoding for "there is no memo here" and only one legal encoding for as many other things as I could think of.

Anyway, I'm going to give the requester (an important software developer partner) a link to this github comment as a stopgap. ¯\(ツ)/¯

It would be great to get this finalized as a ZIP! I think the next steps are:

1. Someone check whether the encrypted memo emitters of whyrusleeping's's https://github.com/whyrusleeping/zmsg, and radix42's's zcash4win, and ZcashCo's MagicBean are compliant with one or both of these draft specs (this draft, my draft). If either of them is emitting encrypted memo fields that are incompatible with either of these specs, then we should probably change the spec to accept the memos generated by those two tools. I nominate @arcalinea to do that, or to delegate to someone else to do so, or to kick it back to me.

2. Someone figure out if my half-remembered complaint about this draft allowing multiple ways to do things is legit and if so see if they can outlaw as many such alternatives as possible. I nominate, uh, @daira to do that, or to delegate it to someone else to do so, or to kick it back to me.

3. Someone who is neither me nor @arcalinea generally just go over the ZIP spec draft with a "completeness, precision, and clarity" comb. I nominate @str4d to do that, or to delegate it to someone else, or to kick it back to me.

4. Then we post the results to the 3 or so parties who are actually writing encrypted-memo-using software (including this new one that sparked this comment) and see if they see any problems in it. I'll do that when we get to this step.

[zookozcash]

P.S. Oh, here is an important detail: for step 1 in #105 (comment), check how zmsg and how zcash4win (BeanStalk) and how zcashd (MagicBean) encode the case that the user did not specify any encrypted memo. That is the "there is no memo here" meaning, and I fondly wish that all three of them will turn out to be doing the same thing in that case, because we could then specify that thing as the one and only legitimate way to say "there is no memo here". But if they are doing different things in that case, then we need to specify multiple ways to mean "there is no memo here" and then specify which of those is the preferred way going forward and then ask the other tools to change to start emitting the preferred way.

[nathan-at-least]

I propose we merge this draft into master with as little editing as possible, consistent with my broader request in #135 to do that for all existing proposals.

Also, I would like for it to have a short unique human-friendly identifier (probably a ZIP number) even though this is in proposal status, so that I can refer to it elsewhere, such as tickets like zcash/zcash#2933 where I currently have hyperlinks.

[zancas]

I concur with @nathan-at-least my current process for accessing the draft is to visit this URL and click "Files changed".

This process is not convenient for sharing.

[zancas]

@daira @nathan-at-least @arcalinea
It seems to me that the scope of work proposed by @zookozcash #105 (comment) maps fairly well to a set of github issues.

I've been pondering a reasonable organization for said issue set. One possible approach (the simplest?) would be to open the issues in this repo, and have a tag associated with the ZIP (proposal).

My intention is to poke around this repo looking for policies about "issues". If it's consistent with whatever I find, and no-one objects, I will open 1 issue for each of @zookozcash 's first 3 list items. Again barring objection, I will tag each issue "ZIP 302".

[zancas]

See @zookozcash 's comment: #105 (comment)

[zancas]

@daira I have a couple of questions for you (when you get a chance):

(0) Do you have a set of memo fields, or memo-field like datasets you'd like to see (or have already seen) submitted to e.g. git tag v1.1.0 zcash-cli?

(1) For purposes of submitting malformed memo fields to consumers:

e.g. non-zero padded,
more than 512 bytes,
non-hexencoded,
utf-8 with invalid continuation-or-start bytes etc.

to e.g. http://z-board.net/

do you have a recommended approach (a python, or pytest module, or howto/readme link)? Should I be looking somewhere in zcash/qa/rpc-tests, and git annotate mentions you (also @zookozcash suggested you would be expert in this context).

[adityapk00]

ZecWallet is currently using several "conventions" that I would love to standardize in the memo field as well.

• If the memo field (string) starts with zcash:, it interprets it as a payment request, and ZecWallet presents it as a Zcash Payment URI to the receiver, that they can pay. It is used as a way to "request money"

• If the memo field (string) ends with ReplyTo:[sapling address], ZecWallet shows a "reply" button, allowing the receiver to reply to the memo, by sending a ZEC 0.0001 transaction to the reply to address. The reply itself also contains a ReplyTo:[sapling addres], containing the address that the receiver would like to be replied to.

• I would also like to add an invoice description of some sort to a recurring payment's memo, so that the receiver of a recurring payment can decode from the memo:

  • Payment number of Total Payments
  • Invoice Number or any other identifying field that the merchant originally presented for this recurring payment

What's the best way for me to contribute to this ZIP? Should I submit a pull request to this branch?

[str4d]

@adityapk00 please submit a PR with a new ZIP draft. This ZIP is for the generic memo field encoding, while your suggestions are specific use cases that would reference this ZIP (if only to say that your use cases would just use the text version of the memo field).

[nuttycom]

Request for clarification of the 0xF5 case.

[nuttycom]

Reviewed and ACK'ed with @daira