As we approach the release date for the SEGWIT (Segregated Witness) update to the blockchain, we were pleased to see a complete update from the BitcoinCore team about how this update will affect the network, what will change and where are we going to proceed in the future.

For those of you who don’t know what SEGWIT is software that is used to produce transactions for which it separates the TxID transaction signatures from the rest of the data, thus Segregated Witness. This allows miners to place the transaction signatures outside of the block-chain.

Pros and cons

There are benefits that we will immediately be able to enjoy once the update has been complete. The first benefit is that malleability will be ultimately eliminated, and third-parties won’t be able to interfere with the transaction process, and transaction ID’s will be hidden from everyone, while at the same time allowing the transaction software to calculate the transaction without reference to the witness. This update will open up development paths for Bitcoin, by eliminating security holes and lowering the complexity of smart contracts for Bitcoin.

The second benefit is that capacity of transactions will modestly increase. New-style blocks can hold more data than current versions, which means that the amount of transaction data will increase per block. That doesn’t mean that witness data is stored off-chain, but rather following this soft-fork, the data will start being signed on the new-style blocks (which include the old-style block and extra space).

Overall this update will simplify things for developers to produce new features for Bitcoin use and it improves the efficacy of running full nodes. We are happy to see that long-term benefits will come out of this update.

According to the blog post that the BitcoinCore team released on June 24th, 2016, SEGWIT has been extensively tested by Bitcoin developers, and this was necessary because of the way SEGWIT changes parts of the Bitcoin system. One of the most important change happens to the consensus rules that full nodes use to agree on the current state of the ledger. That shift is the primary reason for such tests to be performed, because if we come to a position where the network stops agreement on the current state, Bitcoin transactions become dangerous.

Other notable changes happened to the peer-to-peer code that’s used by the network to distribute blocks and transactions. (This was all included in the 0.13.0 BitcoinCore Update, but it’s not going to happen be accepted on the main network until at least ver. 0.13.01) SEGWIT blocks and transactions are different from previous versions, so it’s important that the network is capable of distributing both SEGWIT and old-style data.

The complete update added about 7800 lines of code to the proprietary software, with the majority of lines relating to the SEGWIT capabilities. A large part of the code update related to the automated testing system, which enabled Bitcoin developers to test out the features on a separate network extensively, promptly called “testnet”.

SEGWIT was initially implemented by the Elements Project, led by Pieter Wuille. This initial implementation was happening in April through June of 2015. It was never intended for the main blockchain but is actually considered a side-chain. A few months later in October 2015, Luke Dashjr describes a method that allows SEGWIT to be implemented by using a soft-fork and they team up with Wuille to work on the implementation that is going to be completely compatible with the main blockchain.

The first version of this new code comes out in December 2015, close to the end of the year. (New year, new updates!) It’s implemented and tested extensively for the whole duration, ranging from the beginning of the year to August 23rd, 2016, when the BitcoinCore team launched the update.

Within this update, SEGWIT is completely implemented, but it’s sitting there in a passive state, only used for testing purposes. Like I mentioned before, it will become operational with the next update! The Bitcoin Core developers are finally convinced that implementation of SEGWIT will not cause any adverse effects and it won’t negatively influence Bitcoin, it’s value and reliability.

SEGWIT won’t change a lot about how you perceive Bitcoin transactions happening, well… There is one pretty perceptive change, but I’m sure you’re not going to mind it.

Transaction fees are going to get a little bit cheaper.

I’m sure we all can appreciate spending a little bit less on our transactions. But wait, what about Bitcoin smart contracts?

Yes, I’ve mentioned them. Well SEGWIT will not introduce any smart contracts, but it’s the first step allowing the development of the capability to support these.

It solves a crucial problem that currently is affecting the creation of smart contacts and script functioning. It opens up the doors to new development paths and creates new opportunities that were previously inaccessible due to security loopholes and visibility of transaction identifiers. In the future, smart contracts and scripts will use MAST, an acronym for Merkalized Abstract Syntax Trees.

A short description of MAST is that it allows the creation of conditional Bitcoin scripts to be utilized. For now, it’s being reserved for the extremely tech-savvy people, the developers to use these tools and potentially make them available to Bitcoin users. MAST is going to be available for use following the SEGWIT update in the future.