The MTP Stratum Mining Protocol is a modification of the original Stratum Mining Protocol. Where there is missing information, please refer to the original specification for clarification:

• SlushPool - Stratum Mining Protocol
• Bitcoin Wiki - Stratum Mining Protocol

There are 2 primary reasons to modify the protocol. The first is that MTP requires additional data (proofs) to submit shares. The second is that the additional data is quite large.

The MTP proofs are about 200kb per share submission. The current use of UTF-8 hex strings doubles the size of this data. Given the non-fixed and non-trivial expenses of high bandwidth usage, it is necessary to be more efficient with regards to serialization of the data.

Switching to binary serialization will prevent the doubling of bandwidth usage associated with using hex values to represent binary data. The binary serialization format used comes from the BOS serializer.

The BOS serializer uses a relatively simple format that allows for the same flexibility as JSON. It allows implementing the MTP stratum protocol into existing stratum's more easily and can accept future changes and additions to the protocol without causing incompatibility with older implementations or requiring rewrites to the serializer to accommodate.

• 01 - mining.subscribe - After connecting the client will send the mining.subscribe message.
• 02 - mining.authorize - The client should authorize itself using the mining.authorize message.
• 03 - mining.set_target - The server will set the miners share target using the mining.set_target message.
• 04 - mining.notify - The server will send the client mining.notify messages containing new and updated jobs.
• 05 - mining.submit - The client submits shares using the mining.submit message.

In order to prevent the doubling of data size inherent with using hex strings, the MTP Stratum Protocol uses a binary serialization rather than JSON string serialization. The binary serialization format is based on the BOS (Binary Object Serializer) format.

The examples below represent the same exception message. The first example is the JSON Representation and is the JSON string that would be sent using the original stratum protocol. The second example, Binary Overview, shows an abstract overview of how the same data is laid out in binary. The table below that shows the actual byte values to represent the JSON value in binary. Note that all binary values are sent in little endian byte order.

JSON Representation

{
    "id": 1,
    "result": null,
    "error": [21, "Job not found", null]
}

Binary Overview

> OBJECT
--> KEY_0         : UTF-8 string whose value is "id".
--> KEY_0_VALUE   : a NUMBER that is the "id" of the message.
--> KEY_1         : UTF-8 string whose value is "result".
--> KEY_1_VALUE   : NULL
--> KEY_2         : UTF-8 string whose value is "error".
--> KEY_2_VALUE   : ARRAY
-----> ARRAY[0]   : a NUMBER that is the error code of the exception.
-----> ARRAY[1]   : STRING that is a human readable message.
-----> ARRAY[2]   : NULL or traceback data for debugging.

Binary

The complete binary value for the above exception message represented in hex is: 0x2d0000000F03026964060106726573756c7400056572726f720E0306150C0d4a6f62206e6f7420666f756e6400

There are changes to some of the messages to be aware of:

• The response to the mining.subscribe message has been changed. The first element contains the subscription ID and the 3rd element, which contained the ExtraNonce2 size, has been removed. The ExtraNonce2 size should be 8 bytes.
• The mining.set_difficulty message has been changed to mining.set_target along with the type of data it contains.
• The mining.submit message has 3 additional elements appended to the "params" array for MTP proofs.

The key/value pairs in an object may be in any order. Do no assume that the binary order of key/value pairs as shown in examples is the way the data will always be received. Optional object properties or array elements may not even be present.

The DataType used for numbers is the smallest data type that the value will fit into. A larger data type such as UINT16 or UINT32 may be used as required. A larger fixed size may also be used.

NUMBER data types include:

• UINT8
• UINT16
• UINT32

Where the original protocol uses UTF-8 hex strings, the BYTES value should be used rather than STRING value in the MTP stratum protocol. The byte order should be little endian.

The ExtraNonce1 and ExtraNonce2 values are both 64-bits (8-bytes).

• BOS Binary Format - Binary Format Specification.
• BOS Serializer - NodeJS binary object serializer.