SegWit (Segregated Witness) is the name used for an implemented process change in the way Bitcoin stores the transaction data in the blockchain. The code for this change was released in 2015, and SegWit finally went live in August 2017.
SegWit improves Bitcoin and fixes a number of bugs.
Primarily, SegWit doubled the transaction capacity of the Bitcoin network. While lot of people are claiming that SegWit did not increase the block size, it鈥檚 very easy to see that, yes, SegWit was a block size increase!
Here, for example, we can see a 2,177 KB (2.17 MB) Bitcoin block mined in January 2018.
In addition to increasing Bitcoin鈥檚 ability to process transactions, SegWit fixed a flaw in Bitcoin鈥檚 protocol that allowed nodes to tamper with transaction IDs of transactions on the network. This bug was known as the 鈥榯ransaction malleability bug鈥.
Without going into too much detail on how exactly that bug worked, here is the short version:
If all the right conditions were met, a user could change the transaction ID to a spend before it could be confirmed by the network. This makes it easier to pretend this transaction didn鈥檛 happen, which may be useful to someone looking to claim they sent coins to someone else when they really didn鈥檛.
It would be similar to receiving a package from amazon and claiming you never got it, and using a faked tracking number from Fedex that backs up your story.
That is what transaction malleability allowed you to do.
Segwit increased the amount of transactions that could fit into a block and fixed the transaction malleability bug by removing what is known as 鈥榯he witness data鈥 or 鈥榮ignature data鈥 from the input field of a block.
Transactions get smaller, so you can put more into a block. And with witness data removed, there is no way to change the TXID of a transaction.
SegWit2x was a movement beyond the SegWit change to improve the Bitcoin blockchain by increasing the size of blocks from 1MB to 2MB (2x). In 2017, users had been paying miners a lot of money to make transactions. Fees were high and users were annoyed.
In fact, fees once reached nearly 1000 Satoshis per byte.
For comparison, you can normally do 1 satoshi per byte, meaning fees were 1000 times higher than normal.
Bitcoin needed to scale to service more transactions.
SegWit2x was a proposal that would require a hard fork, and it was built on the back of a soft fork proposal.
At it鈥檚 heart, SegWit2x was two separate changes to Bitcoin combined into one.
First, you have Segregated Witness or 鈥楽egWit鈥 (outlined above).
SegWit was the 鈥渟mall blocker鈥 solution to scaling Bitcoin - instead of increasing the block size, you would instead use the existing block space more efficiently.
Then you had the 鈥渂ig blocker鈥 solution, which is where the 鈥2x鈥 comes from. Their solution was to simply double the size of existing blocks.
And that is where the New York Agreement came into play.
This agreement was initially formed so that the Bitcoin network would prevent splitting into two different coins.
The solution proposed by the agreement runners was to give both parties what they wanted: a doubling of the block size and an activation of SegWit.
In order to implement SegWit2x, there would have to have been a considerable change in the rules of bitcoin governance.
However, the revolutionary aim was that SegWit2x would keep all existing bitcoin users on the same singular blockchain.
In the run-up to its proposed adoption, startups and miners were the most overt supporters of the new update.
Fundamentally, this was based on the frustrations people had over bitcoin adoption. Bitcoin鈥檚 slowness allowed other coins to take market share.
The other huge fans of the SegWit2x proposal were larger bitcoin companies like Circle and Coinbase. While they would ultimately suspend their support, their logic was similar to that of miners and startups.
For the most part, these companies make money when there is lots of coin circulation. More transactions equals more fees for them to charge. If users don鈥檛 want to send their coins to your exchange because the transaction fees are too high, that is bad for business.
SegWit2X satisfied many of the shared aims of the various stakeholders. It would allow Bitcoin to increase its transaction throughput in the short term and allow exchanges and miners to continue to make money as usual even if it meant potentially harming what made Bitcoin great.
The opposition to SegWit2x came from node operators, developers, and users in developing countries.
Part of the debate came from an inherently different understanding of what matters most about Bitcoin.
For opponents of SegWit2x, decentralization was of prime importance. Doubling the block size would make it harder to run your own node and verify your own transactions and this was doubly true of people in the developing world where running a node was already relatively more expensive.
To opponents of SegWit2x, the hard fork violated the whole point of Bitcoin - to create an open financial system that everyone could afford to participate in.
Ultimately, the risks outweighed any potential benefits. While SegWit2x would increase the speed of transactions, the burden would have been felt more keenly by every day users operating nodes, as they would have had to store more data.
With opposition in both ideology and the rollout of the protocol, there was ultimately too wide a gulf to bridge.
On November 8, 2017, the proposal was suspended due to the ongoing resistance to the protocol. Companies such as Coinbase and Circle revoked their support, and ultimately the protocol failed.
SegWit adoption is increasing. 82% of all Bitcoin transactions use SegWit addresses.
Another sign of the adoption is the support by many of the exchanges and digital hardware wallets allowing accounts that are SegWit accounts. Two of the top digital hardware wallets, Ledger and Trezor both support SegWit accounts, while many of the larger exchanges like Coinbase support, allow legacy and SegWit support.
It is important to understand the differences in managing these accounts on your digital wallets
On the Trezor wallet, a 鈥渟tandard鈥 account is a SegWit account. That means that when you set up a Trezor device, it will generate a SegWit Bech32 address by default.
Trezor will continue to support Legacy accounts on their devices, but in order to benefit from the SegWit change you must move your coins into a SegWit account from a legacy account.
You can pick which kind of address you want when you set up your TREZOR device:
In Bitcoin there are multiple address formats that can reside in the blockchain. Most wallets support multiple format types with the most common being P2PKH, P2SH, and Bech32. The format of the SegWit address is the Bech32 format, also known as the bc1 address because the string always starts with 鈥榖c1鈥.
Here is an example of what a Bech32 address would look like:
Bech32 is the native segwit address format, and is supported by the majority of software and hardware wallets.
Lightening Network is a fix to both the speed and cost of a Bitcoin transaction and is a decentralized network that allows the transfer of bitcoin ownership by way of an additional layer in a transaction. SegWit is the foundation for the Lightning Network. By eliminating the possibility for transaction malleability, secure payment channels can be created that will eventually allow the Bitcoin network to process millions of transactions per second. Lastly, SegWit is a way to help Bitcoin scale to accommodate its ever-expanding user base, without forcing a hard-fork.
Before SegWit, the Transaction ID of a transaction could have been changed by manipulating the unlocking code of the transaction (your digital signature). After you digitally sign a transaction, it is sent through Bitcoin鈥檚 cryptographic hash function which results in a unique transaction ID.
If one character is changed in the digital signature, it will result in an entirely different transaction ID. SegWit moves the signature to the end of the transaction data, so the Transaction ID is created from everything but the digital signature.
In effect, this change renders it impossible to change the Transaction ID 鈥 if malicious nodes were able to tamper with Transaction IDs, the Lightning Network wouldn鈥檛 be possible.
SegWit is short for 'segregated witness'.
SegWit was a soft fork. This is opposed to a hard fork which would create a separate coin (such as Bitcoin Cash). It added features and fixes to Bitcoin in 2017.
Yes, hardware wallets like Ledger and TREZOR support SegWit.
SegWit was developed by Peter Wuille. He's one of Bitcoin's most prolific developers, and won Coindesk's 2017 Most Influential Award.
Yes, congrats Litecoin! :) Litecoin will also be adding more features in the future.
You can think of the Bitcoin (bitcoin is modeled after gold) network like a chain, and each link in the chain is a block. For the sake of simplicity, let鈥檚 picture a block that only contains one transaction. If Mike sends 1 BTC to Bob, he鈥檇 add important data to the block:
Mike鈥檚 public key and digital signature must be included in the block to prove that the transaction is legitimate and really did come from him. The digital signature is included in the block as script (you can think of script as code). Just like people sign checks to authorize them, users of the BTC network must sign transactions to authorize them.
Despite being necessary to authenticate transactions, digital signatures fill up a lot of space that could otherwise be used for transaction data.
When thousands of transactions are initiated at once, there is not enough room for all of them to enter the same block at the same height. Users must pay a transaction fee which incentivizes miners to include their transaction in the block before others鈥. The more you pay, the faster your transaction will go through.
Unfortunately, transaction fees can get quite pricey. In December of 2017, it wasn鈥檛 unheard of to pay $50 per transaction if you wanted it to be validated within 10-20 minutes. Bitcoin鈥檚 scalability issue is one of its most significant obstacles prior to mainstream adoption. Nobody in today鈥檚 society wants to pay $20 for a cup of coffee while waiting around for their payment to clear.
Something must change.
Some believe the best way to solve the problem is expanding Bitcoin鈥檚 block size 鈥 however, that solution would require Bitcoin to hard fork. Rather than forking into a completely new cryptocurrency, SegWit has been implemented to significantly increase Bitcoin鈥檚 ability to process transactions.
For an easy primer on the lifecycle of a standard Bitcoin transaction, you can reference the image below from the Bitcoin wiki.
SegWit was activated via UASF. As mentioned previously, every block is composed of transaction data (public key, amount of BTC, etc.) and script (the sender鈥檚 public key and their digital signature). Although it is imperative that digital signatures are included in the validation process, they use a lot of space in blocks that could otherwise be used for more transactions.
Digital signatures, also known as witnesses, take up 60% of transaction data and usually the witness data exists in the middle of the transaction data. Segregated Witness is a way to remove the witness (signature) from the transaction 鈥 instead, SegWit transactions move the witness data to the end of the transaction. When a SegWit transaction is being validated by a Legacy node (one that hasn鈥檛 upgraded), the witness data is stripped from the transaction. By removing signatures from the main block of transactions, transaction size is notably smaller, thus allowing far more transactions per block.
It is important to note that prior to SegWit, Bitcoin鈥檚 maximum block size was 1,000,000 bytes (1MB) 鈥 that is, once that data limit was reached, the block was no longer able to accept more transactions and any other transactions that weren鈥檛 included in the block had to wait in the mempool.
SegWit, contrary to popular belief, is indeed a block size increase. SegWit has implemented a new way to measure the size of transactions. Instead of relying on a 1,000,000-byte block size, SegWit measures blocks using something known as block weight.
Here鈥檚 the formula used to calculate block weight:
(tx size with witness data stripped) * 3 + (tx size)
Since Segwit transactions are broadcasted to all nodes with the witness data stripped, the legacy nodes will never have to validate a block greater than 1,000,000 bytes, therefore adhering to Bitcoin鈥檚 original protocol.
Conversely, SegWit nodes can receive blocks that are very close to, but not quite 4MB in size. In order for a block to be (near) 4MB, it would have to consist of primarily witness data rather than transaction data. It would be incredibly close to 4MB with the witness data, but still, less than 1,000,000 bytes when stripped of the witness data.
Although SegWit nodes are capable of validating a 4MB (4,000,000 bytes) block, in practice, that block size is ridiculously large. In most cases, a SegWit block will not exceed 2MB.
| Before | After | |
|---|---|---|
| Max Block Size | 1 MB | 4 MB |
| Transactions per Second | 3 TX/s | 7 TX/s |
| Transaction Malleability Bug | Broken | Fixed |
Part of the issue with SegWit2x was that it required a hard fork, as opposed to vanilla SegWit, which would only require a soft fork.
A soft fork is, at its core, backwards compatible. It allows for a shift in network rules and creates blocks that will still be recognized by existing, non-upgraded software.
On the other hand, a hard fork involves taking a blockchain and splitting it into two permanently. It performs a complete overhaul of the rules that apply to the blockchain and completely redesigns it so that it will not recognize old software.
In some cases, a hard fork can split a network into two, creating different systems that allow people to choose which they wish to adopt. This was seen in the case of bitcoin and bitcoin cash.
However, a split can also be caused if enough people adopt both possible outcomes, causing disruption to networks and systems.
