1
0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00

More corrections and improvements

This commit is contained in:
Jorge Timón 2015-11-08 12:45:35 +01:00
parent 7d31bf365b
commit 82784e6061

View File

@ -16,9 +16,8 @@ consensus forks and proposes a deployment mechanism for each of them.
==Motivation== ==Motivation==
The security assumptions of p2p consensus-based systems like Bitcoin are 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 best upgrade mechanisms to the
consensus rules are a work in progress that may vary depending on the consensus validation rules may vary depending on the type of change being deployed.
type of change being deployed.
Discussing such changes without a uniform view on the deployment Discussing such changes without a uniform view on the deployment
paths often leads to misunderstandings and unnecessarily delays the paths often leads to misunderstandings and unnecessarily delays the
deployment of changes. deployment of changes.
@ -26,16 +25,22 @@ deployment of changes.
==Definitions== ==Definitions==
;Software fork ;Software fork
: A copy of an existing project where management is separate from the existing project. : A copy of an existing project. In free software, this can be done without the permission of the original project's maintainers.
;Consensus fork ;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. : A divergence in the implementation of the verification consensus 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 ;Softfork
: A change to the Bitcoin protocol wherein previously valid blocks and transactions become invalid. A hashrate majority of miners can enforce the new rules so that the change enforced across all clients. Softforks are backward compatible. : A consensus fork wherein everything that was previously invalid remains invalid while blocks that would have previously considered valid become invalid. A hashrate majority of miners can impose the new rules. They have some deployment advantages like backward compatibility.
;Hardfork ;Hardfork
: A change to the Bitcoin protocol that makes previously invalid blocks valid. Hardforks require all users to upgrade. : A consensus fork that makes previously invalid blocks valid. Hardforks require all users to upgrade.
;Libconsensus
: a theoretical piece of software that contains the specifications that define the validity of a block for a given state and chain parameters (ie it may act differently on, for example, regtest).
;Libbitcoinconsensus
: the existing implementation is a library that is compiled by default with Bitcoin Core master and exposes a single C function named bitcoinconsensus_verify_script(). Although it has a deterministic build and implements the most complex rules (most of the cryptography, which is itself heavily based on libsecp256k1 after #REPLACE_libsecp256k1_PR), it is still not a complete specification of the consensus rules. Since libconsensus doesn't manage the current state but only the validation of the next block given that state, it is known that this long effort of encapsulation and decoupling will eventually finish, and that the person who moves the last line
==Taxonomy of consensus forks== ==Taxonomy of consensus forks==
@ -162,7 +167,7 @@ mine itself. For that or another reason, a single entity controls
improvement in decentralization. Such an untenable centralization could improvement in decentralization. Such an untenable centralization could
be fixed (with great risks) by switching the hash function used in the be fixed (with great risks) by switching the hash function used in the
proof of work, effectively "pressing the restart button" on the ASIC proof of work, effectively "pressing the restart button" on the ASIC
market. [The next function should be simple to implement in ASIC as 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 well so that the market can more easily develop as a healthy and
competitive one (as opposed to what the "ASIC-hard" proponents would competitive one (as opposed to what the "ASIC-hard" proponents would
want), but that's another story...] want), but that's another story...]
@ -191,12 +196,12 @@ have to be ignored.
====Anti-cabal hardfork==== ====Anti-cabal hardfork====
Let's imagine BIP66 [TODO remove has been deployed, but it] had a crypto backdoor Let's imagine BIP66 had a crypto backdoor
that nobody noticed and allows an evil developer cabal to steal that nobody noticed and allows an evil developer cabal to steal
everyone's coins. The users and non-evil developers could join, fork everyone's coins. The users and non-evil developers could join, fork
libconsensus and use the forked version in their respective bitcoin libconsensus and use the forked version in their respective bitcoin
implementations. implementations.
Should miner's "vote" to express their consent? What if some miners Should miner's "vote" be required to express their consent? What if some miners
are part of the cabal? In the unlikely event that most miners are 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 part of such an evil cabal, changing the pow function may be
required. In other cases, mining "vote" doesn't have much value required. In other cases, mining "vote" doesn't have much value
@ -327,7 +332,7 @@ https://github.com/freicoin/freicoin/commit/beb2fa54745180d755949470466cbffd1cd6
==Attribution== ==Attribution==
Incorporated corrections and suggestions from: btcdrak, Andy Chase, Bryan Bishops, Luke Dashjr Incorporated corrections and suggestions from: Andy Chase, Bryan Bishop, Btcdrak, Gregory Sanders, Luke Dashjr, Marco Falke.
==Copyright== ==Copyright==