Target

The target is a number that a block hash for a candidate block must get below before the block can be added on to the blockchain.

It is used during the process of mining.

The target adjusts every 2016 blocks (roughly two weeks) to try and ensure that blocks are mined once every 10 minutes on average. This creates a consistent time between blocks, and a consistent issuance of new bitcoins (via the block reward).

Period

When does the target adjust?

The target adjusts every 2016 blocks.

This is roughly every two weeks.

Blocks are mined roughly every 10 minutes, and there are 20,160 minutes in two weeks.

History

Here are the block heights and target values for every target adjustment in Bitcoin's history:

^* The adjustment ratios in this table are calculated based on the change from one target to the next. The actual adjustment ratios are calculated based on the time between blocks. See each block for details.

Adjustment

How is the target calculated?

tool-6629484472519

Target Adjustment

Calculate the next target value based on the current target and the time between blocks.

Previous Adjustment

Current Target

0x

0 bytes

Time (seconds)

Actual

0d

Expected

0d

The target adjustment period is 2016 blocks. A block is mined on average every 600 seconds (10 minutes), so the expected time is 2016 * 600 = 1209600 seconds.

Ratio

The actual time divided by the expected time. We multiply the current target by this ratio to get the new target.

New Target (Full Precision)

0x

New Target

0x

0 bytes

Note: This target value has been truncated slightly for storage in the bits field of the block header, and that's the target value that's actually used when mining.

0 secs

The target for the first block was set at:

This initial target value is hard-coded in to the source code of every Bitcoin node (see chainparams.cpp). It's also the maximum possible target value. It was most likely a best-guess by Satoshi at what be a good starting point for a difficult-enough target that would result in a 10-minute interval between new blocks.

On every 2016th block, each node will look at the time between the previous 2015 blocks and work out if they were mined faster or slower than 10 minutes on average.

Each block contains a timestamp in its block header. This timestamp is in Unix Time, which is the number of seconds since 01 Jan 1970, 00:00:00.

If blocks during this period were mined faster than every 10 minutes, the target will adjust downwards to make it more difficult to get below the target for the next period of blocks.

Conversely, if blocks were mined slower than every 10 minutes, the target will adjust upwards to make it less difficult to get below the target for the next period of blocks.

As a result, each node regularly recalculates the target to maintain a 10-minute average interval between new blocks as miners join and leave the network over time.

See the code at the bottom of the page for a worked example.

Synchronisation

How do nodes calculate the same target?

Each node on the network operates independently, so there is no central authority to determine the current target value.

However, because nodes always adopt the longest chain of blocks as their blockchain, they will each calculate the same target.

For example, when you run Bitcoin for the first time, your node will perform the initial block download and calculate the targets as it goes. And because you're receiving the same blocks as everyone else, you will end up calculating the same current target when you reach the tip of the blockchain.

Furthermore, all nodes continually update to the same version of the blockchain (as they will always adopt the longest available chain of blocks). Therefore, nodes will also calculate the same target value as each new block is mined.

As a result, despite the fact nodes calculate the target independently, they each share the same blockchain and calculate the same target value as each other.

Purpose

Why does Bitcoin use a target?

The target regulates the speed at which new blocks are added on to the blockchain.

This has two benefits:

1. It gives blocks time to propagate across the network.

It's preferable to have miners working on extending the same chain of blocks as much as possible. For this to work, we need to allow time for new blocks to propagate across the network before the next block gets mined.

If blocks are being mined faster than they can be broadcast across the network, it will result in miners regularly working on top of "old" blocks in the blockchain (because they haven't had chance to receive the latest blocks yet).

This will result in miners building multiple competing blockchains; only one of these will become the longest, so some miners will end up wasting energy working to build on top of a competing chain only for it to be left behind due to a chain reorganisation.

Therefore, this time delay (block interval) allows blocks to propagate the network so that more miners can adopt the longest available chain, which helps to concentrate the network's mining power on extending the same chain of blocks.

2. A consistent issuance of new bitcoins.

Bitcoin is a currency, so having a fixed rate of new bitcoins introduced in to the system helps to provide stability.

So thanks to the target, you can be confident that new bitcoins will be minted at a predictable rate.

Location

Where can you find the target?

The target gets stored in the bits field in the block header of every block.

The bits field is a compact representation of the target (to save space in the block header). But you can easily convert between the bits representation and the full target.

Commands

$ bitcoin-cli getblocktemplate '{"rules": ["segwit"]}' | grep target

"target": "0000000000000000000331db0000000000000000000000000000000000000000",

$ bitcoin-cli getdifficulty
88104191118793.16

$ bitcoin-cli getblockheader 000000000000000002e9533a4fe03bb251b3fdb30ffaa384aad133b7fae594cf
{
  "hash": "000000000000000002e9533a4fe03bb251b3fdb30ffaa384aad133b7fae594cf",
  "confirmations": 425677,
  "height": 401184,
  "version": 4,
  "versionHex": "00000004",
  "merkleroot": "b4afa0502a55fdfa4a5cda6ea2bc546ba527d276ea9c7e848b8cd478cd9b6607",
  "time": 1457133956,
  "mediantime": 1457132303,
  "nonce": 3778923481,
  "bits": "1806f0a8",
  "difficulty": 158427203767.3917,
  "chainwork": "00000000000000000000000000000000000000000012da32364c8f47d519604d",
  "nTx": 845,
  "previousblockhash": "000000000000000003c4a4d9c62b3a7f4893afe14eef8a6a377229d23ad4b1ea",
  "nextblockhash": "00000000000000000037ab74c8db9b7a9d7de039210d8eafaeb44ba35adfb624"
}

Code

Here's some example Ruby code for calculating target adjustments.

This code works out the new target for block 403,200, using the timestamps from blocks 401,184 and 403,199.

# 403,200 - NEW TARGET
# 403,199              | last block
#		               |
#                      |
#                      |
# 401,184 - NEW TARGET | first block (target = 0x000000000000000006f0a8000000000000000000000000000000000000000000)

# 1. Get the timestamps for the first and last block in the target adjustment period
first = 1457133956 # block 401,184
last  = 1458291885 # block 403,199

# 2. Work out the ratio of the actual time against the expected time
actual = last - first     # 1157929 (number of seconds between first and last block)
expected = 2016 * 10 * 60 # 1209600 (number of seconds expected between 2016 blocks)
ratio = actual.to_f / expected.to_f

# 3. Limit the adjustment by a factor of 4 (to prevent massive changes from one target to the next)
ratio = 0.25 if ratio < 0.25
ratio = 4 if ratio > 4

# 4. Multiply the current target by this ratio to get the new target
current_target = 0x000000000000000006f0a8000000000000000000000000000000000000000000
new_target = (current_target * ratio)

# 5. Don't let the target go above the maximum target
max_target = 0x00000000ffff0000000000000000000000000000000000000000000000000000
new_target = max_target if new_target > max_target

# 5. Truncate the target, because the official target is the truncated "bits" format stored in the block header
# This code is a bit rough, because it's working with strings when I should really be working with actual bytes.
new_target = new_target.to_i.to_s(16) # convert from decimal to hexadecimal
new_target = new_target.size % 2 != 0 ? '0' + new_target : new_target # make sure it's an even number of characters (i.e. bytes)
truncated = new_target.scan(/../).each_with_index.map { |byte, i| byte = i >= 3 ? "00" : byte }.join # set all bytes apart from first 3 to zeros
# e.g. 6a4c316c01f354000000000000000000000000000000000 <- full precision
# e.g. 6a4c3000000000000000000000000000000000000000000 <- official target

# 6. Display the full target (with leading zeros)
target = truncated.rjust(64, '0')
puts target
# 000000000000000006a4c3000000000000000000000000000000000000000000

Off-by-one error. Target adjustments are actually calculated using the time across 2015 blocks (e.g. 403199 - 401184 = 2015), and not across 2016 blocks as you would expect. This is an implementation error in the code, and it still exists today.

Official Target. The actual target that miners need to get below when mining is the truncated target that gets stored in the bits field. So it's not actually the full-precision target that you get after a target adjustment calculation.

FAQs

Why 10 minutes between blocks?

I don't think anyone except Satoshi knows why 10 minutes was chosen exactly.

My guess is that it seemed long enough to allow blocks to propagate around the network (to minimize chain reorganisations), and short enough to not have to wait too long new transactions to get mined on to the blockchain.

And 10 is a nice round number.

What causes blocks to be mined faster or slower than every 10 minutes?

Firstly, mining is unpredictable, so you never know when a miner is going to find the next block with a block hash below the current target.

Secondly (and most importantly), miners can join and leave the network at any time, which affects the speed at which blocks can be mined. For example, the more miners that join the network, the more hashing there will be taking place, and the more likely it is a new block will be mined in under 10 minutes.

Resources

• pow.cpp – The function CalculateNextWorkRequired() adjusts the target.
• chainparams.cpp – The initial (and maximum) target value is set by consensus.powLimit.
• https://en.bitcoin.it/wiki/Target
• How is the target in Bitcoin set? Who does this? (bitcoin.stackexchange.com)
• Why not retarget on every block?
• Why was the target block time chosen to be 10 minutes?
• Gaming the "off-by-one" bug (difficulty re-target based on 2015 instead of 2016 block time span)?

Thanks

• Thanks to David Harding for pointing out that you can get the target directly from bitcoind using bitcoin-cli getblocktemplate.