ScriptSig (Input Script)

What Is ScriptSig?

ScriptSig (short for "script signature," also called the "input script" or "unlocking script") is a field inside each input of a Bitcoin transaction. When someone spends bitcoin, each input references a previous unspent output (UTXO). That output has a locking script (scriptPubKey) that defines the conditions for spending. The scriptSig provides the data that satisfies those conditions: typically a digital signature and the corresponding public key.

Think of scriptPubKey as a lock and scriptSig as the key. The lock says "prove you own this public key by signing with the matching private key." The scriptSig answers by providing that signature and public key. Bitcoin's Script engine evaluates both together: it first pushes the scriptSig data onto a stack, then runs the scriptPubKey opcodes against that stack. If the result is true, the spend is valid.

The name "scriptSig" comes from Satoshi Nakamoto's original variable name in the Bitcoin source code, even though a scriptSig does not always contain a signature. For example, an OP_RETURN output or certain hash-locked scripts require data other than signatures.

How It Works

Bitcoin uses a stack-based scripting language inspired by Forth. Transaction validation concatenates the scriptSig with the scriptPubKey and executes them as a single program. The scriptSig pushes data onto the stack, and the scriptPubKey consumes that data using opcodes like OP_CHECKSIG.

P2PKH: The Classic Example

Pay-to-Public-Key-Hash (P2PKH) was the most common transaction type before SegWit. The scriptSig contains two pieces of data: an ECDSA signature and the sender's compressed public key.

// scriptSig (unlocking script)
<signature> <public_key>

// scriptPubKey (locking script)
OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG

// Combined execution:
// 1. <signature> and <public_key> pushed onto stack (from scriptSig)
// 2. OP_DUP duplicates the public key
// 3. OP_HASH160 hashes it
// 4. OP_EQUALVERIFY checks hash matches <pubkey_hash>
// 5. OP_CHECKSIG verifies the signature against the public key

If step 5 succeeds, the transaction input is valid and the referenced UTXO can be spent.

P2SH: Script Hash Inputs

Pay-to-Script-Hash (P2SH) transactions wrap complex scripts behind a hash. The scriptSig for a P2SH input contains the data needed to satisfy the redeem script, followed by the serialized redeem script itself as the final push.

// P2SH multisig scriptSig
OP_0 <sig_1> <sig_2> <serialized_redeem_script>

// The redeem script (when deserialized) might be:
OP_2 <pubkey_1> <pubkey_2> <pubkey_3> OP_3 OP_CHECKMULTISIG

The leading OP_0 is required due to a historical off-by-one bug in OP_CHECKMULTISIG, which pops one extra item from the stack. This bug has been preserved for backwards compatibility.

ScriptSig Contents by Transaction Type

Notice the progression: as Bitcoin's address types evolved, scriptSig shrank until it became entirely empty for native SegWit and Taproot inputs.

ScriptSig and Transaction Malleability

ScriptSig was the root cause of transaction malleability in Bitcoin. Because the txid was computed over the entire serialized transaction (including scriptSig), anyone who could alter the scriptSig bytes without invalidating the transaction could change the txid. Three properties made this possible:

1. Non-strict DER encoding: Bitcoin originally used OpenSSL for signature validation, which accepted multiple valid encodings of the same signature. The same cryptographic signature could be serialized differently, producing different scriptSig bytes and a different txid.
2. Inherent ECDSA malleability: for any valid ECDSA signature (r, s) over the secp256k1 curve, the value (r, -s mod n) is also valid. A third party could flip the s-value without knowing the private key, creating a valid but different signature.
3. Non-minimal push operations: Script allowed multiple opcodes to push the same data (for example, using OP_PUSHDATA2 where a direct push would suffice). Substituting one for another changed the scriptSig bytes without affecting execution.

This mattered because protocols like the Lightning Network depend on chaining unconfirmed transactions. If a txid changes after broadcast but before confirmation, any child transaction referencing the original txid becomes invalid. Transaction malleability made it impossible to build reliable payment channels or multi-step protocols on top of Bitcoin.

How SegWit Solved Malleability

Segregated Witness (SegWit), activated in August 2017 via BIP 141, solved transaction malleability by moving signature and witness data out of the scriptSig into a separate witness structure. The txid is now computed without the witness data, so any modification to signatures no longer changes the txid.

For native SegWit inputs (P2WPKH, P2WSH, and P2TR), the scriptSig must be exactly empty. All unlocking data goes into the witness field instead. The witness for a P2WPKH input contains exactly two items: the signature and the public key, the same data that would have been in a P2PKH scriptSig.

Beyond fixing malleability, this separation provides a fee discount. Witness bytes count as only 0.25 weight units compared to 1 weight unit for non-witness bytes (including scriptSig). Since signatures are the largest part of a transaction, moving them to the witness field significantly reduces the effective fee.

Why It Matters

Understanding scriptSig is essential for anyone working with Bitcoin Script or building transaction-handling software. The evolution from scriptSig to witness data represents one of Bitcoin's most important architectural improvements. It enabled the modern transaction lifecycle that underpins Lightning channels, multi-step protocols, and Layer 2 systems like Spark.

For developers building on Bitcoin, the practical implication is clear: use native SegWit or Taproot address types. These produce transactions with empty scriptSigs, lower fees, and no malleability concerns. Legacy P2PKH and P2SH formats still work but carry the overhead and risks of non-empty scriptSig fields. The address type evolution from P2PKH to Taproot traces this transition in detail.

Use Cases

• Legacy transaction spending: P2PKH and P2SH inputs still use scriptSig to carry signatures and redeem scripts. Wallets must construct valid scriptSig data when spending from older address formats.
• Wrapped SegWit compatibility: P2SH-P2WPKH inputs use a minimal scriptSig containing only the witness program, allowing SegWit transactions to be sent from wallets that only support P2SH addresses.
• Custom spending conditions: advanced Bitcoin Script constructs like hash locks, time locks, or Miniscript policies require specific data in the scriptSig (or witness) to satisfy their conditions.
• Coinbase transactions: the first input of every block has a special scriptSig called the coinbase field, which miners use to include the block height (required since BIP 34) and arbitrary data such as pool identification strings.
• Transaction analysis: the contents of scriptSig reveal the spending pattern used (P2PKH, multisig, P2SH), which is relevant for chain analysis and privacy considerations.

Risks and Considerations

Malleability in Legacy Transactions

Any transaction with a non-empty scriptSig remains susceptible to third-party malleability. While BIP 146 and strict DER enforcement have reduced the attack surface, only SegWit and Taproot inputs provide a complete fix by eliminating scriptSig entirely. Applications that build chains of unconfirmed transactions should exclusively use SegWit inputs.

Size and Fee Implications

ScriptSig data is not discounted under SegWit's weight calculation. Each byte of scriptSig counts as 4 weight units, compared to 1 weight unit for witness data. A P2PKH input with a roughly 107-byte scriptSig costs significantly more in fees than an equivalent P2WPKH input where the same data sits in the witness field. This creates a strong economic incentive to migrate away from legacy address types.

Privacy Leakage

ScriptSig exposes the spending script in plaintext on the blockchain. For P2PKH inputs, the full public key is revealed when spent (it is hidden behind a hash until that point). For P2SH multisig, the scriptSig reveals the exact m-of-n configuration and all participating public keys. Taproot addresses improve privacy by making key-path spends indistinguishable from single-signature spends, regardless of the underlying complexity.

Standard Transaction Limits

Bitcoin Core enforces a maximum scriptSig size of 1,650 bytes for standard (relay-eligible) transactions. Coinbase scriptSigs are limited to between 2 and 100 bytes. Non-standard transactions with larger scriptSigs can still be included in blocks by miners but will not be relayed by default nodes.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.