Legacy vs. SegWit ScriptSig

One of the biggest changes in Bitcoin's history was the introduction of Segregated Witness (SegWit). This upgrade fundamentally changed where "Unlocking Data" is stored.

1. Legacy (Pre-SegWit)

In legacy transactions (Addresses starting with 1), all signature and public key data is stored directly in the ScriptSig field of the input.

• Downside: This data is part of the TXID Calculation, leading to transaction malleability.

• Downside: This data occupies expensive "block space" (1 byte = 1 byte).

2. SegWit (Native)

In Native SegWit transactions (Addresses starting with bc1q), the ScriptSig field is empty.

• The data (Signature/PubKey) is moved to a new field called the Witness.

• The Witness is segregated from the main transaction data and the TXID calculation.

• Benefit: Fixed malleability and a Witness Discount.

3. SegWit (Nested/P2SH)

In Wrapped SegWit transactions (Addresses starting with 3), the ScriptSig is not empty.

• It contains a "Redeem Script" that points to the Witness.

• This allows older wallets to send money to SegWit addresses without knowing what SegWit is.

4. Comparison Table

Feature	Legacy (P2PKH)	SegWit (P2WPKH)
ScriptSig Size	~106 Bytes	0 Bytes
Witness Size	N/A	~106 Bytes
TXID Impact	Signature changes TXID	Signature does NOT change TXID
Address Type	Starts with 1	Starts with bc1q

[!NOTE] Even though SegWit makes ScriptSig empty for most transactions today, the protocol still requires the field to exist for backward compatibility.

In the final section, we will build a Python ScriptSig Decoder to extract raw signature data.