ScriptSig: The Anchor Guide to Unlocking Bitcoin Proofs

🔍 Why This Module Matters

If you think of an output as a "Safe" full of money, ScriptSig is the combination to that safe. Without a valid ScriptSig, those coins are unspendable and effectively lost to the network. This module will deconstruct the "Key" mechanism of Bitcoin, explaining how ScriptSig interacts with the stack-based execution model and why it is physically separated from the "Lock" it intends to open. Understanding ScriptSig is the first step toward mastering Bitcoin's programmable money capabilities.

🏛️ The Locking/Unlocking Lifecycle

To understand ScriptSig, you must see it as one half of a two-part conversation.

1. The Question (ScriptPubKey)

The previous transaction asked a question: "Who can provide a signature for this Public Key Hash?" This is the "Lock" that lives on the blockchain.

2. The Answer (ScriptSig)

Your new transaction provides the answer: "Here is my Digital Signature and my raw Public Key." This is the "Key" that travels with your transaction.

3. The Execution

When a node verifies your transaction, it "concatenates" (joins) these two scripts together.

• Legacy Order: [ScriptSig] + [ScriptPubKey]

• Result: If the combined script evaluates to TRUE, the coins are released.

⚙️ The Data Push: How ScriptSig Works

Unlike the "Lock" (which contains logic like OP_DUP and OP_HASH160), a standard ScriptSig is incredibly simple. It is a sequence of Data Pushes.

1. Signature Push: The node pushes the 70-72 byte ECDSA signature onto the memory stack.

2. PubKey Push: The node pushes the 33 or 65 byte public key onto the stack.

The Stack State (Initial): | Top | Bottom | | :--- | :--- | | Public Key | Signature |

Once these two items are on the stack, the "Lock" script starts executing and consumes them to perform its verification math.

🛠️ Components of a Standard P2PKH ScriptSig

graph LR
 A[ScriptSig] --> B[Push Signature]
 B --> C[Push Public Key]
 C --> D[Stack Ready]
 D --> E[ScriptPubKey Execution]

⚖️ Legacy vs. SegWit: Where is the Script?

One of the biggest changes in Bitcoin's history (SegWit) affected ScriptSig.

• Legacy (P2PKH): The signature is inside the ScriptSig field within the input.

• SegWit (P2WPKH): The ScriptSig field is actually empty (or 0 bytes). The signatures are moved to a separate "Witness" area.

• Why?: This was done to fix transaction malleability and reduce fees, but the logical function of unlocking remains identical.

🛡️ The Danger of "Custom" ScriptSigs

While most wallets generate standard ScriptSigs, Bitcoin Script is flexible.

• P2SH: In "Pay-to-Script-Hash" transactions, the ScriptSig contains an entire additional script called the Redeem Script.

• Complexity: This allows for complex logic like "2-of-3 Multisig" or "Timelocks" to be included in the unlocking process.

🎯 Learning Objectives for this Module

By the end of this module, you will be able to:

1. Identify the physical location of the ScriptSig in a transaction.

2. Explain the "Unlocking" role of ScriptSig in relation to ScriptPubKey.

3. Describe how ScriptSig pushes data onto the LIFO execution stack.

4. Contrast the contents of a legacy ScriptSig with a SegWit input.

5. Understand the two primary components (Signature and PubKey) found in a standard spend.

🗺️ Module Roadmap: What's Next?

Now that we've pushed the data, we will look at how the network processes it:

1. Stack-Based Execution: A step-by-step walkthrough of OP_CODES.

2. The Signature Component: Deconstructing the $(r, s)$ values.

3. The Public Key Component: Comparing compressed vs. uncompressed bytes.

4. Legacy vs. SegWit ScriptSig: A technical comparison of byte layouts.

🎓 Summary

ScriptSig is the "Proof of Authority" for every transaction on the ledger. It is the mathematical bridge that allows you to claim ownership of your coins without revealing your private secrets. By mastering the structure and logic of the unlocking script, you are looking at the very core of Bitcoin's cryptographic spending engine.