Release of Bitcoin Core 0.13.1: Activation Plan for SegWit
After a long time of waiting, it finally happens; the release of Bitcoin Core 0.13.1 prepares the activation of Segregated Witness. Since October 27, the new release has been available for download. But the new transaction format will not get activated until late November.
In the crazy history of Bitcoin there might be no update that has been awaited as desperately as Core 0.13.1. This release has only one, minor update; it activates Segregated Witness (SegWit), an upgrade of the transaction format already implemented in Core 0.13.
SegWit means to separate the signature from the transaction. For the first time, this idea was made public at the first Scaling Bitcoin Workshop in Hong Kong in late 2015 by Bitcoin Core developer Pieter Wuille. At first glance SegWit is nothing more than a small formality; signatures are not stored in the transaction but in an extra packet. But if you look further, it provides some major advantages for the Bitcoin network. Most importantly:
- SegWit eliminates all known variants of transaction malleability. This simplifies the construction of several smart contracts enormously, for example, those deployed in Lightning Network.
- SegWit reduces the formal size of a transaction. While the amount of data flowing through the network remains the same, the signature is no longer part of the calculation of the block size. If all transactions are made as SegWit transactions, the real block size will basically be 1.7 to 2.0 MB. SegWit is the long awaited capacity increase.
- By separating the signatures, SegWit changes the calculation of fees. This removes a somehow perverted incentive to pollute the UTXO set with transactions containing few inputs but many outputs, while it reduces the costs of cleaning up the UTXO set.
On top of this SegWit makes future soft forks easier, thus enabling the implementation of ideas like using Schnorr signatures instead of ECDSA, where experts agree that the former provides more robust security. It also scales the sighash operation linearly instead of exponentially to avoid any delays in block validation, simplifies the construction of hardware wallets and increases the security of multi-signature transactions.
However, some drawbacks involved with the SegWit implementation, for example, the larger block size introduces the risk of higher orphan rates for miners, leading to an increase in centralization and lowers the security of the network. Nevertheless, the Bitcoin Core team has laid out details for participants of each of the risks to the Bitcoin ecosystem from SegWit, as well as how best to avoid and mitigate these potential setbacks.
One major reason why the Core devs want to increase the network capacity with SegWit instead of an increase of the block size limit is the former can be implemented as a soft fork. While a hard fork requires every node to update, a soft fork only needs the miners to update. Nodes, which do not want to bear the extra load SegWit implies or refuse it for any other reason, do not need to update. They will just be unable to send or receive SegWit transactions but remain able to send and receive standard transactions. A hard fork replaces the rules, whereas a soft fork extends them.
Considering the many advantages SegWit offers Core devs are optimistic that the miners will implement the update. Version 0.13.1 included a detailed upgrade plan that will activate SegWit by end of November. If everything runs smoothly.
Like every soft fork, SegWit requires that 95 percent of the miners signal their support. Beginning November 15, some kind of voting by the miners will start. In periods of 2,016 blocks – roughly two weeks – it will be measured if 95 percent of the miners want to upgrade. If they do, SegWit is activated. If they do not, another voting period starts. If after one year of voting SegWit is still disabled, it will never be activated.
After the events of the last week, a delay of the activation of SegWit seems likely. Both ViaBTC and the pool of Bitcoin.com are using the alternative Bitcoin client ‘Bitcoin Unlimited’, whose developers by now are not willing to implement SegWit. Since the two pools together have a share of 10 to 15 percent of the hash rate, they can prevent the activation of SegWit, at least for some time.
In the long term, it is likely that a change in the hash rate or simply the usual variance of miner’s luck will result in the activation of SegWit despite the resistance of ViaBTC and others. More likely, however, is that the pools will use SegWit as a hostage to enforce the hard fork, as some Core devs promised in the so-called “Hong Kong agreement.”
