Add 8-bit 'Memo Type' to indicate type of data in Memo Field about zips HOT 14 CLOSED

Out of scope! We're past spec freeze. A type field was considered and we decided to do the 0xF5-0xFF thing instead. I believe that allows plenty of space for future expansion. Also, a note plaintext has to be fixed-length for any given protocol version, to maintain indistinguishability.

from zips.

Ok, we can close this issue. However, I do think that since the protocol specifies a memo field of 128 bytes, at first glance developers might expect to be able to make full use of that field. Has there been any consideration given to explicitly labelling the first byte a control/flags/magic field and setting the memo length to 127 bytes? The note plain text would then look this:
[8-bit version] [64-bit v] [256-bit p] [256-bit r] [memo control 1 byte] [memo 127 bytes]

from zips.

I think it's too late to make such changes. We did discuss this in considerable detail before the spec freeze.

from zips.

Can we link to the earlier discussion, Daira? I can't remember where it was.

FWIW, Simon, I too preferred a more explicit type field, but we settled on the current spec.

Note that both the typing information (however it is encoded) and the memo field contents have to be encrypted and visible only to privileged clients (who have the description key) so this part of the spec can't impact consensus rules.

Also note that I still want to increase the size of the memo field. Is there a ticket open for that possible change? I don't see one...

from zips.

Hm, I'm thinking more about #54 (comment). I think people actually can use the entirety of the memo field (currently 128 bytes, but I want to enlarge it), because they can use some out of band signalling to know what sort of data to expect in memo fields, including the encoding type (utf-8, binary, etc.) as well as the actual meaning (human-entered memo, computer-generated sequence number, Travel Rule KYC information, BLAKE2 hash of a payment order, etc.).

from zips.

The discussion of the size of the memo field was on zcash/zcash#85 . The discussion of how it was encoded was mainly in engineering meetings IIRC; there's a little bit about that on the ticket but I don't think all of the points made in meetings were recorded.

I'm resistant to reopening consensus spec issues at this stage, but I won't object to doing so if @nathan-at-least (as engineering project manager) agrees. If we decide to do that then we should reopen zcash/zcash#85 and mark it "engineering meeting agenda". This will have a schedule impact (about one day, I estimate).

from zips.

Incidentally, relying on out-of- band information to encode non-UTF-8 data with a first byte of 0x00-0xF4 in a memo field is a clear violation of the current spec on the sender's part. Conformant software receiving such a memo will decode it as UTF-8, with U+FFFD replacement characters indicating any encoding errors. (The spec is unclear on how many U+FFFD characters per error; I'll fix that to make it deterministic.)

from zips.

People might be tempted to use all 128 bytes for raw data and violate the current spec given there is no penalty other than the software displaying funny looking characters and a note is not (yet) rejected if the memo begins with 0xF6-0xFF.

Perhaps the note version byte could look like this?

[ 1 bit (0=raw, 1=UTF-8) ] [ 3 bits for protocol extension ] [ 4 bits for version of encoding of note plaintext ]

from zips.

The current spec isn't fully implemented, but notes with a first byte of 0xF5-0xFF will not be displayed (or maybe they will be but in hex; not sure yet). I don't see why people would violate the spec; there is a perfectly conformant way to send 127 bytes of arbitrary data already.

from zips.

It's hard to predict what people will do. Counterparty used to create multi-sig transactions with fake pubkeys to transmit data, which polluted Bitcoin's UTXO set.

from zips.

@nathan-at-least Can you make a decision about whether this is in scope, please?

from zips.

Will do.

from zips.

@nathan-at-least ping

from zips.

Past consensus freeze.

from zips.