ScriptSig (Unlocking Script)

A ScriptSig is the data field in a Bitcoin transaction input that contains the cryptographic proof required to satisfy the spending conditions—the ScriptPubKey—of a previous unspent transaction output (UTXO). It is often called the unlocking script because it 'unlocks' the funds by providing a valid digital signature and any other required data, such as a public key. This mechanism is the core of Bitcoin's programmable security model, where spending is governed by a script instead of a simple address check.

The structure and content of a ScriptSig are dictated by the type of ScriptPubKey it is attempting to unlock. For a standard Pay-to-Public-Key-Hash (P2PKH) output, the ScriptSig contains two pieces of data: a cryptographic signature created with the sender's private key and the full public key that corresponds to the hash in the locking script. The Bitcoin node validates the transaction by concatenating the ScriptSig and ScriptPubKey and executing the combined script. Only if the final result is TRUE are the funds considered legitimately spent.

With the introduction of Pay-to-Witness-Script-Hash (P2WSH) and other Segregated Witness upgrades, the traditional ScriptSig field was largely moved to a separate witness data structure to mitigate transaction malleability and enable scaling solutions. In a native SegWit transaction, the unlocking data is not part of the traditional ScriptSig field, which is often left empty. This evolution highlights how the conceptual role of the unlocking script remains constant, even as its implementation location within a transaction can change.

Understanding ScriptSig is fundamental for developers working with raw transactions or building smart contracts on Bitcoin's layer 1. It represents the user-provided half of Bitcoin's script-based authentication system. Common related concepts include ScriptPubKey (locking script), witness data, transaction input, and digital signature. The elegance of this paired-script system allows for complex spending conditions beyond simple signatures, forming the basis for multisig wallets and other advanced Bitcoin functionalities.

The term ScriptSig is a portmanteau of "Script" and "Signature," originating from the Bitcoin Core codebase. It refers to the unlocking script placed in a transaction input to satisfy the conditions set by a previous transaction's ScriptPubKey (locking script). This naming convention directly reflects its function: it is the script that contains the cryptographic signatures and any other data required to 'unlock' the funds. In the original Bitcoin whitepaper, Satoshi Nakamoto described this mechanism simply as a script that "provides a signature."

The concept evolved from the foundational idea of digital signatures and proof-of-ownership. In early Bitcoin documentation and code, the input script was often called scriptSig, establishing it as a core technical term. Its counterpart, the scriptPubKey, defines the spending conditions. Together, they form the basis of Bitcoin's smart contract system, albeit a simple, predicate-based one. This scripting system was inspired by earlier concepts of cryptographic proof and was designed to be intentionally limited (non-Turing complete) for security and predictability.

With the advent of Segregated Witness (SegWit), the structure was modified. The witness data, which primarily contains signatures, was moved out of the traditional scriptSig field and into a separate witness structure. However, the conceptual role of the unlocking script remains identical. In modern Bitcoin discourse, ScriptSig is often used interchangeably with "unlocking script," though technically it may refer specifically to the legacy field. Understanding its etymology clarifies the direct link between the code's variable names and the fundamental input-output model of Bitcoin transactions.

A ScriptSig is the data field in a Bitcoin transaction input that provides the cryptographic proof required to unlock and spend the bitcoins held in a previous transaction's output. It is the 'unlocking script' that, when combined with the ScriptPubKey (the locking script) from the referenced output, must execute successfully for the transaction to be valid. In the original Pay-to-Public-Key-Hash (P2PKH) scheme, the ScriptSig typically contains two pieces of data: a digital signature (created with the sender's private key) and the full public key corresponding to the address that received the funds.

The validation process is performed by every node on the network. The node concatenates the provided ScriptSig with the ScriptPubKey from the spent output and executes the combined script. For a standard P2PKH script, this process involves the opcodes OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. The ScriptSig's public key is hashed and checked against the hash in the ScriptPubKey; if they match, the signature is then verified against that public key. Only if the final result of the script is TRUE is the spending condition considered satisfied.

With the introduction of Segregated Witness (SegWit), the role of ScriptSig changed significantly. In Pay-to-Witness-Public-Key-Hash (P2WPKH) transactions, the signature data (the witness) is moved from the ScriptSig field into a separate witness field. The ScriptSig in a native SegWit input is typically empty or contains a minimal datum. This separation reduces transaction size for fee calculation, mitigates transaction malleability, and enables more complex scripting. The unlocking proof is still required, but its storage location and the validation process are optimized.

Understanding ScriptSig is fundamental to grasping Bitcoin's UTXO model and security. It embodies the 'proof-of-ownership' system without a central authority. While its visible prominence has diminished with SegWit, the logical function—providing a solution to a cryptographic puzzle—remains core to authorizing transfers. Developers interacting with Bitcoin's base layer, especially when constructing raw transactions or analyzing blockchain data, must comprehend how unlocking scripts interact with their corresponding locking conditions to create valid spends.

A ScriptSig, or unlocking script, is the piece of data in a Bitcoin transaction input that provides the cryptographic proof of ownership required to spend an output. It contains the digital signatures and any other data needed to satisfy the conditions set by the previous output's ScriptPubKey (locking script). The validation process involves concatenating the ScriptSig and ScriptPubKey and executing the combined script; a transaction is only valid if the final result is TRUE. This mechanism is the core of Bitcoin's programmable security model, enabling pay-to-public-key-hash (P2PKH), multi-signature, and other complex spending conditions.

The original design had a significant flaw: the ScriptSig data was counted towards the block size limit and was included in the transaction ID (txid) calculation. This created the transaction malleability problem, where a third party could alter the ScriptSig's signature encoding without changing its validity, thereby generating a new, different txid for the same economic transaction. This malleability complicated the development of layer-2 protocols like the Lightning Network, which rely on unchangeable transaction identifiers. Furthermore, because signature data is bulky, it inefficiently consumed the limited block space, driving up fees for all transactions.

The Segregated Witness (SegWit) upgrade, activated in 2017, fundamentally restructured transaction data to solve these issues. It segregated the witness data—which includes the ScriptSig and its signatures—moving it outside the traditional transaction structure into a separate witness field. This change had two profound effects: first, it removed the witness data from the calculation of the txid, eliminating transaction malleability for SegWit outputs. Second, it introduced a new block weight metric where witness data is counted as 1 unit versus 4 units for core data, effectively increasing block capacity and reducing fees for SegWit transactions.

Post-SegWit, the role of the unlocking script is conceptually the same, but its implementation is split. The ScriptSig field in a SegWit input is often empty or contains a minimal redeem script. The actual signature data resides in the new witness field. For a native SegWit output (P2WPKH), the witness contains the signature and public key. For a wrapped SegWit output (P2SH-P2WPKH), it contains the signature, public key, and the witness script. This separation allows the network to verify signatures without making them part of the transaction's core data hash, enhancing scalability and security.

The transition to SegWit scripting underscores Bitcoin's capacity for incremental, backward-compatible evolution. While new wallets create bech32 addresses (starting with bc1q) for native SegWit, the system maintains full support for legacy ScriptSig-based transactions. This upgrade did not invalidate the original scripting opcodes but added new ones and repurposed others (like OP_CHECKSIG) to operate with witness data. The decoupling of proof from data is a foundational concept now extending to other blockchain innovations, proving that core protocol mechanics can be refined to meet new demands for efficiency and functionality.