diff options
Diffstat (limited to 'bip-0099.mediawiki')
| -rw-r--r-- | bip-0099.mediawiki | 333 |
1 files changed, 333 insertions, 0 deletions
diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki new file mode 100644 index 0000000..9bfc96d --- /dev/null +++ b/bip-0099.mediawiki @@ -0,0 +1,333 @@ +<pre> + BIP: 99 + Title: Motivation and deployment of consensus rule changes ([soft/hard]forks) + Author: Jorge Timón jtimon@jtimon.cc + Status: Draft + Type: Informational | Process + Created: 2015-06-20 + Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html +</pre> + +==Abstract== + +This BIP attempts to create a taxonomy of the different types of +consensus forks and proposes a deployment mechanism for each of them. + +==Motivation== + +The security assumptions of p2p consensus-based systems like Bitcoin are +not always well understood, and the upgrade mechanisms to the +consensus rules are a work in progress that may vary depending on the +type of change being deployed. +Discussing such changes without a uniform view on the deployment +paths often leads to misunderstandings and unnecessarily delays the +deployment of changes. + +==Defintions== + +- Software fork: in free software, an existing project can be copied + and extended/maintained without permission from the original + project's maintainers. +- Consensus fork: a divergence in the implementation of the + verification rules can impede the expected eventual convergence of + the network in a single chain that has the most proof of work and + also satisfies the rules. This can be intentional or be caused by a + bug in consensus validation reimplementations. +- Softfork: an intentional consensus fork where everything that + was previously invalid remains invalid, but some things that were + valid also become invalid. Majority of miners can impose + this kind of changes and they also have some deployment advantages. +- Hardfork: an intentional consensus fork that is not a softfork. + +==Taxonomy of consensus forks== + +===Accidental consensus fork=== + +Software forks are very different in nature from consensus rules forks. No software +maintainer has special powers over consensus rules changes. There's +many good reasons (experimentation, lack of features, independent +development, diversity, etc) to fork the Bitcoin core software and it's good +that there's many alternative implementations of the protocol (forks +of Bitcoin core or written from scratch). + +But sometimes a bug in the reimplementaion of the consensus +validation rules can prevent alternative implementation users from +following the longest (most work) valid chain. This can result in +those users losing coins or being defrauded, making reimplementations +of the consensus validation rules very risky. Note that a natural +language specification of those rules doesn't help since the +consensus is not determined by such specification but by the software +that the majority of the network runs. That's why "the implementation +is the specification". + +But Bitcoin core contains many more things than just consensus +validation and it would be unreasonable for all alternative +implementations to depend on it. Bitcoin core should not be the +specification. That's why the consensus validation is being separated +into a libbitcoinconsensus library with a C API easily accessible from +any language. This makes alternative implementations much more secure +without burdening them with specific design choices made by Bitcoin +core. It is to be noted that sharing the same code for consensus +validation doesn't prevent alternative implementations from +independently changing their consensus rules: they can always fork +the libbitcoinconsensus project (once it is in a separate repository). + +Hopefully libbitcoinconsensus will remove this type of consensus fork +which - being accidental - obviously don't need a deployment plan. + +====11/12 March 2013 Chain Fork==== + +There is a precedent of an accidental consensus fork at height 225430. +Without entering in much detail, the situation was different from +what's being described from the alternative implementation risks (today alternative implementation +still usually rely in different degrees on bitcoin core trusted proxies, which +is very reasonable considering the lack of a complete +libbitcoinsensus). +The two conflicting consensus validation implementations were two +different versions of Bitcoin core (Bitcoin-qt at the time): 0.8 +against all versions prior to it. Most miners had been fast on +upgrading to 0.8 and they were also fast on downgrading to 0.7 as an +emergency when they were ask to by the developers community. + +Without entering in much detail[2], the issue was that BDB was being +abandoned in favor of levelDB, and - at the same time - the miner's +policy block size limit was being lift (it was not a consensus rule, +not even enforced via softfork). Even after testing, a case where +levelDB couldn't correctly validate certain bigger blocks only appeared after +deployment in production. Fortunately this was handled very well and +rapidly by the whole worldwide community and nobody is unhappy about +the solution. + +But there's some philosophical disagreements on the terms of what the +solution was: we can add a pedantic note on that. +If "the implementation is the specification", then those +levelDB-specific limitations were part of the consensus rules. +Then additional rules were necessary and any alternative +implementation (including 0.8) would have to implement it. Then a +planned consensus fork to migrate all Bitcoin-qt 0.7- users could +remove those additional consensus restrictions. +Had libconsensus being implemented without depending on levelDB, +those additional restrictions wouldn't have been "the implementation +is the specification" and this would just have been a bug in the +consensus rules, just a consensus-critical bug in a set of +implementations, concretely all satoshi-bitcoin-0.7-or-less (which +happened to be a huge super majority of the users), but other +implementations (like libbitcoin) would be free from such bug and +implementing the correct libconsensus specification. But since the +buggy implementation was a super-majority, the solution would have +been to instantly (from a specific block) change the rules to not let +the super-majority deviate from the specification and then have +another consensus fork to remove them. Two theoretical consensus forks +instead of one but the first one deployed practically for free. The +practical result would have been identical and only the definitions +change. This means discussing something that went uncontroversially +well further is "philosophical bike-shed" (TM). + +===Unilateral softforks=== + +If it is in their best interest of miners to softfork it should be +assumed that they may likely enforce it. In some cases, even against the will of a +super-majority of users. This is practically an attack on the network +and the only solution is to carefully design the incentives so that +the case is simply impossible. If that fails, miners should still +consider the risk of motivating a schism hardfork before attempting +such a consensus fork. A deployment plan for this case is also +unnecessary. + +===Schism[1] hardforks=== + +In all of the following examples there's clearly a confrontation that +is being resolved using an intentional consensus fork. + +Being a schism hardfork, there will likely be 2 chains +coexisting for at least some time, maybe forever. Maybe bitcoin +becomes bitcoinA and bitcoinB. The implications for market +capitalization are completely unpredictable, +maybe mc(bitcoinA) = mc(bitcoinB) = mc(old_bitcoin), +maybe mc(bitcoinA) + mc(bitcoinB) = mc(old_bitcoin), +maybe mc(bitcoinA) + mc(bitcoinB) = 1000 * mc(old_bitcoin), +maybe mc(bitcoinA) + mc(bitcoinB) = 0, +... + +This is very disruptive and hopefully will never be needed. But if +it's needed the best deployment path is just to activate the rule +changes after certain block height in the future. On the other hand, +it is healthy decentralization-wise that many independent software +projects are ready to deploy a schism hardfork. + +====ASIC-reset hardfork==== + +Imagine ASIC production has been consolidated to a single company and +distribution is simply not happening: the company is keeping them to +mine itself. For that or another reason, a single entity controls +40%+ of the hashrate and there's no hope for an spontaneous +improvement in decentralization. Such an untenable centralization could +be fixed (with great risks) by switching the hash function used in the +proof of work, effectively "pressing the restart button" on the ASIC +market. [The next function should be simple to implement in ASIC as +well so that the market can more easily develop as a healthy and +competitive one (as opposed to what the "ASIC-hard" proponents would +want), but that's another story...] + +Since in this case the confrontation is clearly against the current +miners any notion of "miners' voting" is utterly irrelevant. + +====Anti-Block-creator hardfork==== + +There's less extreme cases where changing the pow function would not +be necessary. For example, let's imagine a bright future where +commoditized ASICs are running in millions home-heaters all over the +world, but the block size has been completely removed and the network has devolved to a +very centralized system where only 2 big pools have the resources to +fully validate full blocks and create block templates with competitive levels of +transaction fees. In that case, changing the pow function would be a +terrible waste and a risk that could be avoided. A hardfork restoring +a block size limit could help fixing this situation. Please don't +take it as an argument for or against raising the block size limit: +it's just an example. But in this case, again, those 2 big pools +would probably be against the fork and, again, their voting is +irrelevant. + +Like in the previous example, miners are expected to oppose and they +have to be ignored. + +====Anti-cabal hardfork==== + +Let's imagine BIP66 [TODO remove has been deployed, but it] had a crypto backdoor +that nobody noticed and allows an evil developer cabal to steal +everyone's coins. The users and non-evil developers could join, fork +libconsensus and use the forked version in their respective bitcoin +implementations. +Should miner's "vote" to express their consent? What if some miners +are part of the cabal? In the unlikely event that most miners are +part of such an evil cabal, changing the pow function may be +required. In other cases, mining "vote" doesn't have much value +either since this kind of hardfork would not qualify as +uncontroversial anyway. + +===Uncontroversial consensus upgrades=== + +"Uncontroversial" is something though to define in this context. What +if a single user decides he won't upgrade no matter what and +he doesn't even attempt to explain his decision? Obviously, such +a user should be just ignored. But what if the circumstances are +slightly different? What if they're 2, 10 users? where's the line. +It is possible that we can never have a better definition than "I know +it when I see it" [citation needed]. + +====Uncontroversial softforks==== + +If a majority of miners adopts a softfork, users will follow that +chain, even without understanding the new rules. For them is like +if blocks are created in a certain way or certain valid transactions +are being rejected by miners for some reason. For old nodes it just +looks like the new rules are policy rules rather than consensus rules. +This greatly reduces the deployment risks, making softforks the +preferred consensus rules upgrade mechanism. + +The first precedent of a softfork was the introduction of P2SH +documented in BIP16. There were competing proposals, but BIP12 had +clear disadvantage and BIP17 was considered a less tested but +functionally equivalent version by most of the reviewers. Although it +was later discovered that BIP16 had unnecessary limitations and BIP17 +is now considered superior, this probably still qualified for our +vague concept of "uncontroversial". + +At the time, there was no "mining voting" implementation and it was +simply deployed using the timestamp of the blocks at some time in the +future as the activation trigger. This can't guarantee the assumption +that most miners have upgraded before enforcing the new rules and +that's why the voting mechanism and first used for BIP30 and BIP66. +The current voting threshold for softfork enforcement is 95%. There's +also a 75% threshold for miners to activate it as a policy rule, but +it should be safe for miners to activate such a policy from the start +or later than 75%, as long as they enforce it as consensus rule after 95%. + +The current miners' voting mechanism can be modified to allow for +changes to be deployed in parallel, the rejection of a concrete +softfork without getting locked for the deployment of the next one, +and also a more efficient use of the version field in block +headers [3]. BIP65 is expected to be deployed with the improved +mechanism. + +====Uncontroversial hardforks==== + +Some consensus changes require all participants to upgrade their software +before the new rules can be safely activated or they will face serious +risk of following the wrong chain and being defrauded. Even if the +exact same mechanism used for softforks would be more risky in these +cases, that doesn't mean that this type of changes cannot be deployed +in an uncontroversial and safe manner. + +The simplest approach is to select a block height far enough in the +future that everybody has plenty of time to change their software. +But if you're aiming for universal adoption, that includes miners' +adoption, so it seems reasonable to use a mining voting on top of +that. In this case there's only one relevant threshold and it could +be different from the softfork one. Probably 100% is too strict, +since it would allow a relatively small miner to attack the network +and block a consensus upgrade. Something between 99% and 95% is +probably a sensible choice for this parameter. + +====Uncontroversial emergency hardforks==== + +Emergency forks may not have time to consult miners and have to be +deployed simply by choosing a block height not so far in the future. + +But emergency forks could be prepared ahead of time. For example, an +intermediary version of software could allow blocks +that are double the size of old blocks (after a certain height in the +future) while still making miners reject bigger blocks as a softfork +rule. Then miners can start the regular process for uncontroversial +softfork (or a unilateral softfork if they're a majority) at any +point in the future if it is required, and both intermediary and new +versions would be prepared for it (which would make deployment much +easier). Other related consensus changes could be deployed in the +meantime (say, quadrupling the block size) making the emergency +softfork unnecessary. + +==Code== + +This BIP is complemented with a concrete code proposal[4] for an +uncontroversial hardfork which acts as a precedent and removes the +perception that hardforks are impossible in Bitcoin. The deployment of +the proposal should not block any other potential hardforks (thus it +will required the version bits proposal[3] to be implemented). The +change itself doesn't add much complexity to Bitcoin Core and is simple +enough that is trivial to apply to diverse implementations (that +currently can only use libbitcoinconsensus to validate script-related +rules). The change has been already widely tested in many altcoins. + +The chosen consensus change is the fix of the timewarp attack +discovered and also fixed with a simple patch[5] by @ArtForz. This +change has been deployed by most altcoins that made any minimally +meaningful change to bitcoin and thus can be considered somewhat +tested (in fact, most SHA256d altcoins that didn't implemented it have +died or being forced to implement it as an emergency hardfork). When +deploying this change has been discussed, usually arguments in the +lines of "if we get to the point when this matters to bitcoin, we +would be already in serious trouble" were used against it. This +shouldn't be seen as a disadvantage in this context, since it means we +can safely activate the fix very far away in the future (say, 4 years +worth of blocks). + +==Attribution== + +Incorporated suggestions from @btcdrak. + +==Footnotes== + +[1] https://en.wikipedia.org/wiki/Schism + +[2] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki + +[3] http://sourceforge.net/p/bitcoin/mailman/message/34146741/ + +[4] https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11 + +[5] Original references: +https://bitcointalk.org/index.php?topic=114751.0 +https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 +Rebased patch: +https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14 + |