executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
bitcoin-mining-difficultyDifficulty adjustment algorithm: 2016-block re-target window, max 4x factor, time-warp considerations, real-world hashrate dynamics. USE WHEN: predicting next adjustment, understanding hashrate/ difficulty cycles, building mining analytics.
Independent GitHub snapshot · Automated classification · Original documentation governs
Bitcoin re-targets the difficulty every 2016 blocks to maintain ~10-minute average block time despite hashrate fluctuations.
def next_difficulty(current_difficulty, actual_time, expected_time):
# actual_time = sum of block_n.timestamp - block_(n-2015).timestamp
# expected_time = 2016 * 10 * 60 = 1,209,600 seconds
factor = expected_time / actual_time
factor = clamp(factor, 0.25, 4.0) # 4x max change per epoch
return current_difficulty * factor
Implemented in pow.cpp:CalculateNextWorkRequired() in Bitcoin Core.
Sequential blocks must have:
block.timestamp > MTP(last 11 blocks).block.timestamp ≤ network_time + 2 hours (avoids future-dated
blocks).These rules limit miner manipulation of timestamps to game the adjustment.
Typical adjustments: 0.5% to 5% per epoch in normal conditions. Large adjustments (10%+) signal major hashrate event (region ban, ASIC manufacturing surge, etc.).
hashrate_estimate = difficulty * 2^32 / 600 # H/s
Where 2^32 = full nonce space probed for one solution at expected
target, and 600 seconds = average block time.