149 - Segregated Witness (second deployment)
BIP: 149 Layer: Consensus (soft fork) Title: Segregated Witness (second deployment) Author: Shaolin Fry Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0149 Status: Withdrawn Type: Standards Track Created: 2017-04-14 License: BSD-3-Clause CC0-1.0 ==Abstract== This document specifies a user activated soft fork for [[bip-0141.mediawiki|BIP141]], [[bip-0143.mediawiki|BIP143]] and [[bip-0147.mediawiki|BIP147]] using versionbits with guaranteed lock-in. ==Motivation== Miners have been reluctant to signal the BIP9 segwit deployment despite a large portion of the Bitcoin ecosystem who want the soft fork activated. This BIP specifies a user activated soft fork (UASF) that deploys segwit again using versionbits with guaranteed lock-in on timeout if the BIP is not already locked-in or activated by the timeout. This ensures users have sufficient time to prepare and no longer require a miner supermajority, while still...
148 - Mandatory activation of segwit deployment
BIP: 148 Layer: Consensus (soft fork) Title: Mandatory activation of segwit deployment Author: Shaolin Fry Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0148 Status: Final Type: Standards Track Created: 2017-03-12 License: BSD-3-Clause CC0-1.0 ==Abstract== This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit". ==Definitions== "existing segwit deployment" refer to the BIP9 "segwit" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147. ==Motivation== Segwit increases the blocksize, fixes transaction malleability, and makes scripting easier to upgrade as well as bringing many other [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits]. It is hoped that miners will respond to this BIP by activating segwit early, before this BIP takes effect. Otherwise this BIP will caus...
8 - Version bits with lock-in by height
BIP: 8 Title: Version bits with lock-in by height Author: Shaolin Fry Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0008 Status: Draft Type: Informational Created: 2017-02-01 License: BSD-3-Clause CC0-1.0 ==Abstract== 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 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...
343 - Mandatory activation of taproot deployment
BIP: 343 Layer: Consensus (soft fork) Title: Mandatory activation of taproot deployment Author: Shinobius Michael Folkson Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0343 Status: Final Type: Standards Track Created: 2021-04-25 License: BSD-3-Clause CC0-1.0 ==Abstract== This document specifies a BIP8 (LOT=true) deployment to activate taproot. ==Motivation== The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefini...