Bits
Compact representation of the target
The bits field contains a compact representation of the target.
It indicates what the block hash has to be below for the block to be mined, and it has to represent the correct target value for the height of the block in the blockchain.
Structure
How does the bits field represent the target?
The bits field has two parts:
- Exponent (First Byte): This is "how far up" the coefficient is.
- Coefficient (Next 3 Bytes): This contains some precision from the full target value.
Converting
How do you convert between target and bits?
Bits to Target
To convert bits to a target, you shift the coefficient the specified number of bytes to the left as indicated by the exponent.
For example:
Bits: 1705dd01
coefficient (05dd01)
------
Target: 00000000000000000005dd010000000000000000000000000000000000000000
<---------------------------------------------
exponent (0x17 = 23 bytes)
Code
# bits
exponent = 0x17
coefficient = 0x05dd01
# target
target = coefficient * 2**(8 * (exponent - 3))
# 2** = using a power of two for bit-shifting
# (8 * = there are 8 bits in a byte
# (exponent - 3) = leave space for the coefficient to fill
# target (hex)
target_hex = target.to_s(16)
puts target_hex #=> 5dd010000000000000000000000000000000000000000Target to Bits
Converting a target to a bits field is the reverse of the bits to target conversion. You take the first 3 significant bytes from the target, then work out how many bytes they're shifted to the left.
For example:
coefficient (05ae3af)
------
Target: 00000000000000000005ae3af5b1628dc0000000000000000000000000000000
<---------------------------------------------
exponent (0x17 = 23 bytes)
Bits: 1705ae3a
Don't forget you're looking for the first significant byte for the coefficient. That's why the first significant byte is 05 and not 5d, as the 5 and d belong to two different bytes.
The first significant byte for the coefficient must be below 80. If it's not, you have to take the preceding 00 as the first byte.
This is because Bitcoin uses a custom encoding for uint256 values; if the 00800000 bit is set then it indicates a negative value. So if this coefficient is above 007fffff, then it's indicating a negative value, and the target can't be negative.
For example, the full target for block 489,888 was:
Target: 000000000000000000eb304f6a76a77000000000000000000000000000000000
However, the first significant byte is eb. This is greater than 7f, so we have to use the 00 byte before it to prevent the coefficient from indicating a negative number:
coefficient
------
Target: 000000000000000000eb30000000000000000000000000000000000000000000
<-----------------------------------------------
exponent (0x18 = 24 bytes)
Coefficient: 00eb30
Exponent: 18
Bits: 1800eb30
If it wasn't for this custom uint256 encoding, the bits field would have been 17eb304f.
That's why some bits fields have a coefficient that starts with 00.
See here: Why 1D00FFFF and not 1CFFFFFF as target in genesis block
Anyway, this target-to-bits conversion is what miners do when creating a bits field for their block header after a target recalculation
You do lose some precision when converting the target to bits. However, the numbers are so large that it doesn't really matter, so there's no need to store the absolute precision of the target in the block header.
The "bits" representation of the target is the actual value that miners need to get below to mine a block.
Benefits
Why do we convert the target to bits?
The bits field saves on space in the block header.
So instead of storing the full 32-byte target, we store a 4-byte compact representation of it instead.
Purpose
Why does the block header contain the target?
There are two main functions of the bits field:
- It's useful for quickly finding out what the target for the block was.
- It's the actual level of precision that the block hash has to get below for the block to get mined. So even if the full target value after a target recalculation has more precision, it's actually the precision of the bits field that the block hash has to get below.
For example, during the target recalculation at block 40,320 this would have been full target:
Target: 00000000654657a76a76a8000000000000000000000000000000000000000000
But the actual target that a miner needs to get below is the amount of precision that can be stored in the bits field, which is:
Target: 0000000065465700000000000000000000000000000000000000000000000000
But as I say, this loss of precision here isn't a big deal. I've never seen a block that has been mined with a hash that is below the truncated target, but above the original target calculation.
However, there was no need for Satoshi to include a compact representation of the target in the block header. Nodes calculate target values internally, so having the target in the block header is redundant.
Nonetheless, that's what Satoshi decided to do, probably as some sort of convenience. Removing it would involve a hard-fork, and it wouldn't be worth the effort, so that's why it's still a part of the block header today.
Terminology
Why is it called "bits"?
I don't know why the field is called "bits". Satoshi never explained the reason behind their choice for the name of this field.
It's a bit awkward though, as a "bit" is the word used for the smallest unit of data (i.e. 8 bits in a byte), which is a bit confusing.
Maybe it's because they were storing some bits from the target (and not the full precision), so "bits" was a quick and easy name for the field. I mean, we all use quick variable names when in the middle of programming, and they don't always turn out to be perfect.