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

Random grammar and spelling stuff

Browse Source
This commit is contained in:
instagibbs 2015-08-28 14:32:58 -07:00 committed by Jorge Timón
parent 6b201a4d2d
commit d954832e30
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
bip-0099.mediawiki
View File

@ -16,14 +16,14 @@ 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
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==
==Definitions==
- Software fork: in free software, an existing project can be copied
and extended/maintained without permission from the original
@ -35,8 +35,8 @@ deployment of changes.
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.
valid also become invalid. A majority of miners can impose
these kind of changes and they also have some deployment advantages.
- Hardfork: an intentional consensus fork that is not a softfork.
==Taxonomy of consensus forks==
@ -51,7 +51,7 @@ 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
validation rules can prevent users of alternative implementation 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
@ -78,7 +78,7 @@ 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 (see [2]), the situation was different from
Without entering into 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
is very reasonable considering the lack of a complete