Transactions have inputs and outputs. Outputs express encumbrances, an encumbrance means a limitation on who can spend something.
So when you create a Bitcoin transaction, what you’re saying is, this can only be redeemed by X and that X is an encumbrance, which is expressed through a form of a script. The most common encumbrance is simply the one that allows a signature from one of the Bitcoin public keys, so basically, the only one who can receive this, is whoever has this key.
That’s the basic Alice pays Bob 1 Bitcoin and the encumbrance is, Bob can redeem with Bob’s key.
So if you have a transaction, you have a series of inputs and a series of outputs. You’ll have input 0, input 1, and output 0, output 1, etc. You should think of each output as a puzzle that takes a key.
As an example, output 0 has a specific input key that unlocks that particular output.
This output is called an encumbrance, in Bitcoin terminology it’s called a scriptPubKey even though in some cases, it might not be a public key at all. Simply because in the original transaction language, it was a scriptPubKey pointed to a public key, that was read as, Bob’s key.
The input key is called a scriptSig. Which means the signature that unlocks the scriptPubKey.
When you use an output as part of an input when you’re verifying it, the input that’s providing the input key in a transaction and it’s referred to the previous output in the blockchain by reference to the transactional index. So it’s saying from the transaction X last week, I’m taking the second output and here is the scriptSig that unlocks it.
That’s how you define an input.
Then you say, and I’m sending that to this new output, which is a scriptPubKey, and in order to redeem that, someone has to offer a scriptSig when they reference it as an input.
Think about it as keys and encumbrances.
One of the critical considerations, when you’re doing transactions scripting, is where does the script, the thing that has lots of data in it, go.
There’s a critical consideration that Bitcoin, at the moment, the sender pays the fee to create these encumbrances, so the scripts, which are the outputs, which are bigger in size, much bigger than simply a key, the scripts that makes up the transaction are paid for by the sender.
The recipient puts a much smaller piece of data, which is a scriptSig in their transaction, so there’s an issue, a very deliberate issue and you’ll see how that changes when we talk about paid to script hash, the bird is actually reversed, which means you only put a half a script here, and then a script is provided as a sig here, and that shifts all of that burder, the data of the output, instead of being in the output of the sender is in the input of the recipient. Another thing that does, is we’re putting a data heavy encumbrance, in the blockchain early.
With paid to script hash, this is very deliberate, the encumbrance is put in the block only when it’s redeemed. Which means, the actual large amount of data that goes into the transaction is introduces much later when the output is redeemed. That was one of the deliberate reasons that happened which is one of the reasons why P2SH is used. It’s to shift the load of data from being an output in transactions that are being paid to the sender and put into the blockchain early. Put most of the data as input, paid by the recipient who got the value after all, and go into the blockchain later. And that’s an important change as it reduces blockchain loads.
You don’t actually put all of the big data in there, until you’re ready to redeem it.