Segregated Witness is a proposal (BIP-141) aimed at solving the transaction malleability problem on the Bitcoin blockchain.
1. What is Transaction Malleability?
That is, the transaction content has not changed, but the transaction ID has changed. The ECDSA signature algorithm used in the BTC network, due to the symmetry of the elliptic curve, can always calculate two valid signatures for a transaction, and these two valid signatures can also be calculated from each other. After broadcasting a transaction, a transaction with the same content is published with a different signature. The two transactions have the same content but different transaction IDs, which will mislead participants in the network.
2. The transaction extension changes the signature, but the transaction content does not change. In the end, the network will still confirm the transaction content. The second transaction with a different signature but the same transaction content will also be invalidated. It has no impact on transaction security, and there will actually be no double-spending problem in the network (the same money is spent twice). So what will the transaction extension actually affect?
In fact, it is mainly because many Bitcoin services (such as exchanges and third-party on-chain automation services) rely on transaction IDs as transaction identifiers. An example is that Xiao A initiated a withdrawal from the exchange, and then his withdrawal transaction was broadcasted. Before his transaction was verified by the node, Xiao A carried out a ductile attack. It happened that the new transaction generated by the attack was confirmed first, and the new transaction would allow him to obtain the currency, and the old transaction would be rejected by the network. Xiao A complained to the exchange that he did not receive the currency. The exchange saw that the previous transaction to transfer the currency to Xiao A was indeed rejected, so it transferred another sum of currency to him.
3. It sounds like the problem is actually caused by the transaction ID being used as a transaction identifier. Is it possible not to use the transaction ID as a transaction identifier?
Analyze the content in the BTC block. For example, use the block height + transaction position to determine the identifier? Or determine the identifier based on the transaction input + output hash? These can indeed be used as unique identifiers, but they are either inefficient in practice or not as convenient and secure as transaction IDs (transaction IDs will be recorded directly in the block content and will never be changed after being uploaded to the chain).
4. How does segwit solve the problem of transaction scalability?
Segwit effectively solves this problem by separating the transaction signature data (witness) from the block, so that changing the signature will no longer affect the transaction ID. At the same time, Segwit also reduces the block size to a certain extent and improves transaction processing capabilities (for example, SPV can process more transaction content under the same bandwidth).
5. How was this problem solved before segwit?
After a transaction fails, you need to check the transaction failure error message on the blockchain and whether such a transaction has been initiated in the network within a short period of time to determine whether it has been attacked by transaction extension. At the same time, you should also try to avoid doing logic on unconfirmed transactions or transactions confirmed by a few blocks. However, these methods do not fundamentally solve the problem.
