Verge Timestamp Exploit Let a Miner Produce One-Second Blocks

The Verge cryptocurrency network accepted an abnormal sequence of rapidly produced blocks on April 4, 2018 after a miner exploited timestamp and difficulty-retargeting behavior in its proof-of-work code.

A technical disclosure posted by the operator of the Suprnova mining pools showed successive scrypt blocks being accepted approximately one second apart. The disclosed node log included blocks around heights 2,009,406 through 2,009,470, with timestamps alternating between two different time ranges rather than progressing normally.

The incident mattered because Verge promoted the use of five mining algorithms as a way to distribute and strengthen its proof-of-work system. The April 4 activity showed that combining algorithms did not provide protection when the consensus rules governing their timestamps and difficulty adjustments could be manipulated.

How the reported exploit worked

Under Verge’s design, blocks could be mined with scrypt, X17, Lyra2rev2, Myr-Groestl or Blake2s. The reporting miner, using the name ocminer, explained that the protocol was intended to rotate among algorithms rather than permit an uninterrupted sequence from one algorithm.

According to that contemporaneous technical account, an attacker could submit a block carrying a timestamp approximately one hour behind the actual time. The network would then treat the relevant algorithm as though it had not produced a recent block, affecting the difficulty calculation and eligibility of subsequent blocks. Alternating manipulated and current timestamps allowed scrypt blocks to enter the accepted chain in rapid succession.

Ocminer said the abnormal activity had been occurring since approximately 06:00 UTC on April 4. That start time was the pool operator’s observation, not an independently reconstructed network-wide measurement. The surviving logs directly demonstrate accepted one-second block intervals, but they do not by themselves identify the miner or establish the complete duration of the activity.

Verge acknowledged a hash attack

Verge’s official account described the event as a small hash attack that lasted about three hours and said it had been cleared. The project also disputed calling it a 51% attack and maintained that only some blocks were affected.

That terminology remained contested on April 4. The technical disclosure characterized the event as a greater-than-51% attack because the exploiting miner gained effective control over block production. Verge’s statement rejected that description. The verified common ground was narrower: abnormal blocks were accepted, their timestamps were manipulated, and the project responded through its code and public communications.

The official source repository recorded an immediate change to the maximum permitted clock-drift setting. Commit 7294e06 replaced `2 * 60 * 60`, equivalent to 7,200 seconds, with `2 * 15`, equivalent to 30 seconds. The accompanying code comment described the new value as fifteen minutes, which did not match the expression. The commit changed only one line and did not, on its own, prove that every node or mining pool had adopted the new rule.

Because changing block-validity rules can divide nodes that enforce different versions, the response also raised a coordination problem. A patch intended to reject the attacker’s blocks could create a hard fork if deployed without an activation height or broad agreement among miners, exchanges and other node operators.

What was uncertain on April 4

Contemporaneous reports offered sharply different estimates of how many XVG the miner obtained and how long the exploit ran. Some extrapolated millions of XVG from the apparent block rate, while other accounts cited much smaller totals. Those estimates depended on disputed start and end points, block inclusion and the eventual treatment of the affected chain.

No loss total or market return can therefore be stated confidently from the event-day record. The defensible conclusion is that Verge’s live consensus rules accepted a sustained sequence of timestamp-manipulated, rapidly mined blocks and that the first repository response was both immediate and technically controversial.

For a proof-of-work network, that was not merely an application outage. It concerned which blocks counted as valid, who could collect newly issued coins and whether independently operated nodes would continue recognizing the same ledger.