ZIP 302: Structured memos

[str4d]

No description provided.

[nuttycom]

ACK

[daira]

Strictly speaking this can't be more than 507, because the 0xF5 || type || length is encoded as at least 3 bytes for length <= 252 and 5 bytes for lengths > 252, therefore the maximum is 512 - 5. But it's correct as stated because we only need a conservative upper bound.

[sellout]

It’s probably not worth squeezing out the extra couple bytes, but we could store 512 - length instead of storing length, which gets us a range 0..509, so then payloads over 260 bytes only require one byte for the “length”, and smaller payloads require three (which they aren’t using anyway).

[sellout]

I think the ZIP mixes up the encodings it mentions – the type is stored as CompactSize (1–9 bytes), and the length is stored as VarInt (which fits a value of 508 in 2 bytes, not 3). I found https://bitcoin.stackexchange.com/a/114585, which explains the encodings better than the Bitcoin docs do.

However, just using a regular 2-byte length

• also leaves 508 bytes for the memo;
• is simpler; and
• is consistent with the nested type || length in [ZIP ???] Multipart Memos #247, which says “Total length of encoded multipart memo (2 bytes, as a 16-bit little-endian integer)”.

The multipart length obviously gets no benefit from a variable-length encoding, so I think we should just use a non-variable length 2-byte uint here as well.

[daira]

ACK

[str4d]

In ZIP Sync today, we decided that:

• We would specify the multi-TLV format using prefix byte 0xF7.
  • Concatenated TLV tuples.
  • Type code 0x00 is an optional "no more TLV tuples" marker, after which everything must be 0x00 (i.e. fixed padding).
• We would abandon 0xF5 as "for legacy private agreement", and document that newer applications should prefer 0xFF which is unambiguously for this purpose.
  • We decided that using up another top-level prefix byte here is fine, because it opens up the typecode space significantly (it adds >250 new single-byte typecodes that can encode 509 bytes, which is not a significant reduction from the 511 bytes that a top-level prefix byte can encode).

[str4d]

I've replaced the old contents of this PR (which just reverted the prior content that was removed from the original ZIP 302 PR) with an initial draft following what was decided in ZIP Sync almost 2 years ago.