Bitcoin Forum
April 26, 2017, 04:36:17 AM *
News: Latest stable version of Bitcoin Core: 0.14.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: History of Hardforks and Rollbacks in Bitcoin  (Read 8811 times)
amesterdamer
Sr. Member
****
Offline Offline

Activity: 318

Designer and CryptoCurrency Enthusiast.


View Profile
July 20, 2014, 11:33:51 PM
 #1

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:

Quote
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


Quote
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!
1493181378
Hero Member
*
Offline Offline

Posts: 1493181378

View Profile Personal Message (Offline)

Ignore
1493181378
Reply with quote  #2

1493181378
Report to moderator
1493181378
Hero Member
*
Offline Offline

Posts: 1493181378

View Profile Personal Message (Offline)

Ignore
1493181378
Reply with quote  #2

1493181378
Report to moderator
1493181378
Hero Member
*
Offline Offline

Posts: 1493181378

View Profile Personal Message (Offline)

Ignore
1493181378
Reply with quote  #2

1493181378
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1493181378
Hero Member
*
Offline Offline

Posts: 1493181378

View Profile Personal Message (Offline)

Ignore
1493181378
Reply with quote  #2

1493181378
Report to moderator
1493181378
Hero Member
*
Offline Offline

Posts: 1493181378

View Profile Personal Message (Offline)

Ignore
1493181378
Reply with quote  #2

1493181378
Report to moderator
1493181378
Hero Member
*
Offline Offline

Posts: 1493181378

View Profile Personal Message (Offline)

Ignore
1493181378
Reply with quote  #2

1493181378
Report to moderator
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2632


View Profile
July 21, 2014, 12:52:26 AM
 #2

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2170



View Profile
July 31, 2014, 08:46:26 AM
 #3

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.

Quote
- 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
Legendary
*
Offline Offline

Activity: 1428


Franko is the Future.


View Profile WWW
June 09, 2015, 10:00:39 PM
 #4

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

Fortune favors the brave. - Publius Terence
Fair, Scarce, and Fast. Meet Franko
Franko ★  Expanse To The Moon NewsJoin the Expanse SlackHow to get free bitcoins
pereira4
Legendary
*
Offline Offline

Activity: 966



View Profile
June 09, 2015, 10:25:50 PM
 #5

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
Hero Member
*****
Offline Offline

Activity: 492


View Profile
June 10, 2015, 12:16:23 PM
 #6

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.)

If I've said anything amusing and/or informative and you're feeling generous:
1GNJq39NYtf7cn2QFZZuP5vmC1mTs63rEW
defaced
Legendary
*
Offline Offline

Activity: 1428


Franko is the Future.


View Profile WWW
June 10, 2015, 04:15:22 PM
 #7

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.

Fortune favors the brave. - Publius Terence
Fair, Scarce, and Fast. Meet Franko
Franko ★  Expanse To The Moon NewsJoin the Expanse SlackHow to get free bitcoins
kai2005
Newbie
*
Offline Offline

Activity: 1


View Profile
April 22, 2016, 05:22:29 PM
 #8

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
Donator
Legendary
*
Offline Offline

Activity: 1330


I outlived my lifetime membership:)


View Profile WWW
February 12, 2017, 01:48:32 AM
 #9

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.

Hardfork aren't that hard.
1GCDzqmX2Cf513E8NeThNHxiYEivU1Chhe
Carlton Banks
Legendary
*
Offline Offline

Activity: 1610



View Profile
February 12, 2017, 07:44:35 AM
 #10

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.

Vires in numeris
franky1
Legendary
*
Offline Offline

Activity: 1666



View Profile
February 12, 2017, 06:29:12 PM
 #11

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

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Don't take any information given on this forum on face value. Please do your own due diligence & respect what is written here as both opinion & information gleaned from experience. If you wish to seek legal FACTUAL advice, then seek the guidance of a LEGAL specialist.
masterofmyself
Newbie
*
Offline Offline

Activity: 1


View Profile
March 15, 2017, 08:14:45 PM
 #12

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
Administrator
Legendary
*
Offline Offline

Activity: 2632


View Profile
March 16, 2017, 03:33:10 AM
 #13

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!