SegWit is almost invisible: why the introduction of technology is delayed

A week ago, on August 24, Segregated Witness, or Segwit, was finally activated by the absolute majority of the bit-based hashing of the Bitcoin network. Segwit fixes several important errors that existed in the protocol, improves scaling by increasing the effective block size, and also provides more options for deploying second-tier solutions over the basic blockbuster.
However, a week after activation, which was waited almost two years, no visible effect of SegWit's work is still not noticeable. The queue of transactions and commissions remain at the same levels, and sometimes even grow. The size of most units remains at the same level about 1MB. And even the exchange rate of bitcoin is trampled almost on the spot, showing a sluggish upward dynamics.
Why is this promising and widely advertised technology, with which the solution of almost all the vital problems of Bitcoin was connected, did not work at full strength? To understand this, you will have to step back from advertising and high-profile events and find the reasons in the source - that is, in the blockade itself.
Almost two years of debate

In December 2015, the source code for Segregated Witness (Segwit) was released. It was supposed that this update will help to cope with the problem of plasticity of transactions, which allows you to make changes to the transaction ID before it is confirmed in the blockroom. In addition, SegWit offers a way to partially scale Bitcoin, although not the most efficient.
Almost two years the technology could not get the support of 95% of hashing power that was needed for this. It was assumed that the update will be implemented via softfocus, that is, it will comply with all existing consensus rules and will be compatible with previous versions of the protocol, which is especially important for those who do not want to update.
Someone believes that the ongoing activation of Segwit is a direct result of blackmail with the introduction of BIP148, forcing the miners to finally activate the update after all the disputes. A more realistic view is that the New York Agreement caused the key players of the ecosystem to agree to express general support for Segwit.
BIP91 was released in July as part of the implementation of the New York Agreement, to reduce the activation threshold to 80% of the hashing capacity. When BIP91 completed its mission, all network miners started voting for SegWit, and it was fixed in early August. During the two weeks of the update fix period, users and organizations could update their Bitcoin clients in order to work with Segwit. However, most have not done so or have not started using the available opportunities.
How Segwit Works

From the point of view of scaling, the most notable innovation is that the concept of block size was excluded from SegWit, instead of this there is now the notion of block weight. In the terminology of SegWit, there are two types of data that are contained in the transaction. First, there are actual data of the transaction (non-witness data), such as address, output values, executable condition scripts, etc. There is also witness data, which is all the information that is needed only when the transaction is confirmed, and then these data are never actually used again.
Segwit allows you to reduce the nominal size of the transaction due to the second type of data. 1000 transactions in 1Kb obviously will quickly fill the current block size, but remember that the concept of block size is no longer - it was replaced by the weight of the block, the new limit of which is set at 4 000 000 "units of weight" (WU).
The number of units of weight in the transaction data is the number of bytes in the transaction data, multiplied by 4. The witness data is considered a direct translation to units of weight in a 1: 1 ratio.
Suppose that there are 1000 transactions in the pool of unconfirmed transactions (mempool), all with 1 KB of data. Now suppose that in each of the transactions 400 bytes is witness data, and the remaining 600 bytes are transaction data. 600 bytes for transaction data are now equal to 2,400 units of weight, whereas witness data equals 400 units, which gives a total transaction weight of 2,800 units. All these transactions together will occupy only 2,800,000 units of 4,000,000 units, leaving room for more transactions.
If you take transactions similar to those described above, you can put another 430 transactions in the block with a real size of 1kb. In this case, the actual block size when adding additional transactions will increase to ~ 1.43 MB, but the "extra" 430 KB will be moved out of the block, so the "cleaned" block will still fit into the 1Mb limit.
According to the calculations of the researchers, the average space savings due to the signatures is about half the total amount of data, that is, after the full transition to SegWit, the actual block size will be about 1.8 MB. In some cases, if there are many multi-signature transactions in the block, a larger block size is possible. Up to the established limit of 4MB (4 000 000 WU), only a block consisting of some signatures can be held, which in reality, of course, is impossible.
Since the size in bytes of the transaction without signatures becomes smaller, the commission fee for such a transaction will be less. On average, the commission will also decrease by 1.8 times, although for a single transaction this difference may differ in both directions. The savings of four times, which is written in some media, is also an ideal unattainable value, just like a 4 MB block.
In addition, the developers SegWit provided another opportunity to "facilitate" the block. Once the SegWit transaction is confirmed by the network, more unnecessary witness data can be removed from the database. However, this pricing mode (witness pruning) is not compatible with transactions without Segwit support and before the full transition is likely to be applied, otherwise the site will lose the opportunity to participate in the distribution of transactions created by other nodes. In particular, the current version of Bitcoin Core does not support this feature.
How to use Segwit?

Now back to the situation. Why did not the scaling of the network improve after activation of SegWit? The fact is that SegWit was implemented as a softphone - this means that it can, but it is not necessary to use it. And they do not use it, because it requires additional actions, and most users do not want to, do not know how, or simply do not know what to do. In order for Segwit to really increase network bandwidth, it will take weeks, or even months, until it becomes widely available.
What should be done

Segwit transactions can only be sent from Segwit addresses that have a different format than traditional ones, and are received only at SegWit addresses. Therefore, from each address that now contains coins, they must be sent to the Segwit address. And even after that, there may be a decent number of users who do not trust Segwit and do not want to use it. What in general does not bother anyone - this is the main plus softsoft. It does not force users who do not agree with the update to accept it until the vast majority of transactions go to the SegWit format.
So that you can use Segwit and send Segwit transactions, you need to send your coins to the wallet that generates Segwit addresses. Otherwise, it will be a normal transaction. In order to receive Segwit transactions in your wallet, you must create a set of SegWit-addresses. These are addresses of type P2SH and begin with 3.
What wallets support SegWit?

At the moment we know about the following wallets that support SegWit-addresses and transactions:
Bitcoin Core: SegWit-transactions are available, but there are no operations in the graphical interface, only on the command line or via the API. This significantly reduces the number of users who will be able to receive and send segwit-transactions using the most popular purse for bitcoin.
In order to create SegWit addresses in the Bitcoin Core purse, you must use the following command in the wallet console or the operating system command line:
addwitnessaddress addr where addr is the traditional address already in your wallet. The command must be executed for all addresses with non-zero balance.
Light (SPV) and mobile wallets. The support for Segwit transactions is known only by the BitGo, GreenAddress, OpenBazaar wizards, the rest of the developers have not yet announced SegWit support for transactions. Probably most of it already exists, although users may not be aware of this.
Hardware wallets: manufacturers of hardware crypto-currency wallets this time differed. All three main hardware purses - Trezor, Ledger and Keepkey, already support the creation and use of Segwit addresses, this requires only installing the latest firmware version of the device.
Current situation

Thus, if desired, users can switch to SegWit without changing their wallet. But it happens too slowly to give a visible effect. The number of SegWit transactions is growing, but their share in the total is slightly more than 0.5%. At the end of the day of September 1, it rose to 0.83%. Agree, the magnitude is far from sufficient to make the effects visible in practice.
The first segwit-transaction in the network was conducted by the BitGo engineer, Benedikt Chan, on August 25. However, it was mostly demonstrative. Since then, the number of segwit-transactions is growing, and in the last two days, their number is about 1800 pieces per day. However, this is just over 0.5% of the total daily number of transactions in the blockroom. Therefore, the number of blocks that are larger than 1MB is still small, and the limit is rarely exceeded even in a few tens of kilobytes. The largest block of 1067 KB was recorded on August 27.
All this makes it clear that the queue of unconfirmed transactions in the first days after the activation did not hurry to decrease. Some disillusioned members of the community and the media are accustomed to accusing all miners, specifically Antpool and Bitmain, who allegedly sabotage SegWit (for which they voted before) by extracting empty blocks, which contributes to the growth of the transaction queue. Obvious facts that empty and half-empty blocks on this day were extracted by four pools (Antpool, BTCC, BTC.com and 1Hash) and the fact that Antpool has been known for this since its inception in 2014 have traditionally been ignored. In addition, due to the rush around the more lucrative BCH mining, which took on a significant share of the miners, the blocks in the main network were less frequently produced these days, which also caused an increase in the transaction queue.
After September 25, the BCH mining again became less profitable than in the main chain, and the prodigal looters returned. The transaction queue began to decrease gradually. By the end of the day of September 1, despite the weak effect of SegWit, the transaction queue had fallen to acceptable values ​​of several thousand, but the automatically calculated commissions still hold around 300 satosh per byte. Nevertheless, it is already possible to send transactions with a manually assigned commission several times lower, and they are highly likely to be confirmed through several blocks.
As for the mass adoption of SegWit, it obviously should not be expected in the coming days or even weeks. Developers and operators of purses, users and business will gradually switch to segwit-addresses, but the process can last for months. An additional incentive for the transition could be the successful launch of payments Lightning Network and other developments using SegWit.