0

What are the list of all the variables whose values that the miner can cycle or modify to get a valid hash for this block (with very high probability) ? The only one I am aware of is:

  1. Nonce - 4 Bytes.

But since Nonce is just 4 bytes it is simply not enough for generating many potential hash candidates that pass the difficuly condition of SHA256 (256 bits).

What are the other variables that can be tweaked for ensuring the existence of a passing hash candidate (with very high probability)?

P.S. We are assuming that all the hashes are calculated immediately so timestamp for each candidate is same. Thus, timestamp wont be able to help as far as I understand.

I am struggling with this for a while and can't find much detailed answer for this (other than nonce).

Improve this question
1

1 Answer 1

Reset to default
2

ExtraNonce: As well as the Nonce field, There is also an extranonce convention - a part of the unlocking script in the input of the coinbase transaction is used as an extra nonce by miners.

Timestamp: The miner can vary the timestamp. It only has to be accurate within about 2 hours. It doesn't have to be greater than the timestamp of the previous block.

Version: Miners can vary a part of the version number. There is a method known as ASICboost which helps miners who are using ASICs for mining.

Coinbase output: The miner can vary the coinbase output. Perhaps selecting a different receiving address or varying the type of script.

Transaction order: The miner can vary the order of transactions (other than for transactions that spend outputs of prior transactions in same block).

Transactions: The miner can make an arbitrary select of transactions from their mempool or create their own new arbitrary valid transactions to include. If inventing their own transactions they can vary the fee from zero to maximum and can vary the transaction type from legacy to latest. They can also vary the input amounts from near zero to whole UTXO. The transactions must be valid but that still allows a vast range of variations, assuming the miner owns some bitcoin to start with.

From Bitcoin for Developers I

Table 2. The structure of a coinbase transaction input

Size Field Description
32 bytes Transaction Hash All bits are zero: Not a transaction hash reference
4 bytes Output Index All bits are ones: 0xFFFFFFFF
1–9 bytes (VarInt) Coinbase Data Size Length of the coinbase data, from 2 to 100 bytes
Variable Coinbase Data Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height
4 bytes Sequence Number Set to 0xFFFFFFFF

See also BIP-34

Improve this answer
5
  • Thank you. I get the generic idea but I am not clear on the specifics or structure of some things: such as Extranonce, the coinbase script part. Can you please point to a resource where its discussed in details and is more specific (for implementation level details)?
    – J.Doe
    Aug 21, 2021 at 10:38
  • The ExtraNonce isn't a "field", it's more a practice. The entire scriptSig of the coinbase transaction input is freely chosen by the miner (except that it has to be between 2 and 100 bytes long, and subject to BIP34's requirement that it starts with a push of the block height). Miners use this field to put messages in, but since very early on, part is also used as an additional overflow nonce field. There are no consensus rules governing this, just miners choosing to use the coinbase scriptSig this way.
    – Pieter Wuille
    Mar 19 at 13:50
  • @Pieter: Thanks, updated.
    – RedGrittyBrick
    Mar 19 at 13:57
  • 1
    In the more recent past, miners have also been using the version field as a source of entropy per Overt ASICBoost.
    – Murch ♦
    Mar 19 at 19:01
  • @Murch: Thanks, updated.
    – RedGrittyBrick
    Mar 19 at 21:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.