Explain Like I’m Five: Bitcoin BIPs – SegWit and Version Bits
You’ve likely heard all the ruckus going around about Bitcoin. “Bitcoin needs scalability!” - the community cries. So Bitcoin devs answer back with a soft fork or a hard fork solution. Both are a tough pill to swallow, and the community gets to choose.
With all the talks of BIP91, BIP148, BIP141, SegWit2x, what do these Bitcoin Improvement Proposals (BIPs) mean? Is this the best solution? Is this the best way to finding a solution?
A Timeline of BIPs
Since Bitcoin has no standard, formal structure, or central authority, it must use BIPs. These are documents that either inform or propose new features. The major BIPs that are worth looking at are BIP141, BIP148, BIP91, and BIP9.
BIP9 - Version Bits
- Title: Version bits with timeout and delay
- Date: 2015-10-04
BIP9 was co-created with the help of SegWit creator himself, Pieter Wuille. This BIP introduced a very important feature called version bits.
Version bits are a 32-bit field that would help miners or nodes have more power by voting on the future changes of the Bitcoin blockchain. By changing a specific “0” in the version bits field to a “1”, nodes or miners signal support for a protocol that corresponds to the 0.
Each proposed BIP would go through a threshold vote. The threshold was 95% of blocks signaling "1" in a specific version bit. This means that within a difficulty readjustment period, 2016 blocks, if 1916 mined blocks signal "1", the BIP activates.
BIP9 did this through parallel forks (soft forks). Whereby miners could run different forks of Bitcoin, depending on the protocol they signal support for, but would still mine the same blocks.
BIP141 - SegWit
- Title: Segregated Witness (Consensus layer)
- Date: 2015-12-21
The original proposal of SegWit was two years ago. It made a strong argument against the inefficiency of signature data in transactions but went under the radar because the need for scaling wasn't as demanded as it is now. The protocol failed to pass the threshold until very recently.
According to Pieter Wuille, signature data accounts for 65% of the transaction size. This was the first red flag in Bitcoin’s scalability roadmap.
The protocol saved space by removing signature data from the beginning of a transaction, summing all the mini transactions into a single one, and only then adding the signature hash
It also opens the door for a new type of transaction: micro transactions.
- Title: Mandatory SegWit Activation (UASF)
- Date: 2017-03-12
The dreaded BIP148. This proposal is a User Activated Soft Fork (UASF) that shook the Bitcoin community altogether, installing a mandatory activation of SegWit through node votes.
The proposal caused a lot of turmoil because it gave a clear message: Bitcoin needs improvement, whether part of the community likes it or not. It stated that nodes or miners that do not signal for SegWit will fork into a separate chain and their blocks - orphaned.
- Title: Reduced Threshold for SegWit (MASF)
- Date: 2017-05-22
Although BIP148 caused havoc in the crypto community, SegWit still failed to pass any significant threshold. Fearing that the implementation was backtracking, Bitcoin introduced BIP91.
The proposal lowered the threshold from 95% to 80%. Also, by being a Miner Activated Soft Fork (MASF) it meant that the vote was on the miners, not on the nodes.
There is a catch though, BIP91 also reduces the period when the votes are valid. SegWit has a full readjustment period of 2016 blocks for miners to signal support. BIP91 lowered it to 336 blocks and 80%. Hence, if 80% of 336 blocks signal "1" on bit 4 of the version bits field, BIP91 would activate and SegWit would activate.
This also means that three months later miners would get to choose on implementing SegWit2x - joining the 2 MB block size blockchain.
A Timeline of Possibilities - Infograph
As you can see, if BIP91 locks in then there won’t be a BIP148, since BIP148 is there more-or-less as a failsafe. The two lead to almost the same thing.