Home › Browse › BIP 149

BIP 149: Segregated Witness (second deployment)

In plain English: Proposed a second attempt at activating SegWit using version-bits signaling with guaranteed lock-in after a deadline. It was offered as an alternative path in case the original SegWit deployment failed to gain enough miner support.

Status
Closed
Type
Specification
Layer
Consensus (soft fork)
Authors
Shaolin Fry
Assigned
Last changed
Topics
Consensus
Source
bip-0149.mediawiki on GitHub · Markdown

Abstract

This document specifies a user activated soft fork for BIP141, BIP143 and 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 allowing for an earlier miner activated soft fork (MASF).

Reference implementation

The reference implementation will refuse to run on Bitcoin mainnet before 7 November 2017, and can only be run on testnet and regtest until then.

https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday

Specification

This deployment will set service bit (1<<5) as NODE_UAWITNESS.

Deployment

This BIP should only be deployed if BIP9-segwit fails to lock-in or activate before timeout on 15 November 2017. This BIP cannot be deployed before 15 November 2017.

This BIP will be deployed by BIP8 with the name "segwit" and using bit 1.

For Bitcoin mainnet, the BIP8 starttime will be midnight 16 November 2017 UTC (Epoch timestamp 1510790400) and BIP8 timeout will be 4 July 2018 UTC (Epoch timestamp 1530662400).

For Bitcoin testnet, segwit is already activated so no deployment is specified.

Backwards Compatibility

This deployment reuses the GBT deployment name "segwit" to maintain compatibility with existing mining software.

This deployment is incompatible with the BIP9-segwit deployment and should not be run concurrently with it.

Rationale

The starttime of this BIP is after the BIP9-segwit timeout to remove compatibility issues with old nodes.

References

Mailing list discussion

BIP8

BIP9

BIP141

BIP143

BIP147

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.

Related proposals

  • BIP 30: Duplicate transactions: Deployed. Added a rule forbidding a block from including a transaction with the same ID as an earlier one whose outputs are not fully spent. Such duplicates can overwrite earlier coins and make them…
  • BIP 34: Block v2, Height in Coinbase: Deployed. Upgraded blocks to version 2 and required each block's coinbase transaction (the one paying the miner) to include the block's height. This makes every coinbase unique, preventing duplicate…
  • BIP 42: A finite monetary supply for Bitcoin: Deployed. A tongue-in-cheek proposal fixing a software quirk that would have made the block reward reappear and coin issuance restart a couple of centuries from now. It ensures the roughly 21 million coin…
  • BIP 50: March 2013 Chain Fork Post-Mortem: Deployed. A post-mortem of the March 2013 incident in which a database limit in older Bitcoin software caused the blockchain to split temporarily. It explains what went wrong, how miners and developers…
  • BIP 54: Consensus Cleanup: Complete. Bundles fixes for several long-standing protocol weaknesses: the timewarp attack (manipulating block timestamps to speed up coin issuance), blocks that take extremely long to validate, Merkle tree…
  • BIP 62: Dealing with malleability: Closed. Proposed a set of rules to stop third parties from altering a transaction's ID without changing what it does, a problem called malleability. It was withdrawn after Segregated Witness (SegWit) solved…