summaryrefslogtreecommitdiff
path: root/bip-0008.mediawiki
diff options
context:
space:
mode:
authorAntoine Poinsot <darosior@protonmail.com>2021-02-26 13:12:55 +0100
committerAntoine Poinsot <darosior@protonmail.com>2021-02-26 14:18:35 +0100
commita118ef42a684491f9e4c731c407478d615fabd3c (patch)
treedc9c7661841632750af20f50d20681e9503af920 /bip-0008.mediawiki
parent3a7585365ff3280a4fc9d34ea6a1e43c39cfa7be (diff)
downloadbips-a118ef42a684491f9e4c731c407478d615fabd3c.tar.xz
bip8: mention in intro the forced activation is optional
Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
Diffstat (limited to 'bip-0008.mediawiki')
-rw-r--r--bip-0008.mediawiki4
1 files changed, 2 insertions, 2 deletions
diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 8800b43..9fc285b 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -16,13 +16,13 @@
This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that corrects for a number of perceived mistakes.
Block heights are used for start and timeout rather than POSIX timestamps.
-It additionally introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks").
+It additionally introduces an activation parameter that can guarantee activation of backward-compatible changes (further called "soft forks").
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
==Motivation==
-BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide eventual flag day activation after a reasonable time (recommended a year), as well as for accelerated activation by majority of hash rate before the flag date.
+BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide optional flag day activation after a reasonable time (recommended a year), as well as for accelerated activation by majority of hash rate before the flag date.
Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of significant hashrate could interfere with a late activation.