<p>Blocks have a field in the block header which is the time stamp. However this time stamp is set by the miner and can really be changed to whatever they want (although there is some restriction).</p>

<blockquote>
  <p>Can anyone elaborate on what and how is this fiddling carried out?</p>
</blockquote>

<p>BIP 9 has a start time and a timeout time which indicate the time period that a proposal can be signaled for. This times are based on the Median Time Past (MTP) which is the median time of the last 11 blocks as reported by their time stamps. Since miners can manipulate the time stamps, they can change the time stamps on their blocks so that the MTP is never past the signalling start time or so that the MTP is past the signalling timeout. This can delay signalling from starting and end signalling quicker.</p>

<blockquote>
  <p>Why does this raise the difficulty significantly?</p>
</blockquote>

<p>The difficulty is calculated by looking at the block time stamps. The difficulty is adjusted so that 2016 blocks happen over 2 weeks. The difficulty will rise if the last 2016 blocks were found in less than 2 weeks, and it will drop if they were found in more than 2 weeks. If miners were to increment their time stamps so that each block had a time stamp of 1 second after the last block, the difficulty retarget algorithm would think that 2016 blocks had been found in 2016 seconds so the difficulty would increase to compensate for this perceived fast blocks.</p>

CC BY-SA 3.0
2017-07-06T03:40:07.940Z
don't full nodes reject blocks that have timestamp 2 hours off their respective Unix time?
sanket1729
CC BY-SA 3.0
2017-07-06T06:03:59.647Z
The 2 hour restriction is only future looking, i.e. you can't have blocks that are 2 hours ahead of you. However the median time most strictly increase, but that has no effect on a restriction on time stamps before your node time.
Ava Chow
CC BY-SA 3.0
2017-07-05T17:50:25.467Z
2017-07-05T17:50:25.467Z
Ava Chow
<p>In bitcoin mailing list , a proposal had the following concern. </p>

<blockquote>
  <p>BIP 09 is vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically)</p>
</blockquote>

<p>Can anyone elaborate on what and how is this fiddling carried out? Why does this raise the difficulty significantly? </p>

<mining-theory><block-header><bip><bip9-version-bits>
How can miners alter timestamps to prevent or delay BIP09 feature activation?
sanket1729
# How can miners alter timestamps to prevent or delay BIP09 feature activation?

(Asked by: username_0 on 2017-07-05)

In bitcoin mailing list , a proposal had the following concern.

> BIP 09 is vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically)

Can anyone elaborate on what and how is this fiddling carried out? Why does this raise the difficulty significantly?

**Tags:** mining-theory, block-header, bip, bip9-version-bits


---

## 1 answers

### Answer by username_1 on 2017-07-05. Score: 1 | Accepted answer

Blocks have a field in the block header which is the time stamp. However this time stamp is set by the miner and can really be changed to whatever they want (although there is some restriction).

> Can anyone elaborate on what and how is this fiddling carried out?

BIP 9 has a start time and a timeout time which indicate the time period that a proposal can be signaled for. This times are based on the Median Time Past (MTP) which is the median time of the last 11 blocks as reported by their time stamps. Since miners can manipulate the time stamps, they can change the time stamps on their blocks so that the MTP is never past the signalling start time or so that the MTP is past the signalling timeout. This can delay signalling from starting and end signalling quicker.

> Why does this raise the difficulty significantly?

The difficulty is calculated by looking at the block time stamps. The difficulty is adjusted so that 2016 blocks happen over 2 weeks. The difficulty will rise if the last 2016 blocks were found in less than 2 weeks, and it will drop if they were found in more than 2 weeks. If miners were to increment their time stamps so that each block had a time stamp of 1 second after the last block, the difficulty retarget algorithm would think that 2016 blocks had been found in 2016 seconds so the difficulty would increase to compensate for this perceived fast blocks.

> **Comments:**
> **username_0**: don't full nodes reject blocks that have timestamp 2 hours off their respective Unix time?  
> **username_1**: The 2 hour restriction is only future looking, i.e. you can't have blocks that are 2 hours ahead of you. However the median time most strictly increase, but that has no effect on a restriction on time stamps before your node time.  

---

