What is SegWit? Why do we need to implement it as soon as possible?

The author, jl2012, is a Bitcoin technology enthusiast from Hong Kong and the drafter of three Bitcoin Improvement Proposals (BIPs) related to Segregated Witness.

Each Bitcoin transaction can actually be divided into two parts. The first part is to explain the balance in and out, and the second part is used to prove the legitimacy of the transaction (mainly the signature). The first part can be called "transaction status", and the second part is the so-called "witness". If you only care about the balance of each account, the transaction status information is actually enough. Only some people (mainly miners) need to obtain transaction witnesses.

When Satoshi Nakamoto designed the Bitcoin system, he did not process the two parts of information separately, resulting in the calculation of the transaction ID mixing the transaction status and the witness. Because the witness itself includes the signature, and the signature cannot sign itself, the witness can be changed by anyone without the consent of both parties to the transaction, resulting in the so-called transaction mutability (malleability). After the transaction is issued, the transaction ID before confirmation can be changed arbitrarily, so transactions based on unconfirmed transactions are absolutely unsafe. In 2014, someone used this vulnerability to attack the Bitcoin network on a large scale, but this problem has not been solved to this day.

The Segregated Witness (SW) soft fork proposed by Bitcoin core developer Pieter Wuille in Hong Kong in December 2015 has completely solved this problem. When SW users make transactions, they send bitcoins to addresses that are different from traditional addresses. When these bitcoins are to be used, their signatures (i.e. witnesses) are not recorded as part of the transaction ID, but are processed separately. In other words, the transaction ID is completely determined by the transaction status (i.e. the balance in and out) and is not affected by the witness part. This approach has several important results:

1. You can use soft forks to increase the maximum block size:

Because old nodes cannot see these isolated witnesses at all, even if the real block exceeds 1MB, they will still think that it does not exceed the limit and will accept the block. In the whole debate about block capacity, the biggest difficulty is hard fork. SW can provide about 2MB of effective block space without any hard fork risk.

2.

From now on, only the person who issued the transaction can change the transaction ID, and no third party can do it. If it is a multi-signature transaction, the transaction ID can only be changed if multiple signatories agree. This can ensure the validity of a series of unconfirmed transactions, which is a necessary function for a two-way payment channel or lightning network. With a two-way payment channel or lightning network, two or more people can actually conduct unlimited transactions without having to put a large number of fragmented transactions on the blockchain, greatly reducing the pressure on block space.

3. Lightweight wallets can become even lighter because they no longer need to receive witness data.

4.
The signing structure can be greatly improved. On the blockchain, there was once a transaction with more than 5,000 inputs that took half a minute to complete due to a flaw in the signing design. The proposed SW soft fork will solve this problem.

After the soft fork is completed, the core developers have plans to further improve the usability and security of the entire system:

1.
Full nodes can provide very concise proofs for lightweight wallets to check whether transactions are legal. In the future, nodes will no longer be limited to full verification or no verification, but can perform partial verification according to personal resources, which means that a mobile phone can also participate in ensuring system security. This can greatly reduce the system's dependence on full nodes, and we can still maintain security even if the block capacity increases in the future.

2. A new transaction script language will be launched. For example, thousands of different scripts can be compressed to only 32 bytes through MAST technology; different signatures can also be combined for inspection, which will increase the speed of transaction inspection by multiples.

Afterwards, Kong Ming said that Bitcoin should have been isolated from the beginning. The above plan is the result of the core developers' increasing understanding of the system in the past few years. The SW test network has been operating since December 2015. I have also participated in the first-hand testing and am optimistic about the goal of launching it in April 2016. The implementation of SW will be a major leap forward for Bitcoin technology. I hope that everyone in the Chinese cryptocurrency circle can pay more attention and support it.

In another article, I will explain the pros and cons of hard forks and soft forks.

refer to:

Four Bitcoin Improvement Proposals for Segregated Witness:
1. Segregated Witness Soft Fork

https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki

2. Segregated Witness Communication Layer

https://github.com/CodeShark/bips/blob/segwit_peer_services/bip-codeshark-segwit-peer-services.mediawiki

3. Segregated Witness Transaction Address

https://github.com/jl2012/bips/blob/segwit-address/bip-segwitaddress.mediawiki

4. Segregated Witness Signature Check

https://github.com/jl2012/bips/blob/segwit-checksig/bip-segwit-checksig.mediawiki

System Expansion FAQ:

https://bitcoin.org/zh_CN/bitcoin-core/capacity-increases-faq

Transactions that take 30 seconds to check:

https://blockchain.info/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08