Segwit locking in on Bitcoin

On Wednesday morning around 10:40 UTC, the Bitcoin software upgrade known as SegWit will lock-in. Although a two-week waiting period follows before full activation, the lock-in makes it impossible for miners to change their minds about the upgrade without forfeiting their mining income.

An upgrade process called BIP 9 governs how SegWit and other large, possibly contentious upgrades are made to the Bitcoin network. In this case, BIP 9 calls for 95% of miners to signal agreement for the upgrade within a 2016 block period, or roughly 2 weeks.

SegWit had a one year window for deployment, which started last November. The current 2016 block activation period is number 20 out of 26 during that year. Thanks to the successful outcome of the BIP 91 process two weeks ago, every single block mined during the current period has signaled support for SegWit, making tomorrow’s lock-in a near certainty. Once this activation period is finished, on block number 479,808, a 2-week waiting period begins. This gives users time to upgrade their systems to the new client software. The mandatory waiting period will be completed around August 22.

- Bitcoin Core

SegWit was first conceived as a patch for a vulnerability called Transaction Malleability, (TxMal) which has been linked to the infamous MtGox hack. To create the fix, the format for transactional data stored in new blocks will be re-arranged. Developers soon added a block size increase to the upgrade and the SegWit project was born, in 2015. On top of the TxMal fix and block size increase, SegWit ushers in several other new features that we will start seeing on or around the August 22 activation date. These include, but are not limited to:

Reduced Unspent Transaction Output (UTXO) growth; incentivizes nodes, users and developers to build the UTXO database more efficiently. The UTXO database is used by every full Bitcoin node to determine address balances, and takes up more system resources as it gets larger. This change will help network performance, fees, and allow for faster scaling all in one change.

Script versioning; makes Bitcoin’s code safer to upgrade by adding a version number to future changes. Individuals will be able to opt-in or out of particular versions, which makes big upgrades much less contentious. Sidechains, drivechains, the Lightning Network, Schnorr signatures, Key recovery, and Merklized Abstract Syntax Trees (MAST) will all be non-contentious upgrades once Script versioning is in place. Many of these will allow Bitcoin to scale further, without a hard fork.

Linear scaling of sighash operations; changes the way that transaction signatures are calculated so that each byte only needs to be hashed twice, rather than the current four times. This provides far better scaling opportunities without sacrificing security.

Pay-to-script-hash (P2SH) Security boost; greatly increases the protection of multi-signature transactions. Primarily an upgrade to the cryptography itself, this add-on is described as combating the threat of a very resourceful attacker breaking the cryptography and gaining control of funds that normally take multiple private keys to access. While no cases have ever been recorded of P2SH thefts in Bitcoin, the cryptographic weakness is well known. This increase will make Bitcoin 281 trillion times harder to attack, putting P2SH addresses on par with attacking normal Bitcoin addresses.

Signing of input values; allows hardware wallets and IoT devices to securely send bitcoin while in a less resource-intensive environment. By sending only a transaction hash, index, value, and which public key was used, these devices can safely sign a spending transaction with computing overhead such as RAM requirements.

Once TxMal has been patched and script versioning is in place, Bitcoin will facilitate new layers, such as adding Lightning Networks, Rootstock, Drivechains, and Sidechains. Each addition, along with many others yet unimagined, will offer its own new features to the Bitcoin network. They will be created by their own development team on their own schedule, as an optional service, without the need for permission from any Bitcoin developer.

The most significant change that SegWit initially offers is more transactions. Bitcoin is currently able to handle 3 to 7 transactions per second (TPS). In order for the network to effectively serve a global user base the network would need to be able to process many thousands, or more, transactions. The Visa network, for example, can alone process 65,000 TPS. While the Bitcoin network will see immediate gains in terms of transaction throughput on the 22nd, the network will still need further scaling solutions.

The next chapter begins in November, when Bitcoin’s miners and users will have to decide if they want to keep bitcoin as it is, or complete the highly-contentious SegWit2x upgrade, which requires another hard fork of the blockchain.

Also known as the New York Agreement, Segwit2x has been agreed upon by representatives from at least 58 businesses in the niche, as well as miners representing over 80% of the global hashrate. It was designed to enact SegWit and then simply double the block size again once accepted, but at the expense of wresting control of Bitcoin’s main software repository away from Bitcoin’s core team of developers.

The adoption of SegWit2x will put Bitcoin in the hands of Jeff Garzik, and a few other volunteer developers, by adopting an as yet untested version of Bitcoin that this team has been building in the /btc1 directory on Github, outside of the current team’s control.

While the majority of miners have been signaling that they wish to remove this power from the Bitcoin core developers since July, all of Bitcoin’s core developers are against the action, calling it unnecessary, too rushed, and unsafe.