Bitcoin Core 0.16.0 is finally released with full Segwit support

Getting your Trinity Audio player ready...

It’s been a long time coming, but last week, Bitcoin Core, the development team responsible for the Segwit fork of Bitcoin, finally released an update to their client, featuring full support for Segregated Witness.

In short Segregated Witness was touted as a scalability fix in itself, but as BTC found heavy usage during the 2017 run to its ATH (all-time-high), fees shot up to astronomical heights, and congestion levels reached unprecedented levels, forcing users to wait up to and over a week at times for transactions to confirm. The aftermath of which gives strong evidence for a false news media campaign concerning the scalability capability of Segwit.

However, Segwit’s true capacity increase which is only expected to provide a mere 1.7-1.8MB on average effective blocksize (or, 5-6 transactions per second throughput), will be made apparent only when the vast majority of the eco-system adopts ‘Segwit’ transactions.

Because of the way Segwit was introduced as a soft-fork, it allows Bitcoin legacy transactions, while incentivising the newer ‘Segwit’ transaction format. Thereby, encouraging users and businesses to switch to Segwit transactions, over time. As more and more wallets, exchanges, and businesses adopt Segwit, the blockchain slowly finds itself migrating over to “Segregated Witness” addresses and transactions, abandoning the original Bitcoin transaction format as laid out in the Satoshi Nakamoto whitepaper of 2008.

While many adherents to the ‘Core’ faith have been loud in the condemnation of entities like ‘Coinbase’, for whom it took 6+ months to implement Segwit, it ought to be equally observed, that Core themselves, have taken just as long to release full native support for Segwit in their own client.

It is most pivotal that Core released this as soon as possible given that so much of the rest of the eco-system is depending on them to move first. Take for example, the major exchange Kraken, which tweeted the following:

Sounds reasonable.

Certainly, the Segwit soft-fork will now have its engine roaring a little louder, as evidenced by the below graph illustrating the rising number of Segwit transactions over-time (particularly since Coinbase and Core announced support). Take note of the rise from block number 511075 (27th of Feb 2018) onwards.

As ascertained above, at 6+ months following the activation of Segwit on the BTC chain, the adoption rate for Segwit transaction still sits at only marginally over 30%. In order for the new capacity limits of 5-6 transactions per second to be realised, it requires near universal adoption of Segwit.

What does ‘Native Support for Segwit’ mean?

Upgrading to support Segwit transactions can be a technically tedious task, hence why many businesses have been waiting on Core to move first with their client, which in turn makes implementation a little easier for everyone else. A large part of the BTC eco-system already supports Segwit transactions, although this is done in a non-native, backward compatible manner.

The way non-native Segwit addresses work, is that they use former lead developer Gavin Andresen’s P2SH (pay-to-script-hash), which always start with a “3” instead of a “1”. Because the Bitcoin client already accepts P2SH, using it for Segwit in an effort to on-ramp usage quickly, made sense. But it has many drawbacks.

Using Segwit through P2SH is inefficient, and wastes in the mempool, and it therefore can contribute to rising fees. Native Segwit addresses are known as bech32 addresses, and they start with “bc1”. Native use of Segwit works a little more directly and more efficiently as bech32 has no non-witness SigScript (Signature Script).

However, because native Segwit addresses are a new bech32 format and “look different”, older wallets do not recognise them, and users that don’t upgrade such wallets won’t be able to send to these addresses.

What else comes with “Bitcoin Core 0.16”

Segwit Wallets aside, two very notable changes are:

– HD Wallets are the default! HD Wallets (Hierarchical Deterministic Wallets) are type of wallet that changes address every time it is used for receiving funds. HD wallets have been used for quite a while now, and all major wallets utilise this functionality.
– The highly controversial RBF is default in the GUI. Core’s “Replace By Fee” feature is now on by default.

There are a host of other changes introduced, most which will make little impact to the end user. For a full list of changes, check out the release notes.

Eli Afram
@justicemate