History of Hardforks and Rollbacks in Bitcoin

[amesterdamer]

Hello to all,

I'm trying to gather information about Hardforks and rollbacks that Bitcoin has done in the Past. I'm writing an article but I'm finding hard to gather that information, that's why I ask the help of the community. I think this is a very important subject and it requires a clear list of occurrences like: Date, Cause, Solution

Until now I only could gather this information:

8th August 2010 - 92 billion BTC into existence

On 8th August 2010 bitcoin developer Jeff Garzik wrote what could be mildly described as the biggest understatement since Apollo 13 told Houston: “We’ve had a problem here.”. “The ‘value out’ in this block is quite strange,” he wrote on bitcointalk.org, referring to a block that had somehow contained 92 billion BTC, which is precisely 91,979,000,000 more bitcoin than is ever supposed to exist. CVE-2010-5139 (CVE meaning ‘common vulnerability and exposures’) was frighteningly simple and exploited to the point of farce by an unknown attacker. In technical language, the bug is known as a number overflow error.So instead of the system counting up 98, 99, 100, 101, for example, it broke at 99 and went to zero (or -100) instead of 100. In layman’s terms, someone found a way to flood the code and create a ridiculously large amount of bitcoin in the process.

The fix was the bitcoin equivalent of dying in a video game and restarting from the last save point. The community simply hit ‘undo’, jumping back to the point in the blockchain before the hack occurred and starting anew from there; all of the transactions made after the bug was exploited – but before the fix was implemented – were effectively cancelled.

How serious was it? Bitcoin’s lead developer Wladimir Van Der Laan is pretty blunt about it, telling me: “It was the worst problem ever.”

Source1: http://www.coindesk.com/9-biggest-screwups-bitcoin-history/
Source2: https://bitcointalk.org/index.php?topic=822.0

11/12 March 2013 - Chain Fork Information
What happened: A bitcoin miner running version 0.8.0 created a large block (at height 225,430) that is incompatible with earlier versions of Bitcoin. The result was a block chain fork, with miners, merchants and users running the new version of bitcoin accepting, and building on, that block, and miners, merchants and users running older versions of bitcoin rejecting it and creating their own block chain.

What is being done:Large mining pools running version 0.8.0 were asked to switch back to version 0.7, to create a single block chain compatible with all bitcoin software.

Questions & Answers

I'm not a miner or a merchant, what should I do?
Nothing. Your bitcoin software will switch to the correct chain automatically, no matter which version you are running.

Are my bitcoins safe?
Yes.

What will be done
The core developers have investigated what caused the old versions to reject the new blocks, and have released a 0.8.1 version that avoids creating blocks that are incompatible with older versions. A full post-mortem document has been published.

Source1: https://bitcoin.org/en/alert/2013-03-11-chain-fork
Source2: http://bitcoinmagazine.com/3668/bitcoin-network-shaken-by-blockchain-fork/

I also found this list: https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
but i'm finding hard to identify the ones that had a hardfork / rollback...

So, I ask for help again with this, Can anyone help me with this? It's not only for me but for all the Bitcoin and Crypto Community. Thanks in advanced!

[1714024802]

1714024802

[1714024802]

1714024802

[theymos]

I think that the only two hardforks were:
- The change in the version message which took effect on February 20, 2012 after two years of advance notice.
- BIP 50

The other changes are all softforks.

[gmaxwell]

I think that the only two hardforks were:
- The change in the version message which took effect on February 20, 2012 after two years of advance notice.

This is a hardfork of the P2P protocol, but not the blockchain.  If you setup a protocol adapter (e.g. a node hacked to change its version handshake to bring the old behavior back) a prior release should still sync the chain... though it's been a while since I've done this.

- BIP 50

Sort of a mixed bag there, you can actually take a pre BIP-50 node and fully sync the blockchain, I last did this with 0.3.24 a few months ago. It just will not reliably handle reorgs involving large blocks unless you change the BDB config too. So it's debatable if this is a hard fork either, since it's quasi-non-deterministic. There were prior bugs fixed where older versions would get stuck and stop syncing the chain before that too...

So I think by a really strong definition of creating a blockchain which violates the rules mandated by prior versions we have never had a hardfork.

[defaced]

Interesting post. Its wild how the overflow gave someone the ability to allow a value out that exceed the blockreward at the time.

[pereira4]

Interesting post. Its wild how the overflow gave someone the ability to allow a value out that exceed the blockreward at the time.

It's actually pretty funny that someone owned billions of BTC at some point.
I wonder if we can afford more hard forks after the next one, it seems like such a big deal every time it happens.

[Nancarrow]

Well there's a crucial distinction to be made between
a) Sudden, completely unexpected hard forks due to bugs/unexpected behaviour in the code (bitcoin itself, or ancillary stuff such as database management), and
b) Hard forks predicted and planned several months in advance, due to perceived need to improve weaknesses in the protocol or code or both, and implemented by a consensus-of-miners-switchover

The bazillion-btc and broken-db hardforks that happened in 2010 and 2013 are examples of the former. Increasing the blocksize to 20MB, 8MB or whatever is an example of the latter. In the former everyone could see that the 'new' fork had highly undesirable behaviour and so it was straightforward for the devs to tell everyone to roll back - no one thought the 'new' chain was somehow The One True Bitcoin. In the latter, there is a difference of opinion as to the 'brokenness' of each subsequent chain.

(I know the OP probably wasn't 'going there', but with all the angst at the moment, I think it *needs* to be said.)
(In any case I was mostly responding to pereira4's last sentence.)

[defaced]

Well there's a crucial distinction to be made between
a) Sudden, completely unexpected hard forks due to bugs/unexpected behaviour in the code (bitcoin itself, or ancillary stuff such as database management), and
b) Hard forks predicted and planned several months in advance, due to perceived need to improve weaknesses in the protocol or code or both, and implemented by a consensus-of-miners-switchover

The bazillion-btc and broken-db hardforks that happened in 2010 and 2013 are examples of the former. Increasing the blocksize to 20MB, 8MB or whatever is an example of the latter. In the former everyone could see that the 'new' fork had highly undesirable behaviour and so it was straightforward for the devs to tell everyone to roll back - no one thought the 'new' chain was somehow The One True Bitcoin. In the latter, there is a difference of opinion as to the 'brokenness' of each subsequent chain.

(I know the OP probably wasn't 'going there', but with all the angst at the moment, I think it *needs* to be said.)
(In any case I was mostly responding to pereira4's last sentence.)

Yea, what you say is true.

[kai2005]

hi, I just saw the post. I'm also interested in this topic. I'm doing a research focusing on Bitcoin governance mechanism.

Have you finished the paper? Can you send me one copy? I do fell interested in the history of Hardforks and Rollbacks which require a political decision in Bitcoin.

My email is jken0313@gmail.com.

I appreciate it.

Best.

Kai

[bg002h]

In the early days of the currency, blocks could carry up to 36MB of transaction data apiece. However, in 2010, this was reduced to 1MB.

That is, mining using a node before that change would today produce blocks rejected by recent later versions. This is by definition a hard fork, isn't it?

Soft fork=more restrictions. Hard fork = fewer restrictions.

[Carlton Banks]

In the early days of the currency, blocks could carry up to 36MB of transaction data apiece. However, in 2010, this was reduced to 1MB.

No.

32 MB was the upper limit for network messages, 32 MB blocks were never valid.

Soft fork=more restrictions. Hard fork = fewer restrictions.

Wrong also.

Soft fork=adding new rules that do not conflict with existing rules, hard fork = changing or removing any rules.

[franky1]

In the early days of the currency, blocks could carry up to 36MB of transaction data apiece. However, in 2010, this was reduced to 1MB.

No.

32 MB was the upper limit for network messages, 32 MB blocks were never valid.

Soft fork=more restrictions. Hard fork = fewer restrictions.

Wrong also.

Soft fork=adding new rules that do not conflict with existing rules, hard fork = changing or removing any rules.

wrong
soft = changing the rules without nodes consent. only using pools consent... can cause bilateral split
hard = changing the rules with nodes consent, then using pools consent...  can cause bilateral split

soft consensus = pool agreement at high percentage.. small orphan risk.. one chain after drama
soft controversial = pool agreement at low/mid percentage.. medium/large orphan risk.. one chain after drama
soft bilateral = pool ignores opposing pools.. multiple chain co-existing and not fighting

hard consensus = node AND pool agreement at high percentage.. small orphan risk.. one chain after drama
hard controversial = node AND pool agreement at low/mid percentage.. medium/large orphan risk.. one chain after drama
hard bilateral = node AND pool ignores opposing pools.. multiple chain co-existing and not fighting

[masterofmyself]

Can you guys provide sources for your varying definitions of "soft fork" and "hard fork?"

I've found this: http://bitcoin.stackexchange.com/questions/36090/has-a-hard-fork-ever-occurred

This: https://bitcoin.org/en/glossary/hard-fork

And this: https://www.reddit.com/r/Bitcoin/comments/2s2utx/the_hard_fork_missile_crisis/cnlqcd1/

My very amateur understanding is that there seems to be an amorphous definition of "hard fork" depending on how one is using it. There are instances where a network split is referred to as a "hard fork" relative to the network state, and there are times when it is used to refer to a "software update without backward compatibility." But then Peter Todd (in the above reddit link) argues that we should not even be referring to what happened in 2013 as a "hard fork."

He also argues that a hard fork means "previously allowed behavior is now rejected, for instance creating coins out of thin air." But I think this might not be precise enough, since the previous block size changes were implemented with a soft fork and not a hard fork.

If we can get some consistency, it might provide a stable foundation from which to argue re: the block size debate.

IF bitcoin has never dealt with a hard fork (this would depend on the definition we use), there can be made a substantial argument that if we have no prior experience with measuring the outcomes of a hard fork, we have no way of knowing with certainty the impact of doing so.

[theymos]

Can you guys provide sources for your varying definitions of "soft fork" and "hard fork?"

The first instance of the regex "hard ?fork" on this forum is this post in its link to https://en.bitcoin.it/w/index.php?title=Hardfork_Wishlist&oldid=23227

The rough idea of a hardfork being a change to the consensus rules requiring old nodes to upgrade has remained basically the same forever.

I agree with gmaxwell's old response to my post here classifying the version checksum as a hardfork; since that didn't affect the consensus rules, it wasn't a proper hardfork. It did have very similar effects as a hardfork, though, and it's the closest model to the sort of planned-in-advance hardfork often talked about. I'm on the fence about whether BIP 50 can be classified as a hardfork, and it's also very different from any hardfork that would be planned.