BIPs bitcoin improvement proposals

149 - Segregated Witness (second deployment)

<pre> BIP: 149 Layer: Consensus (soft fork) Title: Segregated Witness (second deployment) Author: Shaolin Fry <shaolinfry@protonmail.ch> 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 </pre> ==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 long...

148 - Mandatory activation of segwit deployment

<pre> BIP: 148 Layer: Consensus (soft fork) Title: Mandatory activation of segwit deployment Author: Shaolin Fry <shaolinfry@protonmail.ch> 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 </pre> ==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 ...

8 - Version bits with lock-in by height

<pre> BIP: 8 Title: Version bits with lock-in by height Author: Shaolin Fry <shaolinfry@protonmail.ch> Luke Dashjr <luke+bip@dashjr.org> 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 </pre> ==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 depl...

343 - Mandatory activation of taproot deployment

<pre> BIP: 343 Layer: Consensus (soft fork) Title: Mandatory activation of taproot deployment Author: Shinobius <quantumedusa@gmail.com> Michael Folkson <michaelfolkson@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0343 Status: Proposed Type: Standards Track Created: 2021-04-25 License: BSD-3-Clause CC0-1.0 </pre> ==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 incl...