mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-03 18:57:18 +01:00
Code Issues Projects Releases Wiki Activity

Some of kanzure's nits, copyright, updated Attribution, don't repeat "Without entering in much detail"

Browse source
This commit is contained in:
Jorge Timón 2015-11-05 23:01:56 +01:00
parent 32bb5cdeab
commit 8d4ae8adf6
1 changed files with 20 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
bip-0099.mediawiki
View file

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