Mining

Mining is the process that adds new blocks to the blockchain, making it difficult to alter the history of transactions.

Introduction

Currently, there are two main forms of mining:

  • Solo Mining: In solo mining, the miner works independently to generate new blocks. If successful, the entire block reward and any transaction fees go to the solo miner, resulting in potentially larger payouts, but with higher variance — meaning longer periods between payments.
  • Pooled Mining: In pooled mining, the miner combines resources with others to find blocks more frequently. The rewards are shared among the pool participants, typically based on the amount of computational power they contributed. This results in smaller, more frequent payments with lower variance.

Solo Mining

As shown below, solo miners typically rely on BitcoinEvo Core bitcoinevod to receive new transactions from the network. Their mining software periodically queries bitcoinevod using the “getblocktemplate” RPC, which provides a list of new transactions along with the public key where the coinbase transaction (the mining reward) should be sent.


Solo BitcoinEvo Mining


The mining software then constructs a block based on this template (explained below) and creates a block header. It sends this 80-byte block header to its mining hardware (usually an ASIC) along with the target threshold, which reflects the current difficulty level. The mining hardware runs through every possible nonce value for the block header and generates the corresponding hash.

If none of the hashes fall below the threshold, the mining hardware requests an updated block header from the mining software. This new header includes a different merkle root by adding extra nonce data to the coinbase transaction.

However, if the hardware finds a hash below the target threshold, it sends the block header along with the successful nonce back to the mining software. The mining software then combines this header with the full block and sends it to bitcoinevod to be broadcast to the network and added to the blockchain.

Pool Mining

Pool miners follow a similar process, which is illustrated below. Mining pools allow operators to distribute rewards among miners based on their contribution to the pool’s efforts. The mining pool obtains new transactions from the network using bitcoinevod, and each miner’s software connects to the pool to request the necessary information for constructing block headers.


Pooled BitcoinEvo Mining


In pooled mining, the mining pool sets a target threshold that is significantly higher (easier) than the network difficulty. This causes the mining hardware to generate many block headers that don’t meet the network threshold for inclusion in the blockchain but do meet the pool’s target, proving that the miner processed a portion of the hash values.

The miner then sends this information to the pool, including proof that the header hashes below the pool’s target and that the block of transactions (linked by the header’s merkle root) is valid according to the pool’s criteria (usually ensuring that the coinbase transaction rewards the pool).

This data, referred to as a share, proves the miner contributed a portion of the work. Occasionally, some shares will also be valid under the network’s threshold, allowing the mining pool to submit these blocks to the network for inclusion in the blockchain.

The block reward and any transaction fees earned from mining are paid to the pool, which then distributes a portion of these rewards to the individual miners based on how many shares they contributed. For example, if the pool’s target threshold is 100 times easier than the network target, 100 shares are needed to create a valid block, allowing the pool to pay out 1/100th of its reward for each share received. Different pools may use various reward distribution methods based on this share system.

Block Prototypes

In both solo and pool mining, the mining software must obtain the necessary information to construct block headers. This section describes the linear process by which that information is transmitted and used. However, in practice, parallel threads and queuing are utilized to ensure that ASIC miners operate at maximum efficiency.

getwork RPC

The earliest and simplest method was the now-deprecated BitcoinEvo Core getwork RPC, which directly constructs a header for the miner. Since a block header contains only a 4-byte nonce, capable of generating around 4 gigahashes, modern miners often need to make dozens or even hundreds of getwork requests per second. While solo miners on v0.9.5 or earlier can still use getwork, most mining pools now discourage or prohibit its use.

getblocktemplate RPC

A more advanced method is the BitcoinEvo Core getblocktemplate RPC, which provides the mining software with far more detailed information:

  • The data necessary to create a coinbase transaction that pays either the pool or the solo miner’s bitcoinevod wallet.
  • A full list of transactions that bitcoinevod or the mining pool recommends including in the block. This allows the mining software to review the transactions, add additional ones if desired, and even remove non-required transactions.
  • Additional details necessary for constructing the block header for the next block, including the block version, previous block hash, and bits (difficulty target).
  • The mining pool’s current target threshold for accepting shares (or the network target for solo miners).


The mining software then uses this information to add a nonce to the coinbase transaction’s extra nonce field and assembles all the transactions into a merkle tree, which is used to generate a merkle root for the block header. Whenever the extra nonce field needs to be updated, the software rebuilds the relevant parts of the merkle tree and updates the timestamp and merkle root fields in the block header.

Like all bitcoinevod RPCs, getblocktemplate is sent over HTTP. To ensure miners receive the most current work, many use HTTP longpoll to keep a getblocktemplate request open continuously. This enables the mining pool to push a new getblocktemplate to the miner whenever a new block is discovered on the peer-to-peer network or the pool wants to send updated transaction data to the mining software.

Stratum

A commonly used alternative to getblocktemplate is the Stratum mining protocol. Stratum is designed to provide miners with only the essential information they need to independently construct block headers:

  • The data required to create a coinbase transaction that pays the mining pool.
  • The necessary parts of the merkle tree that need to be re-hashed in order to generate a new merkle root whenever the coinbase transaction is modified with a new extra nonce. Only the relevant portions of the merkle tree are sent, reducing the total data to about a kilobyte, given current transaction volumes.
  • All additional block header information needed to build the next block, aside from the merkle root.
  • The mining pool’s current target threshold for accepting valid shares.


Upon receiving the coinbase transaction, the mining software appends a nonce to the coinbase extra nonce field, hashes the transaction, and adds this hash to the provided parts of the merkle tree. The tree is re-hashed as needed to create the merkle root, which is then added to the block header. When the extra nonce field needs updating, the mining software re-hashes the modified coinbase transaction, reconstructs the merkle root, and updates the header’s merkle root field.

Unlike getblocktemplate, miners using Stratum cannot inspect or modify the transactions included in the block they are working on. Additionally, the Stratum protocol operates over a two-way TCP socket, meaning miners don’t need to rely on HTTP long polling to receive instant updates from mining pools when new blocks are discovered on the peer-to-peer network.