How Does non-SegWit (Legacy) Node Verify SegWit Transaction?

SegWit, known as Segregated Witness, is a soft fork solution for bitcoin scaling issue. This solution changes the structure of data stored in a block. Specifically, it takes the signature part out of the “input” field and move it to the end of each transaction.

By doing so, each block only includes transaction without taking into account the signature part. Since the block leaves the signature (witness) part out of itself, this process is called Segregated Witness.

In order to propagate this new process to most of miners, this SegWit is implemented as a soft fork. For non-SegWit (Legacy) node, transactions without signature part are still legal transactions and propagation will not cause a fork.

A non-SegWit node can verify a SegWit transaction as any other transitional transactions.

A typical Bitcoin transaction looks like this:

Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG

There are two sections: Input and Output. Inside the output section, the “scriptPubKey” defines the steps to verify this spending. A couple of operators are included:

OP_DUP / OP_HASH160 / OP_EQUALVERIFY / OP_CHECKSIG

These operations will execute in sequence on top of a stack. Such a stack is formatted by combining scriptSig and scriptPubKey fields.

In the “scriptSig” field, it has two parts: <sig> <pubKey>

Since there is no operation, <sig> and <pubKey> will be pushed on top of the stack:

| <pubKey>
| <sig>
— — — — — —

After execute the first operation “OP_DUP”, which means duplicating the top data, the stack updates:

| <pubKey>
| <pubKey>
| <sig>
— — — — — —

Then the next operation “OP_HASH160” computes the top <pubKey> and output its hash as <pubKey Hash1>:

| <pubKeyHash1>
| <pubKey>
| <sig>
— — — — — — — —

The “scriptPubKey” contains a string after “OP_HASH160”. The lone number string is actually a public key hash (<pubKeyHash>). This step will push this public key hash on top of the stack:

| <pubKeyHash>
| <pubKeyHash1>
| <pubKey>
| <sig>
— — — — — — — —

Next operation “OP_EQUALVERIFY” will check if the top two data is equal. After the checking, top two data will pop out. If the result is true, next operation will execute.

| <pubKey>
| <sig>
— — — — — — — —

The final operation is “OP_CHECKSIG”. This will take the last two data as arguments and check if public key and signature are matching. If the result is true, the bitcoin in this transaction can be spent.

To sum up, these operation first verify if the public key (in “scriptSig”) matches the public key hash (in “scriptPubKey”). Then the last operation checks if the public key matches the signature.

In a SegWit transaction, “scriptPubKey” and “scriptSig” are trimmed to save space for each block. However, to pass the verification steps listed above, SegWit modifies scriptSig and scriptPubKey fields like this:

scriptPubKey: Empty
scriptSig: OP_TRUE

There will be no execution to check public key, and the only and final operation will always return true because of the constant “OP_TRUE”.

When running a verification on transaction like this, a SegWit miner or node knows where to find the signature data for verification, and non-SegWit (Legacy) node will verify this in traditional way and let it go.

For non-SegWit nodes or miners, this is an ingenious trick. This transaction is a “non-standard” transaction, also called “anyone-can-spend outputs”. Such transactions are not relayed in the network. However, if a miner (SegWit miner) includes a nonstandard transaction in a block, such block will be valid and the transaction will be relayed.