From 8d4ae8adf6dc9c0bf22c9b9c384748899e7823e4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jorge=20Tim=C3=B3n?= Date: Thu, 5 Nov 2015 23:01:56 +0100 Subject: Some of kanzure's nits, copyright, updated Attribution, don't repeat "Without entering in much detail" --- bip-0099.mediawiki | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/bip-0099.mediawiki b/bip-0099.mediawiki index 0e41870..f05247f 100644 --- a/bip-0099.mediawiki +++ b/bip-0099.mediawiki @@ -46,9 +46,9 @@ deployment of changes. 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 +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). +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 @@ -60,36 +60,36 @@ 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 +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 +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 +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. +which - being accidental - obviously doesn'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 +Without entering in much detail (see [2]), 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 +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 +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 +A short summary would be 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 @@ -207,7 +207,7 @@ uncontroversial anyway. ===Uncontroversial consensus upgrades=== -"Uncontroversial" is something though to define in this context. What +"Uncontroversial" is something tough 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 @@ -302,7 +302,7 @@ 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 +tested (in fact, most SHA256d altcoins that didn't implement 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 @@ -311,17 +311,13 @@ 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/ +[3] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki [4] https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11 @@ -331,3 +327,10 @@ https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 Rebased patch: https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6ff14 +==Attribution== + +Incorporated corrections and suggestions from: btcdrak, Andy Chase, Bryan Bishops, Luke Dashjr + +==Copyright== + +This document is placed in the public domain. -- cgit v1.2.3