QRL Message transaction encoding — QRL Message transaction encoding
List of supported encoding bytes for various services using QRL message transactions. Based upon QIP002. For an encoded message transaction to be valid, the first two bytes of the 80 byte message body must be (in hex), “0x0F0F”. The next two bytes of the message denote the encoding of the specific message type. i.e. where the encoding for specific message type is (in hex) “0x0000”, a valid hexstring message would be: 0F0F 0000 <remaining 76 bytes of message> Supported encoding bytes for specific message type (hex) 0000 - reserved 0001 - reserved 0002 - keybase 0003 - github QIP 002 A standard message encoding format to indicate encoded data in MessageTransaction transactions QIP: 002 Layer: 2 Title: MessageTransaction Encoded Message Standard Author: Scott Donald Comments-Summary: Comments-URI: https://github.com/theQRL/qips/pull/4 Status: Open Type: Proposal Created: 2018-11-03 Updated: 2018-11-12 Abstract The QRL network supports arbitrary messages up to 80 bytes in length to be stored on chain through the MessageTransaction transaction subtype. There is the capability for second layer clients to read and interpret the data contained within these message transactions, and format interfaces accordingly. This can be seen with the currently implemented Document Notarisation transaction type found on both the QRL Wallet and QRL Explorer applications, and further implemented in the explorer-helpers repository. Motivation This QIP aims to create a new base layer for a standard message encoding format such that other usecases have a framework to build within - for example the coinvote proposal mentioned by @surg0r. Specification The following will describe the base requirements to indicate a message contains encoded data, and provide further context on earlier usage as has been implemented in the Document Notarisation transaction type. There are a total of 80 bytes available in a MessageTransaction transaction that are usable. For the purposes of describing the format in this document, we will represent all data as HEX strings. It is worth noting however that the data is later converted to binary bytes for storage by a QRL node. To indicate a message is an encoded message, the first two bytes are reserved for the following HEX string: 0F0F The subsequent two bytes should indicate a unique encoded message transaction type. Each proposal to the community for a new encoded message type will be allocated a unique HEX string for these bytes for client implementations. Eg: 0001, AA01 etc. The remaining 76 bytes contain any data relevant to the encoded message, and should be proposed to the community through a QIP. If this QIP is accepted, a record of accepted message transaction sub type and their respective QIP should be kept updated on docs.theqrl.org such that client implementations have the technical detail available to implement with ease. A Github repository will be setup on https://github.com/theQRL/standard-message-encoding to allow community pull requests into this standard encoding format. Document Notarisation Specification The following describes the structure of the Document Notarisation message transaction sub type for historical purposes. There are approximately 25 transactions from early stages of the network that utilise this format. It is optional to implement for display purposes. First 2 Bytes: AFAF - Indicates encoded message. Subsequent Half Byte: A - Indicates this is a document notarisation message transaction sub type. Subsequent Half Byte: 1, 2, or 3 indicating which hash function has been used to notarise the document as per below: `1` - SHA1 (Now deprecated in user interfaces when notarising a document) `2` - SHA256 `3` - MD5 (Now deprecated in user interfaces when notarising a document) The remaining 77 bytes are reserved for both the hash of the document, and a variable amount of free form text depending which hash function was use. For each hash function above, the following describes the remaining 77 bytes utilisation. `1` - SHA1 - Subsequent 20 bytes store the SHA1 hash, with the remaining 57 bytes available for free form text. `2` - SHA256 - Subsequent 32 bytes store the SHA256 hash, with the remaining 45 bytes available for free form text. `3` - MD5 - Subsequent 16 bytes store the SHA1 hash, with the remaining 61 bytes available for free form text. Implementation No immediate implementation work is required for this QIP as it simply states a standard for encoding messages using the QRL networks MessageTransaction transaction type. Eventual work will be required in any client implementations that wish to adhere to the standard encoding format, such as the public QRL Wallet or Block Explorer