Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£861.31
EST. MONTHLY
205
DAYS
EST. ROI
This guide explains BIP 149 SegWit deployment in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 149 proposed a second SegWit deployment using a user-activated soft-fork contingency if the original BIP 9 deployment failed to lock in or activate by its timeout. It specified guaranteed lock-in using BIP 8-style rules and a NODE_UAWITNESS service bit.
- Why it matters: BIP 149 was a closed contingency for a second SegWit deployment, not the mechanism ultimately required. Its enduring lessons concern explicit triggers, guaranteed lock-in risk and operational preparation for incompatible enforcement.
- Current position: The BIP is Closed and the contingency was not used for Bitcoin’s eventual SegWit activation.
BIP 149 SegWit deployment in simple English
BIP 149 SegWit deployment: The original SegWit path locked in and activated, so BIP 149’s second deployment contingency was unnecessary. Its code and dates are historical.
Simple example
A node operator is checking BIP 149 SegWit deployment. The proposal was conditional on the first SegWit deployment failing by 15 November 2017. It aimed to preserve the already reviewed BIPs 141, 143 and 147 while changing activation coordination.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Contingent purpose
The proposal was conditional on the first SegWit deployment failing by 15 November 2017. It aimed to preserve the already reviewed BIPs 141, 143 and 147 while changing activation coordination. A contingency cannot be evaluated without its trigger and conflict rules.
Guaranteed lock-in
Unlike a threshold that can time out without activation, the described deployment would progress to lock-in under defined BIP 8 semantics. That shifts responsibility toward enforcing nodes and gives miners a preparation window. It also raises split risk if economic participants run incompatible rules.
Timing safeguards
The reference implementation refused mainnet operation before a specified November date and was limited to testnet and regtest earlier. Date gates reduce accidental premature enforcement but depend on median-time and exact release logic. Clock and chain-state tests remain essential.
Service-bit signalling
NODE_UAWITNESS was intended to help upgraded nodes identify compatible peers and avoid serving witness data under mismatched expectations. A service bit advertises capability or policy, not proof of full economic alignment. Peer partitioning and eclipse effects require analysis.
Relationship to other 2017 activation efforts
BIP 149 was one of several proposals during the SegWit activation debate. BIP 91 and BIP 148 had different mechanisms and timelines. Historical articles must not merge them into one UASF or imply BIP 149 caused the activation outcome.
Closed status and outcome
The original SegWit path locked in and activated, so BIP 149’s second deployment contingency was unnecessary. Its code and dates are historical. Running an archival branch on current mainnet would be unsafe and offers no modern activation benefit.
Operational lessons
Contingent soft-fork plans need precise trigger conditions, release and rollback schedules, peer-compatibility monitoring, miner template tests and split procedures. Operators should test alternate histories on private networks and communicate chain-selection evidence without treating a service bit as consensus. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is the main point of BIP 149 SegWit deployment?
BIP 149 SegWit deployment: The original SegWit path locked in and activated, so BIP 149’s second deployment contingency was unnecessary.
For BIP 149 SegWit deployment, what should a beginner know about contingent purpose?
The proposal was conditional on the first SegWit deployment failing by 15 November 2017.
For BIP 149 SegWit deployment, what should a beginner know about guaranteed lock-in?
Unlike a threshold that can time out without activation, the described deployment would progress to lock-in under defined BIP 8 semantics.
For BIP 149 SegWit deployment, what should a beginner know about timing safeguards?
The reference implementation refused mainnet operation before a specified November date and was limited to testnet and regtest earlier.
Conclusion
BIP 149 was a closed contingency for a second SegWit deployment, not the mechanism ultimately required. Its enduring lessons concern explicit triggers, guaranteed lock-in risk and operational preparation for incompatible enforcement.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.