Bitcoin scaling solution, Segwit, released

A new version of Bitcoin’s Core code was released on Thursday, Bitcoin version 0.13.1 Final. The contentious alternative contains a patch known as Segregated Witness (Segwit).

Although the code for Segwit was completed in April, by Blockstream developer Pieter Wuille Ph.D., getting a version for deployment has proven challenging, taking over 35 core Bitcoin developers. The end result could be a major change to Bitcoin, although it is backwards-compatible, and relies on miner adoption to become the new Bitcoin standard.

- Bitcoin Core

The patch works by storing Bitcoin’s proof-of-work signatures, the witnesses, at the end of each line of the transaction, segregating them. This makes them easy to ignore, and allows the file to be read faster by miners and nodes alike.

This design fixed a problem known as transaction malleability. While the problem was once blamed for the meltdown of MtGox, it is a relatively small security issue. However, the Bitcoin core development team lists nine further benefits for the new software, most of which improve overall efficiencies of the network.

Segwit introduces a 70 percent or higher increase in how many transactions could fit inside a block. Part of the Segwit patch is to raise the block size buffer from one to four megabytes. In practice, developers state that the realised increase will be 1.6MB to 2MB, due to Segwit’s new Block weight.

The new limit acts as a re-prioritization of which transaction types are included in blocks first, those more efficiently packaged get moved to the front of the line. A block could contain up to four megabytes, if every transaction is a Segwit transactions.

- Bitcoin Core

The patch also adds a framework that could help Bitcoin scale, by making  layer two applications like the Lightning Network easier to implement.

Current Lightning Network require each Lightning Network client to be a full Bitcoin node, with a complete copy of the blockchain on hand for security’s sake. If Segwit is adopted these clients could outsource this task, according to the Bitcoin Core development team.

An improvement called Script versioning also makes its debut with Segwit. The new code makes improving Bitcoin’s core code safer, by adding a version number to all script improvements. This allows individuals to opt-in to particular versions.

The change allows many future projects like Schnorr signatures, key recovery, smaller signature sizes, sidechains and drivechains, and smarter smart contracts using Merklized Abstract Syntax Trees possible without a hard fork.

Segwit also makes raising the block size safer, the developers claim. Previous attempts to raise the block size risked creating blocks that could take too long for miners to validate, as the sheer bulk of their signatures would be too difficult to hash.

This problem was demonstrated in 2015 when a block was produced with so many signatures that it took 25 seconds to validate. Maliciously designed transactions could theoretically take over three minutes to process at the current block size.

This problem may force miners to exclude any transaction with too many senders or recipients. Segwit could soon produce many large blocks because of the number of transactions they have in them. This would result in a less fungible Bitcoin, so the developers have started working on a new calculation to make the hashing for these signatures far more efficient.

Another claimed benefit of the software is increased security for P2SH multi-signature transactions. A weak setting in the cryptography chain that protects multisig addresses currently exists, potentially allowing one very resourceful attacker to break the cryptography and gain control of funds that normally take multiple private keys to access.

While there no known cases of this happening, as processing power grows it becomes more likely. Segwit requires 281 trillion times as much processing power to attack, putting it on par with attacking normal Bitcoin addresses.

- Bitcoin Core

The decision to deploy the code as a soft fork, which is widely considered a safer option than the alternative hard fork, will continue to delay the code from being activated. The process depends on a supermajority of Bitcoin nodes, including miners, installing and running the new code. It can be completed no sooner than mid December.

To activate the Segwit code, it will take 95 percent acceptance after November 15, and must be sustained for a two week period. There is also a one-year expiry period for Segwit adoption. If the code is not adopted by the middle of November next year, the project will be abandoned.

Interested parties can track adoption on’s bitnodes website. At press time, the day after the code’s release, Core code version 0.13.1 is in third place, making up about 8 percent of the total node count. The new code edged out BitcoinUnlimited, which is now fourth on the list.

 Bitcoin Segwit Adoption Oct 2016

Bitcoin node version count just before Segwit’s launch

However, the deciding factor for Segwit’s adoption is not the percentage of nodes, but rather the percentage of blocks being produced by miners signaling their support for Segwit. This distinction makes node adoption less important, and miner support of Segwit critical.

A mining pool, such as ViaBTC, maintaining more than 5 percent of the overall Bitcoin hashrate and actively campaigning against the upgrade, could be a real threat to Segwit adoption.

“We could have segwit active by christmas, though it's a bit unlikely miners will upgrade that fast.”

- Greg Maxwell, Bitcoin Core developer and Blockstream CTO