Mining Candidate Distribution and Pool Software
https://player.vimeo. com/video/674783106
Periodically, a node generates a block template, or a set of transactions with a complete Merkle tree. Using this template, it can create mining candidates for hashing. Each mining candidate is a aggregate of the parameters in the block header, including the previous block hash, the version of the block, the difficulty value and the timestamp. This is distributed plus some specific data the node uses to track the hasher being allocated the template.
https://player.vimeo. com/video/649540250
These mining candidates are distributed to systems which control ASIC miners. These systems are often referred to as ‘pool-miners’ or ‘hash-pooling systems’.
When a pool-miner requests a mining candidate from a node, it is given the following information:
id - A universally unique identifier (uuid - link to https://en.wikipedia.org/wiki/Universally_unique_identifier) representing an assignment ID which identifies which pool a winning block hash was generated by
prevHash - A 32 byte string representing the previous block’s hash
A suggested coinbase transaction including the input string and any outputs the node requests (optional parameter)
version - A 4 byte string representing the version of the block
coinbaseValue - An 8 byte number representing the value of the combined outputs in the coinbase transaction in Satoshis
nBits - A 4 byte number representing the target difficulty
time - The time in 4 byte Unix epoch time accurate to 1 second
height - A varInt containing the height of the candidate block
merkleProof - An array containing a list of hex strings that represent the Merkle path for the coinbase transaction
https://player.vimeo. com/video/649540299
With these values, the pool-miner has all of the information it needs to perform an unbounded amount of proof-of-work.\
Last updated