One of the most important implementation in bitcoin in the last months is segwit (segregated witness), proposed as a softfork and activated in august 2017.
What is a witness? A witness is a solution that satisfies a condition. The witness is a concept very important in bitcoin transactions.
The change in transactions structure
Segregated witness is a change in the architecture of transactions that allows signatures to be into a separated and attached data structure and not be computed as a part of the transaction hash or transaction id.
Where are signatures?
Signatures are put in a separated tree in the block and those signatures are called “witnesses” and the tree is called “witness merkle tree“. The transactions Ids are no longer affected by signatures and this fixes transaction malleability.
These 2 trees are committed one into the block header (markle root) and the other on the coinbase transaction (witness merkle root). The witness data are not inside each transactions. The witness merkle root is incorporated into the coinbase transaction. Block validation has not changed because validation must validate each transaction and each witness.
- merkle-root -> put into the block header as usual
- witness-merkle-root -> put into the coinbase transaction
validation of a block implies validation of the merkle root of transactions is correct and includes all transactions and the merkle root of witnesses is correct and includes all witnesses.
With segregated witness, transactions have 2 identifiers:
- txid, double sha256 hash of the serialized transaction but without the witness data. NB: the segwit transaction has scriptSig fields empty in each field.
- wtxid, double sha256 hash of the new serialization format with witness data.
Addresses supporting segwit
About supporting addresses, there are 2 kinds of addresses:
- segregated witness wrapped inside a P2SH address, this begin with 3 and looks like a multisign address.
- new native format, bech32 type, starting with bc1. This is full segwit native. Structure is described in BIP173.
How it works
When a transaction is spending a utxo it must provide a witness (a solution which satisfies a condition). Before segwit every input in a transaction was followed by the witness data that unlocked it. The witness data was included into the transaction as a part of each input.
A segwit utxo instead specifies a locking script which can be satisfied with a witness that is found outside the input.
it reduces the cost of fee by giving a discount to the data of signatures. This increases the capacity of the block without an hard fork.
there are several advantages in adopting segregated witness. The more evident and important are the following:
- The cost of transaction is reduced by discounting the witness data and so increasing the capacity of the blockchain;
- Scalability of the blockchain. Nodes infact can prune the witness data after validating signatures. Meaning that immediately after receiving a new transaction and validating the witness data, nodes can discard the witness data.
- The transaction hash become immutable for anyone except the creator of transaction; This means that using segregate witness addresses in your transactions, you unsure that your transactions are not susceptible of malleability;
For all the above reasons is good to start using as much as possible the native segwit transactions, by using the native bech32 address format.