How Bitcoin Inputs Work (Unlocking Scripts)

If you look at a Bitcoin transaction, you won't see any field that says "From Address: Alice." Instead, Alice's role is represented entirely by a collection of Inputs.

An input is an explicit reference to a specific piece of unspent value currently sitting in the global UTXO database, coupled with the mathematical key required to unlock it.

---

🗃️ The 3 Fields of a Transaction Input

A transaction input consists of three fundamental variables serialized into binary:

Field Name	Size (Bytes)	Description
OutPoint	36	Tells the network exactly which piece of change from which previous block is being spent.
scriptSig (Unlocking Script)	Variable	The cryptographic proof (signatures and public keys) that satisfies the locking conditions.
nSequence	4	A parameter used to signal Replace-by-Fee (RBF) or relative timelocks (BIP 68).

┌────────────────────────────────────────────────────────┐
│                   TRANSACTION INPUT                    │
├───────────────────────────────┬────────────┬───────────┤
│ OutPoint (TxID + Vout Index)  │ scriptSig  │ nSequence │
│ (36 Bytes)                    │ (Variable) │ (4 Bytes) │
└───────────────────────────────┴────────────┴───────────┘

---

🔍 Understanding the Input Fields

1. The OutPoint (36 Bytes)

The OutPoint is the GPS coordinate of a UTXO on the blockchain. It is composed of two sub-fields: * Transaction ID (txid) (32 Bytes): The cryptographic double-SHA-256 hash of the previous transaction that created the output Alice wants to spend. * Vout Index (4 Bytes): A transaction can have multiple outputs. The Vout is a 0-indexed counter identifying the exact output being spent (e.g., 0 for the first output, 1 for the second).

2. scriptSig (Unlocking Script)

The scriptSig is the unlocking key. Its physical content depends on the type of script used to lock the coins in the previous transaction. * In a legacy P2PKH (Pay-to-Public-Key-Hash) transaction, the scriptSig contains: 1. A Cryptographic ECDSA Signature proving Alice owns the private key. 2. Alice's corresponding Public Key. * In modern SegWit transactions, this unlocking signature data is moved to a separate field called the Witness to save block weight, but it performs the exact same functional role.

3. nSequence (4 Bytes)

The sequence number was originally designed by Satoshi Nakamoto to handle transaction replacement in off-chain payment channels. Today, it serves two main purposes: * RBF Signaling (BIP 125): If the nSequence is set to any value less than 0xffffffff - 1, it signals to nodes that the transaction is eligible for Replace-by-Fee, allowing the fee to be bumped while pending in the mempool. * Relative Timelocks (BIP 68): If specific bits are set, nSequence restricts the input from being spent until a relative number of blocks or seconds have passed since the UTXO was mined.

---

💻 Stack Validation: Running scriptSig and scriptPubKey

To verify that an input has the right to spend a UTXO, a Bitcoin node executes both the unlocking and locking scripts using a simple, stack-based script interpreter.

       Step 1: Node retrieves the locking script (scriptPubKey) from the UTXO set.
       Step 2: Node loads the unlocking script (scriptSig) from the spending input.
       Step 3: Node runs scriptSig, pushing signatures and public keys onto the stack.
       Step 4: Node runs scriptPubKey on the stack to verify signatures against keys.

If the execution completes without error and the top item left on the stack is a non-zero value (True), the signature is valid, and the transaction input is approved! If it returns zero (False), the transaction is rejected, protecting the network from theft.