🚀JAX Merged Mining API integration flow description
Provided API simplifies merged mining of the JAX Network with SHA256d
-derived networks (like BTC, BCH, BSV, etc), and are expected to be easily integrated with already deployed mining facilities without impact on hash rate generated. Provided documentation describes all the details needed for successful integration.
Communication and support
As developers, we do understand how important it is to have a direct way of communication with third-party developers during an integration process. We prefer fast and efficient communication channels (like Telegram, Discord, etc) and would set up a communication channel for you ASAP. All you need to do is to notify us via mining@jax.net
Benefits of using API instead of direct mining
Lower complexity Using an API allows you to delegate maintenance of the JAX-nodes infrastructure directly to us. You do not need to have a deep knowledge of how to deploy it, control it, and how to maintain it.
Lower resources consumption (including human resources) You can do and support the integration with the help of the same team that supports your mining facilities. Since there are no additional deployments and components — you will most probably not need additional data center resources or human resources.
HashRate risk-free The proposed integration schema being implemented correctly does not affect the level of the hash rate generated for the original network.
Hash Sorting Filtering
Dealing with multiple shards, JAX Network has introduced a way how to control block propagation problems by distributing blocks generation in time. This affects the mining process, so it should be briefly explained in this doc.
The idea is that to be accepted by some shard, the PoW hash should begin with the required prefix. This prefix is unique for specific the shard (until the total amount of shards is less than Hash Sorting Number
), and can repeat every Hash Sorting number
in other case. For instance, if Hash Sorting Number
is set to 16 (4 bits) then the PoW prefix is 4 bits long. If the network has only Beacon Chain (prefix == 0), and let's say 2 shards (prefixes are 1, and 2) then if the PoW hash of the submitted block begins with 0, 1, or 2 — the submission would be accepted into the Beacon Chain, or Shard 1, or Shard 2 correspondingly. Otherwise — the submission would be ignored.
Taking into account that Hash Sorting affects the difficulty of the shards and Beacon Chain — the idea is to just swap the required amount of bits used by the target to the beginning of the PoW hash and use them as a prefix, so the PoW would look like <
target bits..><hash sorting bits>
Hash Sorting Number
for the Test Net is set to16
.Hash Sorting Number
for the Main Net is set to1024
.
Pool integration of HS
It is strictly suggested for the pool to implement this HS filtering on its side. Otherwise, there would be a huge amount of unusable submissions to the API, which could use the redundant amount of traffic and make significant pressure on the RPC communication layer.
Principal integration schema
As shown on this schema, merged mining API hides the complexity of managing nodes and the infrastructure and proxies 2 RPC methods which allows the mining pool to do merged mining with present sha256d
network.
The flow is as simple as follows:
The mining pool constantly (asynchronously, in a loop) fetches AUX data using the method
getaux
This method provides targets for the beacon and each shard of the JAX network as well as HEX-encoded AUX data.Being fetched this data is then used to form the coinbase TX for BTC, BCH, or BSV (depends on which network is originally mined by the pool) according to requirements specified here. Following these specific requirements is strictly required to make it possible for JAX to be merge-mined with an external
sha256d
network.Once mined up to one of the required targets (the least one is usually used), the pool must pass the newly generated block through the Hash Sorting Filter and then, in case if block passes validation — push it back to the API.
it is not required to mine a real-world BTC/BCH/BSW/etc block that would be valid for these networks. It is totally enough to have a block, that would correspond to one of the received targets, fetched by the getaux
.
API Location & Access
As API providers we do understand that the physical location of the API determines its efficiency for the pool, so we provide several regions to choose: East/West Europe, Middle East, Asia/Pacific. Please contact us and we would consider providing the API in your region.
RPC Methods
This section describes provided RPC methods in detail.
Method — getaux
getaux
Provides AUX data for further inclusion into the coinbase TX according to rules required by the protocol.
beacon_aux_data_hex
— HEX-encoded AUX data, that must be added to the mined block.beacon_target
andshard_targets
define beacon and shards targets correspondingly. (the numberi
inshard_targets
defines shard ID)
Method — submitbtcaux
submitbtcaux
Accepts mined BTC / BCH / BSV / etc block data, validates it and in case of success — creates corresponding JAX network block and submits it to the corresponding shard or beacon chain.
In case of successful request processing, the result
and error
fields would be set to null
Responses auditing
Each response returned from the API contains a signature, that proves it was processed by the API. Corresponding response headers are:
sig
— HEX representation of the signature.timestamp
—RFC3339
representation of the timestamp of the response processing (UTC).
Signature schema
Elliptic Curve used —
ed25519
sig = ed25519(H)
H
— hash of the response, built by chaining another hash (response hash, 32 bytes, see below) and current timestamp in binary form (big endian encodeduint64
— Unix Nanosecond Timestamp format);H = sha256(ResponseH + T)
T
— timestamp of the response processing (on the API side) in the UNIX nano format (int64
)ResponseH
—sha256(jsonResponse)
jsonResponse
— json marshalled response.
Coinbase TX requirements
This section defines requirements for a BTC / BCH / BSV coinbase transaction, that can be a valid Coinbase AUX in beacon chain and shard chain blocks in Jax.Network.
Requirements for Inputs
The protocol requires special markers and proof of inclusion to be present in the signature script of the first tx input.
The signature script marker is
6a61786e6574
("jaxnet" in ASCII hex format).Proof of inclusion is an exclusive hash of the Jax.Net beacon block (could be fetched via API).
They can be at any position of the signature script, but they must follow each other in a row, like this: <marker> <beacon_hash> <marker>
According to the rules of Bitcoin script serialization, in the raw format, the length must be present prior to each part.
Requirements for Outputs
There are 3 ways to craft a Bitcoin coinbase transaction as valid BTC Coinbase AUX for Jax.Network. The only difference between them is in the set of outputs.
ONLY a transaction matching one of these requirements can be used as a BTC Coinbase AUX to create a valid BTC AUX and to mine the Jax.Network block. Valid blocks for the beacon chain and shard chains can be made using these kinds.
If
TYPE_A
andTYPE_B
are used as BTC Coinbase AUX, only BTC and JAXNET block rewards will be issued, while JAX reward will be burnt.If
TYPE_C
is used as BTC Coinbase AUX, BTC, and JAXNET block rewards will be burnt.
TYPE_A
A BTC/BCH/BSV coinbase transaction without jaxnet marker out
.
This type of coinbase can't cause Proof of Burn and issuance of JAX coins (in shards). It can have 1, 2, 5, 6, or 7 outputs.
There is only one requirement:
the address of the first out must have a vanity prefix
1JAX
. Example:1JAXmGDsiE2CyK31dYZsMamM18pPebRDAk
TYPE_C
This type of coinbase contains Proof of Burn and causes the issuance of JAX coins (in shards). It can have only 3 or 4 outputs.
These are the requirements for outputs:
NOTE: if the value of the second output is LESS than 6.25 BTC (current BTC Block reward), the protocol will check that a block fee is LESS THAN OR EQUAL TO 0.5 BTC
Examples
JAXnet Marker Out
jaxnet marker out
is a strict special predefined output that matches the following requirements:
This is the first Tx Out.
Value of this out equals
0
.This out is to the
JaxNet Burn Address
.The address in mainnet is equal to
1JAXNETJAXNETJAXNETJAXNETJAXW3bkUN
(testnet addressmxgUfHYGyYoVEQe95oRfzSaZKHmEPHD7Kr
).PKScript of this out is equal to
76a914bc473af4c71c45d5aa3278adc99701ded3740a5488ac
.
Here it is:
JAXnet Burn Address
JaxNet Burn Address
is the predefined unspendable address.
Vanity Address
Vanity address is a normal Bitcoin PublicKeyHash address that starts with the "JAX" string. For example: 1JAXmGDsiE2CyK31dYZsMamM18pPebRDAk
.
Serialization format
Transaction
Serialized transaction:
Explanation of serialization format:
Signature script
Serialized signature script:
Explanation of serialization format:
Last updated