Permalink
Switch branches/tags
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
74 lines (43 sloc) 2.89 KB
CIP: 11
Title: Shorten Transaction Type ID Namespace
Authors: Devon Weller
Status: Accepted
Type: Standards Track
Created: 2017-06-04
Discussions-To: https://counterpartytalk.org/t/cip-11-discussion-shorten-transaction-type-id-namespace/3108

Abstract

Save 3 bytes of space in every transaction by shortening the number of bytes allocated to the message type ID from 4 bytes to 1 byte.

  • Applies to all transaction types
  • Remains backward compatible
  • Allows for extension

Motivation

Each Counterparty message allocates 4 bytes to the message type ID. But Counterparty only uses 14 of the 4 billion possible message types. We should shorten the message type ID to 1 byte. This will save 3 bytes in every transaction.

Rationale

All used message type IDs require a single byte. We will only read 1 byte instead of 4 bytes as the message type ID.

If the type ID is 0 (0x00) then 4 bytes will be read. See Backwards Compatibility.

Example

Before

434e545250525459|00000001|000000000004fadf000000174876e800000000000000000000000000
       |             |          |
       |             |          └── Message specific data (variable number of bytes)
       |             └──────────────── This is the transaction type identifier (4 bytes)
       └───────────────────────────────── The string CNTRPRTY in hexadecimal (8 bytes)

After

434e545250525459|01|000000000004fadf000000174876e800000000000000000000000000
       |          |        |
       |          |        └── Message specific data (variable number of bytes)
       |          └────────────── This is the transaction type identifier (1 bytes)
       └──────────────────────────── The string CNTRPRTY in hexadecimal (8 bytes)

Backwards Compatibility

If the first byte of the type ID is 0 (0x00), then 4 bytes will be read as the message type ID.

Standard send messages have a type ID of 0, so they will not be able to take advantage of the new, short transaction type ID. Standard send messages must still use a 4-byte type ID of 0x00000000. Enhanced sends are the successor to the standard send message and are expected to form the majority of the send transaction traffic.

Keeping the 4 byte message type as an option ensures backward compatibility with alternate clients that form Counterparty transactions. It also provides a simple means for the future expansion to more than 255 message type IDs.

This is a consensus change that will require all users running Counterparty software to upgrade by a certain block to be chosen after implementation is complete.

Implementation

In development...

Copyright

This document is placed in the public domain.