|
Title: History of Hardforks and Rollbacks in Bitcoin Post by: amesterdamer on July 20, 2014, 11:33:51 PM 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! Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: theymos on July 21, 2014, 12:52:26 AM 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. Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: gmaxwell on July 31, 2014, 08:46:26 AM I think that the only two hardforks were: 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.- The change in the version message which took effect on February 20, 2012 after two years of advance notice. 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. Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: defaced on June 09, 2015, 10:00:39 PM Interesting post. Its wild how the overflow gave someone the ability to allow a value out that exceed the blockreward at the time.
Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: pereira4 on June 09, 2015, 10:25:50 PM 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. Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: Nancarrow on June 10, 2015, 12:16:23 PM 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.) Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: defaced on June 10, 2015, 04:15:22 PM 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. Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: kai2005 on April 22, 2016, 05:22:29 PM 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 Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: bg002h on February 12, 2017, 01:48:32 AM 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. Soft fork=more restrictions. Hard fork = fewer restrictions. 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? Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: Carlton Banks on February 12, 2017, 07:44:35 AM 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. Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: franky1 on February 12, 2017, 06:29:12 PM 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 Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: masterofmyself on March 15, 2017, 08:14:45 PM 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. Title: Re: History of Hardforks and Rollbacks in Bitcoin Post by: theymos on March 16, 2017, 03:33:10 AM 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 (https://bitcointalk.org/index.php?topic=61922.msg725644#msg725644) 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. |