The Time Warp: How Lying About the Time Could Break Bitcoin's Difficulty

Where you're going: Bitcoin has no clock. Miners write the time into every block, and every two weeks the network sets its own difficulty from two of those times. A line in Satoshi's 2009 code leaves a seam between those two-week windows that a miner with most of the hash rate could use to drive difficulty to its minimum within weeks, and one with all of it in under six. This chapter covers how Bitcoin keeps time, how a miner could lie, what would follow, where it has happened, why the fix has waited since 2011, and whether to worry.

Several blocks a second

On Friday 9 September 2011 a forum user called Lolcust announced GeistGeld, a coin built from Bitcoin's code, as "an experimental currency intended to test out the limits of block generation rate empirically". By the evening of Monday 12 September it was producing blocks far faster than anyone had planned. Its creator wrote on BitcoinTalk at 20:09 UTC that "another run-in of same kind is in progress", and ten minutes later a miner reported, "Looks like 20k+ blocks again."

At 21:39 UTC a developer who posted as ArtForz explained how. A coin like this resets its difficulty, how much work a block takes, at fixed intervals, and that reset, he wrote, "ignores one block interval every period". A miner could use the gap to make a chain "jump backwards in time" without breaking a single timestamp rule. He walked through it on a toy chain with four-block windows and then added, "This was done on the GeistGeld chain yesterday/today, so it's not a theoretical problem."

By 12:30 UTC on 13 September his fix was in GeistGeld's code, under a comment that ends "Code courtesy of Art Forz". At 15:06 UTC Gavin Andresen, then Bitcoin's lead developer, raised it on the bitcoin-dev mailing list.

The flaw ArtForz was describing came from a line of Satoshi's code, which GeistGeld had copied. Bitcoin had the same seam in September 2011, and it still has it in November 2026. It is now called the time warp attack, and nobody has used it on Bitcoin's main chain.

How Bitcoin keeps time without a clock

Each miner writes a time, the block's timestamp, into the block header it is working on, and no rule requires it to be right. The network puts two limits on the number instead.

The floor looks back. A block must be stamped later than the median time past, the middle value of the previous eleven blocks' stamps, or every node rejects it as time-too-old. Because every new stamp has to beat it, the median never moves backwards, though it can stand still. Time locks use the same median, under BIP-113. Single stamps can run backwards, and often do. In every header we pulled on 2 November 2026 from the Bitcoin Core node behind ChainQuery, 16,248 of 974,264 blocks, about one in sixty, carry a time earlier than the block before them, and all of them are valid.

The ceiling comes from each node's own clock. No node accepts a block stamped more than two hours ahead of it. Satoshi's first release headed its time code with an old sailors' rule, "Never go to sea with two chronometers; take one or three," and named three for each node: its system clock, the median of its peers' clocks, and time servers it did not yet consult. Since Bitcoin Core 27.0 (April 2024, pull request #28956) the node uses the computer's own system clock, no longer adjusted by what its peers report, and since 28.0 (pull request #29623) it warns its operator when its outbound peers' median clock is more than ten minutes off.

Inside those limits the difficulty adjustment, or retarget, does its arithmetic; the mining chapter covers difficulty from the start. Bitcoin counts blocks in windows of 2,016, about two weeks at ten minutes a block. At the end of each window, every node subtracts the window's first timestamp from its last, two times that miners chose, and compares the result with two weeks, 1,209,600 seconds. A window that took one week doubles the difficulty; one that took four weeks halves it. No single step may exceed a factor of four. That clamp has been hit once in Bitcoin's history, upward, at block 68,544 on 16 July 2010, after a window of 3.35 days.

One line, two quirks

The retarget was not always built this way. A copy of Satoshi's code dated mid-November 2008 looked back 30 days at a target of one block every 15 minutes, changed difficulty only by doubling or halving it, counted every gap between blocks, and required each block to be stamped later than its parent. The white paper describes "a moving average targeting an average number of blocks per hour", closer to that draft than to what shipped.

When 0.1.0 came out on 9 January 2009, about eight weeks later, it had fixed windows of 2,016 blocks, the factor-of-four clamp, the eleven-block median in place of that every-block-later rule, and this loop for finding a window's first block:

for (int i = 0; pindexFirst && i < nInterval-1; i++)
    pindexFirst = pindexFirst->pprev;

From the window's last block it steps back nInterval-1, or 2,015, times to the window's own first block. The same arithmetic is line 42 of src/pow.cpp in Bitcoin Core v32.1, and it has two effects.

The first is an off-by-one. A window of 2,016 blocks has only 2,015 gaps between its first and last stamps, and the code compares those gaps with 2,016 times ten minutes, so in effect it aims for two weeks divided by 2,015, or 600.3 seconds a block. A statistical effect that Pieter Wuille wrote up in 2019, crediting Ian Goldberg, adds about as much again, for an average of about 600.6 seconds at constant hash rate. Neither shows in practice, because hash rate keeps growing; real blocks have averaged about 577 seconds since 2009.

The second is the seam. Because the loop stops at the window's own first block, no block belongs to two windows, and nothing compares the last block of one window with the first block of the next except the median rule, which lets a single block carry a time well before its neighbors'. So the first block of a window can be stamped far earlier than the block before it, and the retarget will measure the whole window from that early stamp. Under the November 2008 rule, with every block later than its parent, that could not have happened.

Bending the clock

What follows is a simulation. We wrote Bitcoin Core's retarget arithmetic in Python, checked that it reproduces all 483 retargets in Bitcoin's history exactly, and gave one attacker all the hash rate, starting from the difficulty set on 29 October 2026, about 148 trillion. Day 0 is the last honest block, the one that closes a window, about 12 November 2026.

From day 0 the attacker stamps every block with the earliest time the median rule allows, so the chain's clock, the time its blocks claim, crawls forward one second for every six blocks, about 5.6 minutes per window, while two real weeks pass. Only the last block of each window gets the real time, because that is the stamp the retarget reads as the window's end. The next block, the first of the new window, drops straight back to the crawl. In window 2 that is 44 minutes before day 0, because the crawl started from the median of the last honest blocks, 50 minutes before day 0. It is valid, because one block far ahead of the rest does not move a median of eleven.

The retarget looks only at the two ends. Window 1 began at day 0, so it measures an honest 14 days and difficulty barely moves. Window 2 is mined from day 14 to day 28, but its first block is stamped before day 0, so the retarget thinks it took 28 days and halves difficulty. Window 3, at half the difficulty, takes seven real days, but it too is measured from before day 0, so it looks like 35 days, and difficulty falls another 60 percent. From then on each window passes two and a half to three times faster than the one before. In the table, T is trillion.

Window	Real days	Difficulty while mined	Minutes per block	Span the retarget sees
1	0 to 14.0	148.4 T	10.0	14.0 days
2	14.0 to 28.0	148.0 T	10.0	28.0 days
3	28.0 to 34.9	74.0 T	5.0	35.0 days
4	34.9 to 37.7	29.6 T	2.0	37.8 days
5	37.7 to 38.8	11.0 T	0.74	38.8 days

In window 5, 2,016 blocks arrive in about 25 hours while the retarget believes they took 38.8 days, and by day 39.4 the chain is making more than ten blocks a second.

How long it takes depends on when the attacker starts. From the beginning of a window, as in our run, difficulty reaches its minimum in about 39.4 days, on 22 December 2026 for a 12 November start; Antoine Poinsot's block-level example of May 2024, also started on a window boundary, came to about 39. Starting about six days before a window ends is a little faster, about 37.4 days, and BIP-54, the proposal that would close the seam, puts the worst case within 38 days.

At the minimum the chain's clock is still more than 39 days behind real time, so neither timestamp rule slows the attacker down. In the model every remaining coin of the block subsidy, about 888,300 BTC that an honest chain would pay out over the next 113 years, comes out on one simulated day. In reality the limit would be how fast the attacker could build some six million blocks and every node could check them. Every time lock counted in blocks would expire with them, from Lightning channel deadlines to vault delays.

Everyone else stands in the way. The attack needs a majority of the hash rate for weeks, in public, and gains nothing until difficulty first falls, on day 28 when the attack starts on a window boundary or about day 20 with the best-timed start. An honest miner who wins the first block of any window and stamps it with the real time gives that window a true starting point, so it measures close to its real length, and every honest stamp in between pulls the median, and with it the attacker's floor, forward. A minority gains almost nothing; Poinsot called the gain from opportunistic timestamp games "ridiculously small for any minority hashrate".

No pool has said it could or would use the time warp. The one pool statement we found is a reply on the Bitcoin mining developers' list, dated 3 September 2024, to a question about testnet4's ten-minute version of the fix: "This would be no problem for MARA Digital Holdings", because the timestamps it uses come from getblocktemplate.

Where it has happened

GeistGeld is the first case on record. Its configuration at the time retargeted every 16 blocks, four minutes per window at its target, so the few windows the attack needs passed in minutes rather than weeks. Its chain no longer exists, so nobody can count what the attacker took.

Litecoin still carries ArtForz's fix. Each window is measured from the last block of the one before, so neighboring windows share a block, and the comment over the code ends as GeistGeld's did, "Code courtesy of Art Forz". Freicoin, also built from Bitcoin's code, has the same change, credited to ArtForz, in a commit with an author date of 6 August 2013, whose title begins "Hardfork: Fix Art Forz's time-traveller attack".

Bitcoin's own testnet carries the only time warp ever mined on a Bitcoin network, put there on purpose. Greg Maxwell wrote on the bitcoin-dev list in December 2012 of "adding the timewarp attack to the testnet chain", and in August 2018: "I put a demonstration of timewarp early in the testnet3 chain". Block 8,063 is stamped 23 July 2012. Block 8,064, the first of the next window, is stamped 28 May 2012, eight weeks earlier. The jump repeats at blocks 10,079 and 10,080. Both windows measured one second more than 56 days, where the clamp takes over, so difficulty fell by the maximum twice, from 16 to 4 to 1. The section was mined in late July 2012, after Gavin Andresen announced testnet3 on 29 May; block 10,078 is stamped 29 July, and no node with a correct clock would have accepted it before that day.

Verge fell to a cousin of the attack in April and May 2018. It could be mined with several different algorithms, and it recalculated each one's difficulty at every block from that algorithm's recent blocks; its code also let a block be stamped up to two hours before its parent. Backdated blocks set against honest ones made an algorithm look far slower than it was, and its difficulty fell until blocks came one second apart. That is a different weakness from Bitcoin's seam, since Verge's difficulty has no fixed windows. Verge's first patch, on 4 April, said fifteen minutes in a comment and set 30 seconds in the code. A stricter rule followed on 5 April, but on 6 April it was deleted and the two-hour allowance came back, so the May attack used the same weakness until a patch on 25 May cut it to ten minutes. Accounts of the coins taken disagree, and we give no figure.

The testnet3 block storms of April 2024, when Jameson Lopp set out to grief testnet and the chain added roughly 221,000 blocks in nine days, came from a different, testnet-only weakness, its minimum-difficulty rule, and no seam in those nine days stepped back more than about 40 minutes.

Bitcoin's own seams

If anyone had tried the time warp on Bitcoin, the seams would show it. At all 483 retargets from block 2,016 to block 973,728, we compared the first block of the new window with the last block of the old one. Ten times, the first block was stamped earlier. The worst was 18 minutes 47 seconds, at block 203,616 on 16 October 2012, and there the block before seems to have been the one running fast, since it is stamped later than the next three. Since 2015 the worst is 43 seconds, at block 812,448 on 16 October 2023. The median seam, 410 seconds, is close to the median gap between one block and the next, 402 seconds.

The attack also needs blocks stamped at the floor, one second past the median. Only 48 blocks in Bitcoin's history were stamped that low, the last at height 156,368 in December 2011. A typical block in 2026 is stamped nearly an hour later than its floor.

The same data tests both versions of the fix. Testnet4's ten-minute rule, BIP-94, would have rejected exactly one block in Bitcoin's history, that 2012 one, unless its miner had stamped it 23:04:55 or later. BIP-54's two-hour rule would have rejected none; the worst seam ever is more than 100 minutes inside it. BIP-54's second timestamp rule, the negative-window rule, says a window's last block may not be stamped before its first, and no block has ever broken it either. We checked all of this two ways with headers from the Bitcoin Core node behind ChainQuery, reading every header in bulk and fetching the 967 boundary headers raw to hash them again, and we checked every negative seam against a public block explorer. Anyone with a node can repeat it with getblockheader, and the full table is a CSV download.

When a difficulty rule did fail

The clearest failure of a difficulty rule happened next door, and it shows what happens when miners can game one. When Bitcoin Cash split from Bitcoin on 1 August 2017, it inherited Bitcoin's difficulty with a small share of the miners, the opening a death spiral needs. Its developers had added an emergency difficulty adjustment: whenever six blocks had taken twelve hours or more, the next block's difficulty fell by 20 percent, and the next block's too while the condition held. The rule could only cut; raising difficulty again was left to the ordinary retarget.

Miners learned to play it. They left the chain until the gaps piled up, came back to cheap blocks, mined them minutes apart until the retarget caught up, and left again. The emergency rule fired 43 times in 104 days, including two runs of six cuts in under four hours, and three retargets hit the factor-of-four clamp. On 28 October 2017 the chain mined 1,254 blocks in one day, and by 13 November, 104.32 days after the split, it had mined 25,473 blocks where the clock allowed 15,022, putting it 10,451 blocks, about 130,600 coins, ahead of schedule. Its 2020 halving came 33 days before Bitcoin's.

Bitcoin felt the waves, because hash rate swinging into Bitcoin Cash was swinging out of Bitcoin. On Sunday 12 November 2017 Bitcoin Cash's chain recorded about as much work as Bitcoin's, by its own record slightly more, and Bitcoin found 80 blocks, where the schedule calls for 144. One node with an unlimited mempool, Johoe's, counted about 48,000 transactions waiting on 9 November and 180,000 on 12 November. The next day Bitcoin Cash switched to a rule that recalculated difficulty at every block from about the last day of work. Another, aserti3-2d, replaced it in November 2020, and even that left the minority chain of that year's split, Bitcoin ABC's, later renamed eCash, crawling at 3 to 8 blocks a day for five days.

Bitcoin's own worst came in 2021, when the shutdown of mining in China took about half the hash rate offline. Difficulty fell at four retargets in a row, by 15.97 percent on 30 May, 5.30 on 13 June, 27.94 on 3 July and 4.81 on 17 July, 45.4 percent in 65.6 days. The window that ended on 3 July took 19.4 days at 13.9 minutes a block, the slowest since difficulty first rose in December 2009 (in 2009, at minimum difficulty, windows took as long as 41.5 days). The window after it ran at 10.5 minutes.

Leaving for twelve hours, which paid on Bitcoin Cash, earns nothing on Bitcoin, and the two hours a miner may stamp ahead can stretch a two-week window by only 0.6 percent. The cost is a slow few weeks whenever hash rate leaves at once, as in the four windows of 2021.

Why it is still there

There are two ways to close the seam. One changes the arithmetic so each window is measured from the last block of the window before, as Litecoin does. Every header must carry exactly the difficulty a node computes, so old and new nodes would reject each other's blocks at the first retarget, a hard fork. The other keeps the arithmetic and adds one rule on the first block's timestamp. Every block that obeys it already obeyed the old rules, so nodes that never upgrade follow the same chain, a soft fork.

On 14 September 2011, in the thread he had opened, Andresen judged a fix that forked the chain "too high risk for too little benefit and shouldn't be done until we have a really compelling reason to introduce a forking change." On 7 November Pieter Wuille sketched the second kind: keep the arithmetic and require the first block of each window to be stamped later than the latest of the eleven blocks before it, "essentially just using a maximum instead of a median". Nobody took it further.

From 2015 to 2017 the fix was filed under the first kind, the harmless hard fork developers kept citing during the block size war. Jorge Timon made it the sample change in BIP-99, his 2015 proposal on how to deploy forks, and wrote on 29 March 2017, "I cannot think of a hf that is easier to implement or has less potential for controversy than that." No hard fork was ever scheduled.

On 20 August 2018 Greg Maxwell reopened the fix as a soft fork and explained the wait: "I, and I assume others, haven't put a big priority into fixing this vulnerability because it requires a majority hashrate and could easily be blocked if someone started using it." In March 2019 Matt Corallo bundled the rule into his Great Consensus Cleanup with several restrictions on transaction scripts, which drew the objection that they could invalidate some pre-signed transactions, and the package stalled. Closing a companion pull request on 29 July 2020, Corallo wrote that "it seems unlikely to be picked back up." On 17 September 2022 Anthony Towns, answering Corallo's complaint the day before about a lack of champions, blamed the process: "If we did have a good answer for how to progress a soft-fork," the cleanup "would have made more progress over the past 3.5 years."

Antoine Poinsot revived the cleanup on Delving Bitcoin on 24 March 2024, and he dismissed the comfort that an attack would be slow and obvious: "a month isn't a lot of time to coordinate and change Bitcoin's consensus rules." Mark Friedenbach, the author of record on that 2013 Freicoin commit, wanted the seam kept. His Forward Blocks proposal of 2018 used a controlled time warp to push more transactions through old nodes without a hard fork, and in April 2024 he argued for keeping that option. Poinsot replied on 18 April that "the cost of not fixing timewarp objectively far exceeds the cost of making 'forward blocks' impossible". Friedenbach held his ground on 30 April, in a later reply in the same thread: "Once thrown, this fuse switch can't be undone."

Corallo's draft let the first block of a window sit up to ten minutes before the block preceding it, the rule testnet4 enforces. On testnet4 some pool software stamped blocks from its own clock instead of the template, so BIP-54's authors chose two hours as a precaution, the same as the ceiling on future stamps, which means a miner stamping the current time can never break the rule. In Wuille's simulation of a sustained attack, the extra slack lets blocks come about three seconds faster: 599.9997 seconds apart with the ten-minute rule, 596.7211 with two hours. Mainnet's worst seam, the 2012 one, would have failed the ten-minute rule, one more reason for the margin. BIP-54 leaves the arithmetic alone, so the off-by-one stays.

As of November 2026, BIP-54 is marked Complete (version 1.0.0, 22 May 2026). Besides the two timestamp rules, it carries three unrelated fixes: a cap on signature operations for blocks built to validate slowly, a ban on 64-byte transactions, and a coinbase rule that retires an old duplicate-transaction check. Bitcoin Inquisition, a version of Bitcoin Core built to try out proposed rule changes, has enforced all of it on signet since block 291,168, stamped 12 February 2026. Bitcoin Core has built block templates, the draft blocks it hands to miners, that respect the time warp rule since 29.0 (April 2025) and the negative-window rule since 32.1 (28 October 2026), so miners using it would not break either rule by accident. The rules themselves, without mainnet activation, sit in Bitcoin Core pull request #35793, which is open and needs updating against current code. Nobody has proposed when or how to activate them; that step runs through the slow, public process Bitcoin uses for every rule change.

What this buys us

Nobody holding bitcoin needs to do anything about the time warp. The attack would be visible for weeks before it paid, it needs a majority of the hash rate that could already censor transactions, and the fix only narrows what counts as a valid block, so nodes that never upgrade stay on the same chain. Bitcoin has moved fast against bugs that were being used, as with the inflation bug of August 2010.

• You know where the clock comes from. Miners write it, between the median of eleven blocks and two hours past each node's clock.
• You know what the attack needs. A majority of the hash rate, weeks of stamps held at the floor in public, and three or four weeks of patience before difficulty first falls.
• You know it has not been tried here. Ten negative seams in 483, none worse than 18 minutes 47 seconds, and no block at the floor since December 2011.
• You know why the fix waits. It is written and tested, and Bitcoin changes its rules slowly on purpose.

Pro tip: If you run a node, keep its clock right. Since Bitcoin Core 27.0 the two-hour limit is checked against your computer's own time, and the release notes put the burden on the operator to keep it correct so the node does not fall out of step with the rest of the network. Turn on automatic time sync and leave it on.