When you send Bitcoin, the network doesn't simply take your word for it. Before any funds move, the protocol runs a tiny program to verify that you're actually authorised to spend them. That program is built from two halves: a locking script attached to the previous output, and an unlocking script you provide in your new transaction. The unlocking half is called the scriptSig, and understanding it is one of the clearest ways to see how Bitcoin enforces ownership without a bank in the middle.
What a scriptSig actually is
A scriptSig is the input-side script in a Bitcoin transaction. Its job is to satisfy the conditions set by a previous output's locking program, known as the scriptPubKey or Bitcoin output script. Think of the scriptPubKey as a padlock and the scriptSig as the key. The network runs them together, and if the combined result evaluates to true, the funds are released.
In practice, a standard scriptSig contains two items. First, a digital signature produced by your private key. Second, your public key. The signature proves you authorised this specific transaction. The public key lets the network reconstruct your Bitcoin address and confirm it matches the address the funds were originally sent to.
The protocol stacks these items and runs them through Bitcoin Script, the stack-based language that governs all transaction logic. No loops, no complex branching. Just a sequence of operations that either passes or fails.
How scriptSig fits into a full transaction
Every Bitcoin transaction is made up of inputs and outputs. Each input references a previous unspent output, called a UTXO, and the scriptSig lives inside that input field. When a miner or node validates your transaction, it combines your scriptSig with the scriptPubKey from the output you're trying to spend and runs the combined script. If validation passes across all inputs, the transaction is accepted.
A typical Pay-to-Public-Key-Hash (P2PKH) transaction, the format most beginners encounter first, works like this:
- The scriptPubKey says: "provide a public key that hashes to this address, plus a valid signature."
- Your scriptSig provides: your signature, then your public key.
- The Script engine hashes your public key, compares it to the locked address, verifies your signature, and if both checks pass, the UTXO is spent.
The entire process happens in milliseconds across thousands of nodes simultaneously, with no central authority involved.
Why scriptSig is different in SegWit transactions
With the introduction of Segregated Witness (SegWit), the signature data moved out of the scriptSig entirely and into a separate field called the witness. For native SegWit inputs (P2WPKH addresses, which start with "bc1"), the scriptSig field is left empty. The unlocking data sits in the Bitcoin witness field instead.
This matters for two reasons. First, it fixed a bug called transaction malleability, where third parties could alter the scriptSig data and change a transaction's ID without invalidating the signature. Second, witness data is counted at a discount when calculating transaction weight, so SegWit transactions are cheaper to broadcast than legacy P2PKH transactions of equivalent complexity.
For wrapped SegWit addresses (P2SH-P2WPKH, starting with "3"), the scriptSig contains a short script that points to the witness program, but the actual signature still lives in the witness field. So even there, the scriptSig is minimal.
What a scriptSig looks like on a block explorer
If you pull up any legacy Bitcoin transaction on a block explorer, you'll see the raw input data. The scriptSig appears as a hexadecimal string. Decoded, you'll find the DER-encoded signature followed by a single byte called the sighash flag (usually 0x01, meaning SIGHASH_ALL, which commits the signature to the entire transaction). After that comes the compressed public key, 33 bytes long.
The sighash flag is easy to overlook, but it's important. It defines exactly which parts of the transaction the signature covers. SIGHASH_ALL is the default and the safest. Other sighash types exist for more advanced transaction constructions, but beginners will rarely encounter them outside of specialist contexts like payment channels.
Why this matters if you're just getting started
Most beginners don't need to write scriptSig code themselves. Your wallet handles it automatically every time you press "send." But understanding the mechanism demystifies a question that trips up a lot of newcomers: why can't someone just claim your Bitcoin by knowing your address?
The answer is that your address is derived from your public key, which is derived from your private key, and spending funds requires a valid signature from that private key. The scriptSig is how that signature gets attached to a transaction and verified by the entire network. Without the private key, no valid scriptSig can be produced. No valid scriptSig means no spending.
This is also why a Bitcoin private key is so consequential. Anyone who holds it can produce a valid scriptSig for the corresponding address. Lose it and your funds are locked permanently. Share it and they can be spent by someone else immediately. The scriptSig is the mechanism; the private key is what makes it work.
ScriptSig vs scriptPubKey: the short version
If you want a one-line summary: the scriptPubKey locks funds when they arrive, and the scriptSig unlocks them when you want to spend. Both are written in Bitcoin Script. Both are stored on the blockchain. Together they form the programmable ownership model that makes Bitcoin different from any payment system that came before it.
The elegance is that neither half does anything alone. A scriptSig without the corresponding scriptPubKey proves nothing. A scriptPubKey without a matching scriptSig can never be spent. The network runs them together, evaluates the result, and reaches the same conclusion as every other node on the planet. No trusted third party required.