Bitcoin’s open-source developers don’t agree on many things, but you’d be forgiven if you thought something best known as an “attack” might be one of them.

Still, there’s a divide forming in conversation surrounding bitcoin’s long-standing “timewarp attack” – and for good reason. First and foremost, Blockstream co-founder Mark Friedenbach recently found that the exploit could be harnessed to help bitcoin scale – that is, reach more users and process more transactions faster, if developers embrace and implement the idea.

But since its unveiling last week, the discovery has driven a shift in the conversation around the attack, meant to describe how miners might submit blocks featuring timestamps that are larger than they should be to push down the difficulty of creating new blocks (a trick that could help them to earn and collect more bitcoin rewards).

The result is that prominent thinkers in the bitcoin development community now appear split on an issue that’s been the subject of discussion since 2012..

Greg Maxwell, a Blockstream co-founder and one of bitcoin’s most prominent developers, for example, recently called for a fix to the long-standing bitcoin attack on the bitcoin mailing list, the leading gathering point for development conversation globally. Maxwell has been silent on Friedenbach’s proposal specifically, but the call did occur after chatter began about the research, formally called “forward blocks.”

As a result, this divide might be likely to continue.

Friedenbach’s research, after all, proposes an idea that developers seeking to secure the protocol find enticing: It allows bitcoin’s block size to be increased without asking all of those operating the software to upgrade. (Seeing as this minor parameter has been a hot point of contention among the community for so long, some see it as a sort of “breakthrough.”)

That said, some argue Friedenbach’s new research makes fixing the attack even more pressing.

Time traveling

To begin, however, it helps to understand why the attack exists to begin with.

Individual actors (miners) on the network report the time an event happens – when a transaction was made or when a block was created. So, there’s a small chance someone can manipulate the time a little bit, even while following the rules of the bitcoin code that network nodes are constantly checking.

As such, miners report blocks with the wrong time on occasion. It’s easy to tell because every once in a while, a block rolls in with a timestamp that’s earlier than the block before it (essentially appearing out of order).

To explore why this happens, blockchain analysis company Chainalysis recently pulled together a report exploring how the error rates have changed over time.

“The declining error over time in timestamps reflects the evolution of people getting involved,” Gradwell, who co-authored the report, told CoinDesk, arguing that according to the data, timestamp errors seem to “spike” when the mining industry sees a technology shift.

For example, when miners started joining together to form “pools” early on in 2012 the percentage of timestamp errors rose to 8 percent of timestamps.

Gradwell argues that this data suggests the errors are accidental, rather than done for malicious reasons, as miners need to get used to new equipment.

The timewarp “attack” is a bit different, though, in that it requires much more specific manipulation by miners who twist the rules in the hopes of earning money. This can happen when miners collude together to report incorrect timestamps that are farther apart, messing with the rate at which blocks can be mined.

Luckily, this attack is difficult to execute.

“I, and I assume others, haven’t put a big priority into fixing this vulnerability because it requires a majority [of mining] hashrate and could easily be blocked if someone started using it,” Maxwell said.

In the case where one group of miners were to collect most of the hashrate, a time attack would be the least of bitcoin’s worries. (“And then there will be other problems,” as Chainalysis chief economist Philip Gradwell put it in conversation with CoinDesk.)

For one, it would mean centralization of the network. And the main thing that is supposed to set bitcoin apart from other cryptocurrencies is that it isn’t controlled by any one entity. Not to mention, at this point, the miners in power would be able to perform what’s known as a “51 percent attack,” thereby using their numbers to exert influence over the network.

The proposals

But even if it’s difficult to execute, developers see it as a problem, one that can be fixed easily if so desired.

In his call for proposals, Maxwell mentioned that he had an idea that he tried out on bitcoin’s testnet years ago, but he wants to make sure there isn’t some other, better idea out there before plugging away at his fix.

“Before I dust off my old fix and perhaps prematurely cause fixation on a particular approach, I thought it would be useful to ask the list if anyone else was aware of a favorite backwards compatible timewarp fix proposal they wanted to point out,” Maxwell continued.

“Backwards compatible” is key here. The requirement is for the change to not have a chance of splitting the network.

At Maxwell’s request, a few different proposals have trickled in.

Bitcoin Core contributor Johnson Lau put forward a couple of ideas, both good and bad, to show the tradeoffs of various approaches. He argued that the most “naive” approach would be to just require a block to not submit a time lower than the block before it.

But since this would require a certain type of change, it could lead bitcoin’s software to split into two versions. Lau argues the trick is finding a solution that decreases the likelihood of a timewarp attack, while also not risking a split.

“The aim is to find a [time value] which is small-enough-to-prohibit-time-warp-attack, but also big-enough-to-avoid-split,” he said, adding that he thinks this can be accomplished with a “weaker” version of this naive approach.

Lau’s idea even sparked a little philosophical discussion about “soft forks,” a backwards-compatible way of making such a code change in bitcoin, and how different types can have different consequences.

“In general, soft forks are better when they don’t cause orphaning on non-upgraded miners,” wrote BitTorrent creator Bram Cohen, who’s been focusing his developer efforts on cryptocurrency these days.

All in all, though, he supported Lau’s proposal, but argued for a time window of three hours. “It suffers from still allowing the attack a little bit, but three hours out of every two weeks seems like no big deal,” Cohen said.

Another developer, Scott Roberts, submitted a proposal that turned out to not be “off the mark” for bitcoin in particular, he told CoinDesk. In the end, he agrees with Cohen, though he thinks three hours might be “too tight.”

“I don’t know what the decision will be, but I think the fix is as simple as limiting timestamps to plus or minus something like three to 24 hours from the previous timestamp,” Roberts said.

Another idea

But the problem is that eradicating the time warp attack would ruin forward blocks.

“‘Fixing’ the time-warp attack in the sense of making time warp impossible would prevent entirely forward blocks from achieving on-chain scaling. It might still be worth deploying for the proof-of-work upgrade or increase censorship resistance of sharding,” Friedenbach told CoinDesk, adding:

“But the main advantage [of scaling bitcoin] which excites people would be gone.”

Thinking about this, Friedenbach came up with another proposal, one that would preserve forward blocks, but would expunge the “worst exploits” of the timewarp attack. He went on to argue it “could be deployed early to prevent reckless exploitation of the time-warp bug,” he added.

But many bitcoin technologists seem unsure that pure forward blocks are worth preserving.

Blockstream CEO Adam Back argues that while he thinks it’s interesting research, he’s not sure the community would support it.

“I think it’s useful to explore the technical possibilities, which is what Mark has done. But the main limitation is, will there be consensus for making a big tradeoff of decentralization, censorship-resistance and self-validation cost for brute-force layer1 scale,” Back told CoinDesk.

While forward blocks are interesting because they increase bitcoin’s capacity without a hard fork, a type of change that could split bitcoin in two, it’s still forceful.

And since forcing through a change that not everyone wants and could decrease decentralization was a key reason why the community fought so zealously in bitcoin’s years-long scaling debate, Back argues the community wouldn’t take this type of a change lightly either.

He went as far as to argue that “there are likely simpler, less hacky approaches” than Friedenbach’s to boost bitcoin’s layer-one scale.

With this type of criticism still rolling in, it seems to be an ongoing discussion, as Friedenbach continues to argue forward blocks are worth preserving as a tool:

“The dangerous outcomes of the time-warp bug can be prevented without fixing the bug entirely, and therefore without blocking off forward blocks or related scaling solutions.”

Clock photo by Srikanta H. U (@srikanta) on Unsplash