How does the bitcoin source code define its 21 million cap?
Many of bitcoin’s staunchest critics have expressed doubt about its 21 million cap, but perhaps the most mindless criticism relates…
,Segwit, or segregated witness, was an opt-in change to bitcoin that occurred in August 2017. It coincided with a turbulent time in bitcoin’s history known as the Blocksize War, which can be explored in detail by reading Jonathan Bier’s book of the same name. In this article, we’ll cover the basics of segwit, with a focus on its direct implications for bitcoin custody.
At the highest level, you need to know that segwit changed the way most bitcoin transactions are formatted. A bitcoin transaction can be broken down into two main components:
Before the Segwit soft fork, these two components were combined to produce a transaction identifier (TXID), which is a bunch of letters and numbers referencing the transaction.
Transaction data can’t be adjusted without creating a fundamentally different transaction. However, signature data for a pending transaction can indeed be altered, which could cause the TXID to change. This concept is called transaction malleability, and it specifically posed a problem for certain bitcoin applications, such as enabling the Lightning Network.
Segwit solved this issue by segregating the data related to the signatures, also called the witness, such that the TXID would only be determined by the unmalleable transaction data. Therefore, a pending transaction utilizing segwit has a TXID that cannot be changed, which is crucial to facilitating Lightning payment channels and other potential smart contracts.
Beyond enabling Lightning, there are numerous benefits to using segwit, the details of which are outlined in an excellent Bitcoin Core resource. Some of the benefits are technical and become realized over a longer time frame, relevant to those who operate a bitcoin node (which all bitcoin users should consider doing!) or developers.
However, there are advantages that are easier to understand and directly affect the typical person holding bitcoin in a self-custody wallet. These include cheaper transaction fees, improved efficiency while signing transactions, and enhanced security for the future of collaborative multisig.
As a part of the implementation of segwit, the blocksize limit was reconfigured (citing scalability related to the UTXO set). Previously, each block on the blockchain could only contain up to 1 MB worth of data. With the Segwit Soft Fork adjustment, each block can contain up to 1 MvB instead. This introduced a new concept called virtual bytes, or vB. One byte of transaction data is also worth one virtual byte of data. However, one byte of segregated witness data is discounted to only 0.25 virtual bytes of data.
With a limit of 1 MvB of data per block, it could theoretically contain up to 1 MB of nothing but transaction data, or up to 4 MB of nothing but witness data, due the witness discount. In practice, blocks contain a mix of both types of data, and end up being around 1.5 MB to 2 MB on average.
Since segregated witness data takes up 75% less space than transaction data within a block, it is also treated with a 75% transaction fee discount. This means that transactions being spent out of a wallet using segwit are significantly cheaper on average (sending into a segwit wallet won’t make nearly as much difference). For example, transaction inputs spent from a singlesig wallet using segwit receive a 53% discount compared to one without segwit. Transaction inputs spent from a 2-of-3 multisig wallet using segwit receive a 64% discount compared to one without segwit. While the actual savings for a transaction will vary based on other details, the difference is usually quite noticeable.
The reduction in transaction fees also means that recommendations surrounding minimum deposit amounts into a wallet can be decreased if segwit is used. Low-value deposits into a wallet creates small UTXOs, which can lead to higher percentage transaction fees when those UTXOs are spent in the future. In some cases, the percentage can be so high that the UTXOs are too costly to be spent, also called operative dust. To guard against this, larger size deposits to self-custody are recommended, and segwit offers a more lenient threshold. This concept can be investigated further in our article about dust thresholds.
Another change introduced alongside segwit was a scalability improvement related to the verification of signatures for transactions involving a lot of data. When a hardware wallet attempts to sign a transaction moving many UTXOs at one time, and especially if those UTXOs have substantial signing mass, the device can struggle with the operational intensity. It might take many minutes to complete, or fail entirely and force the user to send several smaller transactions. People who frequently withdraw bitcoin from exchanges to self-custody, or receive regular payouts from mining pools may be familiar with such frustrations.
These problems can still be experienced by wallets using segwit, although they are mitigated to a degree. The time and operational effort to validate complicated transactions scales linearly rather than quadratically, meaning that hefty transactions can be signed faster and with a greater chance of success.
While proposing the changes for the segwit upgrade, developers sought to address a known concern with multisignature security. They realized that in the future, the feasibility of something called a P2SH birthday attack would increase. The attack works in the context of collaborative multisig, where more than one party is contributing a public key toward building the multisig quorum. If one or more participants share their public key(s) first, the last participant to contribute a key could attempt an operation that is both time and resource intensive, but could result in unilateral control of funds, without the permission of the other participants.
It’s important to note that due to the time and resource constraints of this theoretical attack, it’s considered highly impractical at the time of writing this article, and there are no known instances of it occurring in the real world. However, as technology improves, the amount of time and resources required to attempt the attack is expected to decline, meaning it could become more relevant.
To be protected from this futuristic vulnerability, people can simply build multisig wallets using segwit. The changes included with the Segwit Soft Fork resolved this issue by upgrading the security level to be consistent with other aspects of the bitcoin protocol. People who already have a multisig wallet without segwit shouldn’t be alarmed—the attack could only be attempted while the wallet is being first created, not afterwards.
It’s easy to determine if a bitcoin wallet is using segwit—simply examine the deposit addresses for the wallet! In an earlier article about the various address types, we covered that the addresses using segwit begin with bc1, while the older addresses prior to segwit begin with either a 1 or a 3.
Examples of addresses using segwit include:
Examples of older address types not using segwit include:
For a period of time, there were also some addresses beginning with a 3 that used segwit, which were called “nested segwit” or “wrapped segwit”. These were chosen by people who wanted to utilize segwit shortly after its release, but also wanted to still be able to receive bitcoin from others who had not yet upgraded. Nested segwit addresses are much less common now, because nearly all actors within the bitcoin economy are capable of sending bitcoin to native segwit addresses.
For people holding bitcoin in self-custody, using a segwit wallet offers several advantages, including reduced transaction fees, more efficient signing, and enhanced security for future scenarios. You can explore other benefits using the aforementioned Bitcoin Core resource, or by checking out the actual bitcoin improvement proposals that were included in the Segwit Soft Fork, namely BIP141, BIP143, and BIP147.
Many of bitcoin’s staunchest critics have expressed doubt about its 21 million cap, but perhaps the most mindless criticism relates…
Ted Stevenot, Stephen HallWhen Satoshi Nakamoto created bitcoin, he established in its code a fixed number of bitcoin that will ever exist. Since…
Ted StevenotOriginally published in Parker’s dedicated Gradually, Then Suddenly publication. Bitcoin is often described as a hedge, or more specifically, a…
Parker Lewis